Xen Cloud Platform: How to settle someone else's VM in a new home
We have the following task:
- There is a VM 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 settle a new VM on our server, with a minimum number of gestures. The article is a collection of information from several sources. In addition, I tried to comb the teams, so that you, and myself, just use their paste-paste in the future.
The first thing we need to do is get a raw virtual machine image.
We received from an external source the PIII 1000Mhz, 512RAM, 20Gb IDE system requirements and the following files:
FreeBSD.nvram 8684 FreeBSD.vmdk 7131758592 FreeBSD.vmsd 0 FreeBSD.vmx 2234 FreeBSD.vmxf 262 The file we need is a FreeBSD.vmdk disk image that needs to be converted into a raw format. To do this, we use the qemu-img utility from the app-emulation / qemu package. Naturally, there is no need to install it on the server, the image can be converted on any linux machine. First we are convinced that the format of the image is vmdk . If the format is raw , then you do not need to convert anything and just move on 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 hard disk of 20 gigabytes in size:
$ 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 the external storage available from dom0.
It is also necessary to create a suitable VM, guided by system requirements. There is nothing special to describe here, we use free XenCenter to manage our virtual machines.
Recovering a virtual machine disk from a binary image
Go to the server for visualization 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=pygrub make the hard disk bootable, and the virtual CD-drive is 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 Find the VDI identifier 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 virtual machine hard disk 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 occurs because different virtualization systems may have a different understanding of what a gigabyte is. I will give an example. I transferred the linux virtual machine with two 6GB and 2GB disks from Hyper-V to XCP. Everything is exactly the same as described in this article. After the conversion, I received the following binary hard disk files:
-rwxrwx--- 1 1000 1000 6442426368 Sep 10 16:51 sda.raw -rwxrwx--- 1 1000 1000 2147484160 Sep 10 17:00 sdb.raw And the newly created VM's 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 binary sda.raw file is slightly less than 6GB, and sdb.raw is slightly more than 2GB. Why this happens, we can only guess. I just took when copying the smaller of two quantities. I do not know how much this solution is correct and / or universal, in my case, the VM started correctly and no problems were observed.
Sources:
Source: https://habr.com/ru/post/177679/
All Articles