Re: [Users] Making v2v easier?

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(a)linuxland.at ============================================ On Fri, 2014-01-17 at 17:19 +0200, Itamar Heim wrote: