Using Export Domain to migrate from RHEV to VMware

Latest response

We have some Virtual Machines that are better suited to be hosted by VMware (different monitoring, backup and network dependencies).

My question is regarding using the RHEV Export Domain to migrate between RHEV and VMware.

I have an NFS export currently attached to and managed by RHEV.
I would like to add it as a Data Store in VMware. Will this action somehow invalidate the Domain in RHEV? I don't know what permissions VMware expects for an NFS share (UID/GID or root access), I also do not know whether VMware expects to "own" the share.

NFS in a psuedo-clustered File System deployment has always fascinated me. I think it's awesome that either solution is capable of using a shared resource (such as NFS) and manage locking, etc... between the resources. My concern is that the Virtualization Manager on either platform will not allow this shared resource and invalidate it... specifically if I create it on RHEV first, then attempt to mount it with VMware.

Also - if anyone else has experience/advice regarding a RHEV to VMware migration strategy, feel free to share ;-)


Here's what I did when I moved some VMs from RHEV to VMware:

  • Shut the VM down in RHEV, and export it
  • On a Linux box with access to the export volume, locate the VM in the lovely RHEV "UUID"-based directory tree
  • Run "qemu-img convert -O vmdk vmdiskfile vmdiskfile.vmdk"
  • Copy the .vmdk to a VMware datastore (there's a shell script kicking around the internet to upload/download files from datastores via HTTP, but I tend to enable ssh access to ESXi and just use scp)
  • Create a new VM in VMware, but instead of creating a new virtual disk, point VMware at the uploaded .vmdk
  • Boot the VM. A RHEL 6 VM should boot fine, apart from interface MAC changes. Edit /etc/udev/rules.d/70-persistent-net.rule and /etc/sysconfig/network-scripts/ifcfg-eth* to match the new MAC(s). Restart network / reboot.

I migrated a dozen or so EL 6 VMs from RHEV 3.1 over to VMware that way, they all work fine. Other Linux versions might be a bit more of a problem, if the initrd/ramfs doesn't have the right drivers in. You might also want to do the MAC address-related config file edits before shutting the VM down, instead.

That process will likely be how I get this done. Like yourself, I prefer to use scp as well.


Here's an alternative method, so long as you're OK using a Windows box.

Download VMware Converter Standalone, which is freely available. The current version is 5.5.1 and now has good support for RHEL 6 VMs.

Keep your RHEV VM running. Make sure root can login remotely via SSH (modify /etc/ssh/sshd). You may want to put SELinux in permissive mode and stop IPtables if it's particularly restrictive, and if /tmp is mounted with 'noexec' (like in our environment), remount with 'exec'.

Start up Converter from a Windows box with good connectivity. Click "convert machine" and select "powered-on machine". This addresses the machine as just another Linux box on the network -- whether it's a RHEV VM or bare metal box or Xen, etc. -- it doesn't matter. (The only case where this definitely won't work is a container type VM, like with OpenVZ, etc.)

So you follow the wizard which is pretty self-explanatory. One default I change is in disk allocation, from thick to thin provisioned. Also, the "helper VM" may need a (temporary) static address (on the same subnet as source machine) unless you're using DHCP on your servers. And in the post-convert options I have it power down source machine and power on target machine. On the new VM, Converter comments out the mac address from the ifcfg file. I normally just delete the 70-persistent-net.rule file and let it get recreated at reboot.

We have converted many machines this way. If it fails it's usually a network or firewall issue; refer to this article:
Converter is a pretty slick tool; it's using dd and tar under the covers. If you have the source machine powered down and target machine powered up, your effective downtime for that server could be under 5 minutes. I wish Red Hat had something similar. Making it super easy to ingest machines into your virtualization environment is a smart move.

Thanks for the suggestion and the kb link, Daniel.

I converted vm in ovirt to qcow2

Please find below steps for the conversion,

1) configure export domain (example using nfs) and export the vm into it

2) on the linux host which have access to the nfs export domain in this example a vm exported to /home/exports_domain using ovirt manager gui.

3) cd into the fd251a1b-9665-4d3a-b307-66688ae7dab2, you will see a folder called 'images'

4) cd into the 'images' folder'

5) cd into the folder, in this example 7a64ffa1-e759-4a62-aac8-bf01a78f1b7c

6) check the content of the folder, you will see a file bb2794b7-3578-4eee-9d60-79853a689c4d in this case 50GB, the other one is the meta file.

7) run this command for conversion to qcow2 format

qemu-img convert -O qcow2 bb2794b7-3578-4eee-9d60-79853a689c4d jbossfile.qcow2

8) run the qcow2 image on linux kvm,virtual box etc.

full path for above steps


Above steps should also be used to convert rhev/ovirt to other format e.g vmdk

Hi All, i got requirement for migrating VM's hosted on RHEV(3.6) to VMware. Could you please let me know best procedure and prerequisites to follow.

The basic process hasn't changed, and using VMware Converter (as I outlined previously) to migrate a powered on source machine (RHEV 3.6 in your case) remains a good method.

Thanks Daniel for update, any prerequisites that need to cross check.

There's no prerequisites other than those I mentioned about making sure root has ssh login access and checking / temporarily disabling any restrictions in iptables and/or SELinux. I'm assuming you're looking to migrate RHEL 6 or RHEL 7 machines, which shouldn't present a problem using the current VMware Converter. If you have VMs with other Linux distributions (or older RHEL versions), you may want to check the VMware documentation for guest OS support. Most RHEL6/7 VMs should migrate fine, but in my experience there are usually a few that give you trouble. That's just the nature of moving an OS to different 'hardware', whether it's v2v or p2v. You might breeze through 20 in a day and the next day struggle to finish just one.

Thanks Daniel