Migrate XenServer to RHEV
Best regards
I want to migrate Virtual Machine with OS guest (RHEL.6_x64) that run on Hypervisor XenServer. I read documentation VIRT-V2V Guide but I don't understand some things. This the scenario
Machine 1
- HOST ---->XenServer Hypervisor IP: 192.168.1.18
- GUEST_A --->"RHEL_x64" Operate System IP:192.168.1.17
Machine 2
- HOST ---> RHEL-H Hypervisor 6.4 IP: 192.168.1.15
- GUEST _B ---> "Centos Minimal" Operate System
- GUEST_C ---> EMPTY -- Here should be GUEST_A From XenServer.
Machine 3
- RHEV-Manager software.
My question is virt-v2v software where should be installed, on RHEL-Manager or RHEL-Hypervisor or Guest OS ???
Responses
Hi Alexander - of those 3 choices - RHEV-M server, hypervisor, or guest OS, the only one that makes sense for installing virt-v2v is your RHEV-M server.
The guest OS does not work because you are migrating the guest OS and it will not be running during the migration. A RHEV hypervisor does not work because installing anything extra on a RHEV hypervisor does not work well.
That leaves your RHEV-M server as the only choice of the three you provided.
But there is a 4th choice that may be better than the choices you listed. You could provision another physical machine or virtual machine and set up virt-v2v there. You can do it with either Fedora or RHEL. Your RHEV environment will have an export domain, which is really just an NFS service offered by any NFS server. Give your virt-v2v physical or virtual machine access to this NFS service and you will have what you need. The advantage of this 4th choice is, you can do virt-v2v experiments without effecting your RHEV-M system. And all the v2v and p2v migrations I have done eventually required experiments and tinkering.
- Greg
Yup, every P2V I've ever attempted required some tinkering. That EOF error could be a NIC driver on the machine you are migrating. That P2V ISO needs a driver for every possible NIC in the world, but in reality it only has a few. That ISO also has issues with some storage controllers, especially old Compaq ones.
There is also a config file on the P2V server you need to edit that describes the P2V. It's pretty well documented how to do the edit.
The way it's supposed to work is, you boot the source machine from that CD. The source machine loads the block and NIC drivers it needs from the CD, reads the config stuff from the P2V server, and then starts to migrate. The P2V server connects to the RHEV export domain as an NFS client. When the P2V finishes, assuming it runs successfully, you have the virtual disks and metadata for the P2V machine sitting in your RHEV export domain. Now from your RHEV-M GUI, you can import it into your RHEV environment.
So you end up with 3 copies of your P2V machine - the original source, the copy in the export domain, and the copy in your RHEV environment.
- Greg
So one machine migrates from Xen --> RHEV just fine, the other fails with the error you described?
Are your virtual machines Linux or Windows? A year ago when I was fighting this, there were some constraints around Windows P2V migrations. The email archives from the Fedora-Virt mailing list had several comments around that time, mostly me trying various trial and error experiments.
And I have to ask the obvious question, what is different about the failing virtual machine versus the successfully migrated virtual machine? And then one random stab at a possible solution - check your free disk space in your export domain NFS service. Could this be filling up?
Another possibility is, after copying the system disk image, V2V tries to insert the virtio block driver so the target VM will be bootable. If this goes badly, that may explain the problem. The virt-V2V and P2V software has a way to turn on more extensive logging, but now I don't remember the details on how to do it.
For what it's worth, my V2V and P2V projects were all with Windows virtual machines and I never had one go smoothly. I eventually ended up inserting the virtio block driver onto the physical machines and used either Acronis to backup and restore them, or the native Windows 2003 ntbackup program.
- Greg
I agree with Sadique, bringing those packages up to the same version on the VM itself before the migration should make it work.
But wow, I'm not so sure this is a good P2V or V2V design. The idea behind P2V and V2V is, the newly migrated VM should be bug for bug the same as the source physical or virtual machine, right? Why force migrated VMs to have these versions of these packages? Well - one good reason might be that RHEL 5 VMs need these specific versions of these packages to run I guess.
- Greg
Most likely his Xen vm has a paravirtualized kernel inside the vm. This kernel will not boot once converted to KVM/RHEV. So we need to replace it with a generic kernel. Also virtio drivers are not available, afaik, in version below 5.4. So we have to use a specific kernel than the one available in source vm.
But Sadique brings up a good point - if the migrated VM will not boot, you are pretty much out of luck. And maybe there is a good reason for needing those other packages. I can't think of any, but what I think does not matter. Like it or not, the design is what it is.
Here is an ugly workaround:
Leave the original RHEL 5 VM unchanged. Shut it down, copy its virtual disks, and create a new Xen VM using the copied virtual disks, all in the original Xen environment. Think of it as kind of a poor man's snapshot.
Keep the original VM down and boot the copy you just made above. Install the necessary packages on your running copy and test. If your proprietary app works, then V2V the copy.
- Greg
You are updating from a local Satellite server, correct? If so, make sure your Satellite server is properly synced with all the RHEL 5 channels. The Xen stuff may be in its own channel - I never got deep enough into Xen to know how it was packaged.
On your Satellite server - I think the syntax is:
satellite-sync --list-channels
and then
satellite-sync -m {all your RHEL 5 channels} based on the output from above. You can always do satellite-sync --help too.
If you're updating from your Satellite server, this should make sure the source for your updates is good.
- Greg
(Edited a few minutes later)
I looked over this thread and I thought you mentioned a Satellite servera few days ago. But now I don't see it, so maybe I saw that somewhere else. Sorry...
If you are updating directly from Red Hat, make sure your yum repos make sense. The first troubleshooting step: Look in /etc/yum.repos.d and compare what you find there with a known good machine that updates properly.
So the copy of your Xen virtual machine is messed up now and will not boot - right?
It would seem the best course of action now would be to note the steps you did with this copy of the VM to make it fail and then go back to the original VM, make another copy, and look at its yum repo directory and wherre it goes for updates. I suppose the good news from all this is, at least now you know why the V2V for this one has problems.
I know, left-handed good news. American English slang, loosely meaning to make the best of a difficult situation.
How, precisely, does the boot fail? Can you boot into single user mode?
Ya know, sometimes when one mountain is full of obstacles, sometimes it makes sense to climb another mountain. Instead of fighting a long V2V battle, what would it take to build a RHEV VM from scratch, install your app on this new RHEV VM, and copy the relevant data?
- Greg
Hi,
I'm recovering this thread, because I'm trying to do the same operation to migrate XenServer 6.1 to RHEV 3.2. I'm using virt-v2v, but I get an ugly error...
I execute this command:
virt-v2v -o rhev -ic xen+ssh://root@xenhost01 -os POOL --bridge rhevm -osd
And I get this error:
virt-v2v: Failed to connect to xen+ssh://root@xenhost01: libvirt error code: 38, message: End of file while reading data: nc: invalid option -- U
nc -h for help: Input/output error
I can login to xenhost01 using ssh, but I've seen "nc" command doesn't existis in XenServer 6.1 Hypervisor.
Does anybody know how to perform this operation?
Kind regards!
David
virt-v2v is not supported with XenServer 6.1. I doubt it would ever work since I believe XenServer does not support libvirt api.
I think only VMware and Xen that supports libvirt and KVM guests can be migrated using virt-v2v.
For XenServer, you can take the image, convert it to raw or qcow2 if necessary and fire up on RHEV/KVM. Then convert it to RHEV.
Hi Sadique,
I've reach another solution: I've converted paravirtuallized Xenserver VM in full virtualized VM, performed some changes (devices names, change xen kernel and so on), and I've used P2V iso, and it has worked perfectly! I've a couple of VMs migrated to RHEV (with virtio drivers and so on :)).
Thank you very much for your help!
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
