[Users] Making v2v easier?

[Sander Grendelman]

Is there a specification for the ovf/xml/directory structure in the
export domain we can use
to (semi)manually import an ovirt-compatible machine to an export domain?

On Mon, Jan 20, 2014 at 11:39 AM, Matthew Booth <mbooth at redhat.com> wrote:
> On 20/01/14 10:36, Itamar Heim wrote:
>> 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?
>
> No, it's not even functionally complete, yet. We're planning to get that
> sorted soon.
>
> Matt
> --
> Matthew Booth, RHCA, RHCSS
> Red Hat Engineering, Virtualisation Team
>
> GPG ID:  D33C3490
> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490