[Users] Making v2v easier?

[René Koch]

Hi,

I did some migrations with v2v and p2v (most of them to RHEV, but
there's not really a difference between RHEV and oVirt).

Sources where VMware ESX, KVM-servers (hosted on RHEL and Debian), Xen
(hosted on an old SUSE server) and physical machines for p2v.

The servers I used to run virt-v2v from where RHEL 6.3-6.5 - didn't test
Fedora yet.

All sources worked fine except the old SUSE server (had some connection
errors to libvirt but didn't analyzed it further, as we decided to not
migrate this vm and instead create a new one and migrate the data).

One of the most common errors when it comes to migration from VMware is
that users connect to vCenter instead of the ESX host directly (I also
did this on my first test, as I expected to be redirected to the correct
hypervisor by vCenter).

In the past there were big issues when migration machines from VMware
with installed VMware guest tools. You have to uninstall guest tools
_BEFORE_ you migrate the vm. If not, VMware guest tools interfere with
RHEV guest tools - meaning that RHEV guest tools want work properly and
VMware guest tools refuse to uninstall if the machine is not running on
VMware platform. This is definitely more an issue of VMware guest tools
then oVirt/RHEV, but it can be a pitfall in the migration process.

virt-v2v is doing a great job for Windows and RHEL servers by installing
the virtio drivers and setting disks and nics to virtio in ovf-file. For
other Linux distributions I edited ovf file manually to have the correct
type.

Debian and Ubuntu worked fine when changing disk and nic type to virtio
(as they use UUIDs in /etc/fstab and have virtio support in initrd),
openSUSE nics work fine with virtio, disk don't, btw :)
It would be an improvement if virt-v2v could prepare Debian/Ubuntu and
openSUSE/SLES for oVirt/RHEV in the same way as it does with RHEL and
Windows.
Furthermore it would be great if I could change settings during import
(e.g. NIC of disk type, memory, cpu, display type,...).

One thing which is a big pain is, that virt-v2v copies the whole disk to
the export domain and validates it afterwards. If the validation fails,
the disk gets removed from the export domain. When migration big disks
(> 100GB) this is a real pain.

What are the improvements I would like to see?
First of all, I would love to do imports from within the webadmin
portal. At the moment I have to use virt-v2v, switch to Storage tab in
webadmin afterwards to import the vm and change it's settings (if
required) in vm tab. One tab for all these actions would be a huge
improvements. Especially if Windows admins or
non-hardcore-commandline-admins are doing the migration this would help
a lot.
When adding virt-v2v to webadmin I suggest to add a big red notice that
users shall uninstall VMware guest tools before migration the vm when
selection ESX as an input source and also mention to use the hypervisor
instead of the vCenter server.

As written above I would also love to see support for multiple Linux
distributions in virt-v2v (and p2v, too).

Last, verifying the disk before copying would be really great (don't
know if this is possible - if not an option in virt-v2v to not remove
the disk would help as maybe the disk can be imported but only virt-v2v
fails).

I hope I could explain my experience and wishes with/for virt-v2v good
enough.


-- 
Best Regards

René Koch
Senior Solution Architect

============================================
LIS-Linuxland GmbH
Brünner Straße 163, A-1210 Vienna

Phone:   +43 1 236 91 60
Mobile:  +43 660 / 512 21 31
E-Mail:  rkoch at linuxland.at
============================================



On Fri, 2014-01-17 at 17:19 +0200, Itamar Heim wrote:
> I see a lot of threads about v2v pains (mostly from ESX?)
> 
> I'm interested to see if we can make this simpler/easier.
> 
> if you have experience with this, please describe the steps you are 
> using (also the source platform), and how you would like to see this 
> make simpler (I'm assuming that would start from somewhere in the 
> webadmin probably).
> 
> Thanks,
>     Itamar
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users