(Eucalyptus, KVM) Why we need to split a VM into kernel image, ramdisk image, and disk image

cloud computingeucalyptuskvm-virtualizationvirtual-machinesvirtualization

I'm new in using cloud computing technologies. There is a popular cloud software called Eucalyptus.

I found that the way to start a VM in Eucalyptus is very different from Virtualbox. In Virtualbox, we can create a virtual disk file, install any OS into the disk file, and then we can use the disk file as a virtual harddisk to start a VM. The whole process is straight forward and easy to understand.

On the other hand, I found that the way to start a VM in Eucalyptus is quite complicated. First, we need to create raw disk file and install the guest OS. Then, we need to split the VM image into kernel image, ramdisk image, and disk image. We also need to perform the so called "bundling" process on those image files before we can use it.

I don't understand why Eucalyptus make it so difficult to start a VM. Why can't it use the Virtualbox method which is much easier?

May I know what is the purpose of splitting a VM into kernel image, ramdisk image, and disk image? If the VM is a Windows VM, then how are we going to split it?

Why can't we use the raw disk file directly? What is the purpose of bundling an image?

Best Answer

Virtualbox uses the bootloader installed onto the image. Eucalyptus is the bootloader, and so requires the things every bootloader needs: the kernel; the ramdisk; the root.

Related Solutions

KVM Virtualization – How to Copy KVM Disk Image to LVM

You may simply have an off-by-one math error:

3146776576 (size, in bytes of your .raw file)  / 1024 (kb) / 1024 (mb) == 3001MB

But you made your LV exactly 3000MB ?

There's nothing wrong with DD'ing one partition onto another. Even though your vmbuilder partition list added up to 3000, your .qcow file is a hard drive image, which includes a partition table + mbr @ the front of the disk.

How to convert a raw disk image to a copy-on-write image based on another image for use with kvm and virt-manager

This issue was caused by the way libvirt uses apparmor.

The default behavior is to provide some protection for the host against the guest by restricting which files the virtualization process on the host is allowed to access. libvirt knows that the virtualization process (kvm in this case) needs the disk image in order to operate properly, so it creates an apparmor profile which allows access to windowsxp-1.qcow2. However, it doesn't know that windowsxp-1.qcow2 is backed by basewindowsxp.qcow2, so the apparmor profile doesn't allow access to that file.

It's unfortunate that the error reporting from kvm is so minimal. The underlying failure was almost certainly an EPERM when opening basewindowsxp.qcow, but apparently this error gets flattened out and the useful information lost.

However, reading the system logs will reveal that apparmor is doing something. For example,

May 28 13:12:28 hostname kernel: [ 5338.835932] type=1503 audit(1275066748.269:42): operation="open" pid=10601 parent=1 profile="libvirt-b1a29fd0-698c-11df-9c21-f78cb972735d" requested_mask="::w" denied_mask="::w" fsuid=0 ouid=1001 name="/var/lib/libvirt/images/basewindowsxp.img"

This shows what happens when an apparmor profile denies write access to a file for a process. Each time the vm startup failed because of this misconfiguration, this log message appeared in /var/log/messages.

There are several possible solutions to the problem.

1) Disable apparmor protection. This is controllable via the virt-manager GUI. In the overview section, security subsection, apparmor can be disabled.

2) Manually allow access to the extra file. This is controlled by modifying the apparmor files in /etc/apparmor.d/libvirt/ directory. Adding a line like:

"/var/lib/libvirt/images/basewindowsxp.img" r,

to the file matching the uuid of the vm in question will grant read access to the filename in quotes.

3) Upgrade to a newer version of apparmor/libvirt/the base platform and re-create the VMs. Apparently this misconfiguration has been noticed and is addressed automatically in new enough versions of the software in question.

Related Topic