May 16, 2014 at 10:03Experience transferring a virtual machine from someone else's XEN hosting to your KVM
My task was to transfer the site from external hosting to the client server. The peculiarity was that the virtual server was well configured, and really did not want to reinstall and configure the operating system, database and all environment packages.
The site was spinning in the cloud of a well-known provider on a virtual machine with the XEN hypervisor. I was hoping that support would meet and give out the image of a virtual machine, but a miracle did not happen: the failure was cold and courteous, probably, as usual. As a result, an approximate transfer scheme was born: make a disk image, transfer it to your server, create a virtual machine in yourself, indicating the resulting image as a source.
Experienced specialists already guess what I had to face in the process of implementing the plan. For the rest I give details and ways to solve the difficulties that have arisen.
Since making a disk image on this disk itself is rather troublesome, it was necessary to connect a file system that was different from the one used. The first thing that came to mind was to mount the home folder of your server in the file system on the virtual machine using sshfs. Here are the commands for the Debian distribution:
In order for the file system not to lose its integrity, it was necessary to put it in read-only protection mode. To do this in Linux provides the opportunity to remount filesystem:
I used the dd program to create the image. I also used the data pipeline and sent it through the gzip compression program to a file located in a folder that is mounted on a remote server.
After an hour and a half, I had on my server the file /home/vasya/xvda.raw.gz with the image I needed. The compression ratio was not bad: 8.5 / 12.
On local hardware, I use Proxmox VE 3.1. I created a virtual machine with the following configuration:
Of course, I unzipped the virtual machine image file and put it in the right place with the necessary access rights (/ mnt / nfs is the section configured as Proxmox VE storage, 143 is the identifier of the new virtual machine):
In my inexperience, I was looking forward to victory, but it wasn’t there: the Grub bootloader fell into my console. Moreover, attempts to manually boot were doomed to failure: the resulting image lacked the initrd environment initializer, and the kernel was highly specialized and did not contain drivers for virtio devices (network and hard disk). Experienced specialists can supplement and explain me how Linux boot is configured in the XEN environment, I didn’t care, I already had a new plan: I need to put the linux kernel, its drivers and initrd from a working virtual machine with a similar OS on the image.
I had a working virtual machine, to which I added a new disk, and then deleted its image from the file system and replaced it with a symlink with a broken image. Previously, of course, I turned off the virtual 143 so that 2 processes would not accidentally open the image at the same time.
I downloaded virtual 200, mounted the FS of the broken image, and copied the linux kernel, the working bootloader, and device drivers there.
I turned off 200, turned on 143, and entered the Grub manual boot commands:
The system booted and even successfully started mysql and apache2. Of course, I had to fix
On a fully working machine, there were no further problems: I launched the grub installation and installed the linux kernel from the repository in order to straighten the bootloader completely and follow the debian-way:
As a result of all the manipulations, I got a virtual machine, almost identical to the original one, but working in a Proxmox VE environment with a KVM hypervisor and not requiring a special bootloader. The image is planned to be transferred to the client for start in VMware ESX cluster.
The site was spinning in the cloud of a well-known provider on a virtual machine with the XEN hypervisor. I was hoping that support would meet and give out the image of a virtual machine, but a miracle did not happen: the failure was cold and courteous, probably, as usual. As a result, an approximate transfer scheme was born: make a disk image, transfer it to your server, create a virtual machine in yourself, indicating the resulting image as a source.
Experienced specialists already guess what I had to face in the process of implementing the plan. For the rest I give details and ways to solve the difficulties that have arisen.
1. Connect to your server
Since making a disk image on this disk itself is rather troublesome, it was necessary to connect a file system that was different from the one used. The first thing that came to mind was to mount the home folder of your server in the file system on the virtual machine using sshfs. Here are the commands for the Debian distribution:
# apt-get install sshfs # mkdir / mnt / vasya # sshfs vasya@pupkin.ru: / home / vasya / mnt / vasya Password: 2014 Cheburashka
2. Transfer FS to read-only
In order for the file system not to lose its integrity, it was necessary to put it in read-only protection mode. To do this in Linux provides the opportunity to remount filesystem:
mount -o ro,remount /. The command naturally did not work, the kernel blocked the execution of the command with an error mount: / is busy. After some googling, there was a reason: many files were opened by daemons. On the server I had to stop ntp, apache2, mysql, rsyslogd (maybe I missed something, but the list of running processes can be viewed with the htop or top command).# invoke-rc.d ntp stop # invoke-rc.d apache2 stop # invoke-rc.d mysql stop # invoke-rc.d rsyslogd stop # mount -o ro, remount / # touch / test touch: cannot touch `/ test ': Read-only file system
3. Creating and transferring an image
I used the dd program to create the image. I also used the data pipeline and sent it through the gzip compression program to a file located in a folder that is mounted on a remote server.
# dd if = / dev / xvda bs = 64K | gzip -c> /mnt/vasya/xvda.raw.gz
After an hour and a half, I had on my server the file /home/vasya/xvda.raw.gz with the image I needed. The compression ratio was not bad: 8.5 / 12.
4. Connecting the image to a new virtual machine
On local hardware, I use Proxmox VE 3.1. I created a virtual machine with the following configuration:
balloon: 256 bootdisk: virtio0 cores: 2 ide2: nfs-da: iso / debian-7.2.0-amd64-netinst.iso, media = cdrom, size = 222M memory: 768 name: pupkin net0: virtio = 26: 95: 81: 17: D9: 14, bridge = vmbr0 ostype: l26 sockets: 1 virtio0: nfs-da: 143 / vm-143-disk-1.raw, format = raw
Of course, I unzipped the virtual machine image file and put it in the right place with the necessary access rights (/ mnt / nfs is the section configured as Proxmox VE storage, 143 is the identifier of the new virtual machine):
# zcat /home/vasya/xvda.raw.gz> /mnt/nfs/images/143/vm-143-disk-1.raw # chown nobody: nogroup /mnt/nfs/images/143/vm-143-disk-1.raw
In my inexperience, I was looking forward to victory, but it wasn’t there: the Grub bootloader fell into my console. Moreover, attempts to manually boot were doomed to failure: the resulting image lacked the initrd environment initializer, and the kernel was highly specialized and did not contain drivers for virtio devices (network and hard disk). Experienced specialists can supplement and explain me how Linux boot is configured in the XEN environment, I didn’t care, I already had a new plan: I need to put the linux kernel, its drivers and initrd from a working virtual machine with a similar OS on the image.
5. Bootloader fix
I had a working virtual machine, to which I added a new disk, and then deleted its image from the file system and replaced it with a symlink with a broken image. Previously, of course, I turned off the virtual 143 so that 2 processes would not accidentally open the image at the same time.
# rm /mnt/nfs/images/200/vm-200-disk-2.raw # ln -s /mnt/nfs/images/143/vm-143-disk-1.raw /mnt/nfs/images/200/vm-200-disk-2.raw
I downloaded virtual 200, mounted the FS of the broken image, and copied the linux kernel, the working bootloader, and device drivers there.
# mkdir / mnt / vdb1 # mount / dev / vdb1 / mnt / vdb1 # cp /boot/vmlinuz-3.2.0-4-amd64 /mnt/vdb1/boot/vmlinuz-3.2.0-4-amd64 # cp /boot/initrd.img-3.2.0-4-amd64 /mnt/vdb1/boot/initrd.img-3.2.0-4-amd64 # cp /boot/System.map-3.2.0-4-amd64 /mnt/vdb1/boot/System.map-3.2.0-4-amd64 # cp -r /lib/modules/3.2.0-4-amd64 / mnt / vdb1 / lib / modules
I turned off 200, turned on 143, and entered the Grub manual boot commands:
grub> root (hd0, msdos1) grub> linux /boot/vmlinuz-3.2.0-4-amd64 root = / dev / vda1 grub> initrd /boot/initrd.img-3.2.0-4-amd64 grub> boot
The system booted and even successfully started mysql and apache2. Of course, I had to fix
/etc/network/interfacesit so that the system went to the local network and was able to communicate with the router and the Internet. On a fully working machine, there were no further problems: I launched the grub installation and installed the linux kernel from the repository in order to straighten the bootloader completely and follow the debian-way:
# grub-install / dev / vda # apt-get update # apt-get install linux-image-2.6.32-5-486 # reboot
Conclusion
As a result of all the manipulations, I got a virtual machine, almost identical to the original one, but working in a Proxmox VE environment with a KVM hypervisor and not requiring a special bootloader. The image is planned to be transferred to the client for start in VMware ESX cluster.