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 <mbo...@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 <ih...@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 _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users