Re: [Users] Making v2v easier?

On Fri, Jan 17, 2014 at 05:06:13PM +0100, Sander Grendelman wrote: > On Fri, Jan 17, 2014 at 4:19 PM, Itamar Heim <iheim(a)redhat.com&gt; 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. > hear hear! > >> >> if you have experience with this, please describe the steps you are using >> (also the source platform), > > Sources: > - Existing KVM (virt-manager/libvirt) platform > - ESX > - ova/ovf templates from several sources > > Methods: > - KVM: > virt-v2v with libvirtxml option, works reasonably well, most issues > are with windows guests where virt-v2v needs libguestfs-winsupport and > virtio-win (RHEL only) > - ESX: > virt-v2v which works reasonably well _if_ the right packages > (libguestfs-winsupport virtio-win) are installed. > virt-v2v can be used directly from ESX/ESX host (configure .netrc > first) but this is quite slow > another option is to export the VM as an OVA and then import it with virt-v2v > - ova/ovf templates: > hit and miss with virt-v2v, especially if they contain something > that is not a regular windows/linux guest. > Another option is to do a direct copy of the disks on a pre-created > VM, clumsy. > >> and how you would like to see this make simpler >> (I'm assuming that would start from somewhere in the webadmin probably). > > Webadmin would be nice, but better behaviour from existing tools would be > a nice start too. > > For example: the flow with virt-v2v is > 1) Analyze source, look for disks > 2) Convert/copy disks to ovirt export domain > 3) Try to add virtio stuff to the copied disks on the export domain > > If step 3 fails ( which happens a LOT), the copied disks are removed. > This is very frustrating if you just waited a couple of hours for a large > VM (e.g. 200GB) to be copied :( > > Some kind of graceful abort/resume would be VERY welcome. The above basically come down to the fact that currently virt-v2v does the copy first and the v2v step second. It was my understanding [Matt?] that guestconv is supposed to do the v2v step first followed by the copy, which should solve all of that.

> Another issue with virt-v2v is that it _always_ tries to add virtio > drivers. I have a virtual appliance that contains some kind of > proprietary embedded OS: adding drivers will always fail, give me > some option to override that and configure simple ide / e1000 > hardware for the VM

I suspect in this case what you really should be doing is just copying the source disk image, without using virt-v2v at all.