[Users] Making v2v easier?

[Itamar Heim]

On 01/20/2014 12:18 PM, Matthew Booth wrote:
> On 20/01/14 09:53, Richard W.M. Jones wrote:
>> 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 at redhat.com> 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.
>
> guestconv doesn't address this problem directly. We need smarter copying
> for 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
>
> guestconv *does* address that.
>
>> I suspect in this case what you really should be doing is just copying
>> the source disk image, without using virt-v2v at all.
>
> Matt
>

is guestconv ready for adoption/testing instead of virt-v2v?