Xen Cloud Platform: How to Set Up a Strange VM in a New Home
We had the following task:
- There is a virtual machine image prepared and configured in VMware, in our particular case FreeBSD 8.1
- There is a virtual platform XCP 1.6 in which our virtual machines are already spinning
It is necessary to put a new VM on our server, with a minimal amount of gestures. The article is a collection of information from several sources. In addition, I tried to comb the team so that you, and myself, would just apply their copy-paste in the future.
The first thing we need to do is get a raw image of the virtual machine
We received from the external source the system requirements of PIII 1000Mhz, 512RAM, 20Gb IDE and the following files:
FreeBSD.nvram 8684
FreeBSD.vmdk 7131758592
FreeBSD.vmsd 0
FreeBSD.vmx 2234
FreeBSD.vmxf 262
The file we need is the FreeBSD.vmdk disk image , which must be converted to the "raw" format. To do this, we use the qemu-img utility from the app-emulation / qemu package . Naturally, it is not necessary to install it on the server, the image can be converted on any linux-machine. First, make sure that the image format is vmdk . If the format is raw , then you do not need to convert anything and just go to the next step.
$ qemu-img info FreeBSD.vmdk
image: FreeBSD.vmdk
file format: vmdk
virtual size: 20G (21474836480 bytes)
disk size: 6.6G
Next, the actual conversion, after which we get a binary image of a 20 gigabyte hard drive:
$ qemu-img convert FreeBSD.vmdk -O raw FreeBSD.raw
FreeBSD.raw 21474836480
The method of delivering this image to the visualization server can be any convenient for you, in our case, I just copied it to an external storage accessible from dom0.
It is also necessary to create a suitable VM, guided by system requirements. There is nothing special to describe here, we use the free XenCenter to manage our virtual machines.
Recovering a virtual machine disk from a binary image
We go into the visualization server and find the UUID of the vital machine:
$ xe vm-list
...
uuid ( RO) : c681c725-xxxx-xxxx-xxxx-5d7cd920bdbf
name-label ( RW): FreeBSD
power-state ( RO): halted
...
$ export VMUUID=c681c725-xxxx-xxxx-xxxx-5d7cd920bdbf
install the bootloader:
$ xe vm-param-set uuid=$VMUUID PV-bootloader=pygrubmake the hard drive bootable, and the virtual CD drive not bootable:
$ xe vbd-param-set uuid=$(xe vbd-list vm-uuid=$VMUUID userdevice=0 --minimal) bootable=true
$ xe vbd-param-set uuid=$(xe vbd-list vm-uuid=$VMUUID type=CD --minimal) bootable=false
we find the identifier of the VDI disk of the newly created virtual machine:
$ xe vm-disk-list uuid=$VMUUID
Disk 0 VBD:
uuid ( RO) : 50adb0d9-xxxx-xxxx-xxxx-f8f64e5c4f19
vm-name-label ( RO): FreeBSD
userdevice ( RW): 0
Disk 0 VDI:
uuid ( RO) : af85b950-xxxx-xxxx-xxxx-b5203ba45aae
name-label ( RW): FreeBSD
sr-name-label ( RO): Local storage
virtual-size ( RO): 21474836480
$ export VDIID=af85b950-xxxx-xxxx-xxxx-b5203ba45aae
go to the environment in which the hard disk of the virtual machine is available:
$ /opt/xensource/debug/with-vdi $VDIID /bin/bash
now the device / dev / $ DEVICE is the hard disk of the virtual machine. It remains to roll on him the image that we got at the very beginning:
$ /opt/xensource/libexec/sparse_dd -src /var/run/sr-mount/.../FreeBSD.raw -dest /dev/$DEVICE \
-size 21474836480 -prezeroed
$ exit
That's all, you can start a virtual machine.
UPD:
In some cases, when copying a hard disk image, the following error may occur:
Device /var/run/sr-mount/.../<образ.img> has an unknown driver
This arises because different virtualization systems may have a different understanding of what gigabytes are. I will give an example. I ported a linux virtual machine with two 6GB and 2GB drives from Hyper-V to XCP. Everything is exactly the same as described in this article. After the conversion, I received the following binary files of hard drives:
-rwxrwx--- 1 1000 1000 6442426368 Sep 10 16:51 sda.raw
-rwxrwx--- 1 1000 1000 2147484160 Sep 10 17:00 sdb.raw
And freshly created VM disks look like this:
# xe vm-disk-list uuid=$VMUUID
Disk 0 VBD:
uuid ( RO) : 6e81420a-xxxx-xxxx-xxxx-98b4fc8a5fd4
vm-name-label ( RO): linux
userdevice ( RW): 1
Disk 0 VDI:
uuid ( RO) : 3af76842-xxxx-xxxx-xxxx-b78dca108b22
name-label ( RW): linux-sdb
sr-name-label ( RO): Local storage
virtual-size ( RO): 2147483648
Disk 1 VBD:
uuid ( RO) : 28784fa2-xxxx-xxxx-xxxx-6100d97ccc29
vm-name-label ( RO): linux
userdevice ( RW): 0
Disk 1 VDI:
uuid ( RO) : f858579c-xxxx-xxxx-xxxx-5fc0493269fa
name-label ( RW): linux-sda
sr-name-label ( RO): Local storage
virtual-size ( RO): 6442450944
As you can see, the sda.raw binary is slightly smaller than 6GB, and sdb.raw is slightly larger than 2GB. Why this happens, one can only guess. When copying, I just took the smaller of the two values. I don’t know how much such a solution is correct and / or universal, in my case VM started correctly and there are no problems.