RHEL HA VM cluster v2v to RHEV

Latest response



We have numerous RHEL5 HA VM clusters which are home to several hundred RHEL5 VM's.  The VM's use raw CLVM devices for storage.


VM configuration files (guest.xml) are held in a GFS clustered filesysems shared by the cluster nodes, as per RH recommendations.


I've created RHEL6 VM to be used as a virt-v2v stage which can communicate freely with both the RHEV Export storage domains and the RHEL HA VM clusters.


I would like to use the virt-v2v tool to migrate the VM's from the RHEL5 HA VM cluster to a nice new RHEV environment.


The V2V Guide appears to cover migrations from a standalone KVM server but not a clustered KVM server environment and I'm hitting numerous problems and issues when trying.


Before I spend anymore time doing so, are you able to tell me if virt-v2v supports this type of migration ?

(I do hope so!)





virt-v2v simply connects to libvirt on the running host, and manipulates the exported VMs through that link. I don't think it should matter whether or not the libvirt instance is actually a clustered resource.


Can you please elaborate on what exactly the encountered issues were?

Hello again Dan.


Don't worry, I think I've got it sussed now.

Firstly, I was having a spot of bother creating the required storage pool pre-req on the RHEL cluster but that was down to my misunderstanding of the process.


The second issue is that the VM resource needs to be in a "stopped" state in order for virt-v2v to operate.

In a clustered environment, clusvcadm is used to to disable/stop a clustered VM resource but this effectively initiates a "virsh undefine" on the VM resource, removing it from libvirt control and making it invisible to virt-v2v.

Simply had to place the VM resource back under control of libvirt by initiating a "virsh define <path to guest.xml>" which made it visible to virt-v2v and migration was possible.

(Just have to remember to undefine the VM once migration is complete otherwise you are in danger of having libvirt running the VM locally whilst also under control of the cluster as a VM resource!)