I am investigating the procedure to follow when moving a KVM guest instance from one host to another where the guest uses LVM as its storage. As a preliminary cut I have cobbled the following together from various sources located through Google searches:
1. Log in to vmhost_old
2. Shutdown guest
3. Create an LVM snapshot of the guest volume 3.a. lvcreate -s -L 300m -n LVM_guest_snapshot guest_lv
4. Convert snapshot to a file image 4.a dd if=/dev/vhost/LVM_guest_snapshot of=/tmp/fs/LVM_guest_snapshot.img bs=4096
5. Remove the original snapshot 5.a lvremove /dev/vhost/LVM_guest_snapshot
6. Move the snapshot image file to the new KVM host. Note that for large vm guest images tape transport is probably better than network transfers.
7. Log in to vhost_new
8. Create a new lv on the new vhost 8.a lvcreate -n guest_name_lv -L 60G vhost_new_vg
9. Copy transferred image to new LV 9.a dd if=tmp/LVM_guest_snapshot.img of=/dev/vhost_new/guest_name_lv bs=4096
10. Copy guest xml file from vhost_old via sftp 10.a. get /etc/libvirt/qemu/guest_name.xml \ /etc/libvirt/qemu/guest_name.xml
11. Start new guest?
Is there anything obviously wrong or omitted from this?
On Tue, 2011-11-29 at 15:51 -0500, James B. Byrne wrote:
I am investigating the procedure to follow when moving a KVM guest instance from one host to another where the guest uses LVM as its storage. As a preliminary cut I have cobbled the following together from various sources located through Google searches: ...
If you are moving the virtual disk, you can't run the virtual machine while you are moving it. Therefore, taking a snapshot (and removing it later) is superfluous.
I use md5sum to give myself some extra re-assurance that a copy that big is accurate.
Are the virtualization servers at the same location?
How often do you move virtual machines?
If your virtualization servers are in the same location, you might want to look into setting up a LAN for transferring virtual machine images. It would only take an extra network card in each virtualization server and a Gb Ethernet switch (or better).
If you are interested in virtual disk replication, you might want to look at DRBD. It adds an extra layer to your storage, but allows for hot replication of disk space which would allow you to start a virtual machine on any virtualization server.
On Tue, November 29, 2011 17:11:01, Ed Heron Ed at Heron-ent.com wrote:
If you are moving the virtual disk, you can't run the virtual machine while you are moving it. Therefore, taking a snapshot (and removing it later) is superfluous.
Point taken.
I use md5sum to give myself some extra re-assurance that a copy that big is accurate.
Good idea.
Are the virtualization servers at the same location?
At the moment. It is planned that there will be two vhosts at each of two different locations, one backing up the other.
How often do you move virtual machines?
I have not moved any as of yet. I am investigating how to do this as part of setting up our first virtual server host. I am discovering what is possible and the techniques used. Moving vm guests is not being considered for load balancing but is under consideration for providing warm spares for use in a DR situation.
If your virtualization servers are in the same location, you might want to look into setting up a LAN for transferring virtual machine images. It would only take an extra network card in each virtualization server and a Gb Ethernet switch (or better).
Our vhosts all (will) have two nics, one for public IPs and one for private IPs. The private IPs are used for vhost management. The experimental vhost is so equipped.
If you are interested in virtual disk replication, you might want to look at DRBD. It adds an extra layer to your storage, but allows for hot replication of disk space which would allow you to start a virtual machine on any virtualization server.
This is a useful suggestion. However, I find that the availability of a DRDB package on CentOS-6 is presently an issue. And, our vm project has already expanded into multiple areas with commensurate delays. I think that I will leave DRDB for a later time.
So, what I now have for a proposed procedure is:
1. Log in to vmhost_old
2. Shutdown guest
3. Convert guest lvs to file images for each lv 3.a dd if=/dev/vhost/lv_vhost_guest of=/tmp/fs/lv_vhost_guest.img bs=4096
4. Create MD5 hash for each image file 4.a md5sum /tmp/fs/lv_vhost_guest.img > \ /tmp/fs/lv_vhost_guest.md5
5. Move the guest image file(s) and the checksum file to the new vhost; preserving both the directory structure and file names or subsequently modifying the file names in the md5 checksum file. Note that for large vm guest images tape transport is probably better than network transfers.
6. Log in to vhost_new
7. Verify md5 checksum(s) on transferred file(s). 7.a md5sum -c /tmp/fs/lv_vhost_guest.md5
8. Create a new lv(s) on the new vhost. Ensure sufficient size. 8.a lvcreate -n lv_guest_name -L 60G vhost_new_vg
9. Copy transferred image to new LV 9.a dd if=/tmp/fs/lv_vhost_guest.img of=/dev/vhost_new/lv_guest_name bs=4096
10. Copy guest xml file from vhost_old via sftp 10.a. get /etc/libvirt/qemu/guest_name.xml \ /etc/libvirt/qemu/guest_name.xml
11. Start new guest?
Thanks,
-
Ed Heron -
James B. Byrne