5:19 p.m.
I see a lot of threads about v2v pains (mostly from ESX?)
I'm interested to see if we can make this simpler/easier.
if you have experience with this, please describe the steps you are
using (also the source platform), and how you would like to see this
make simpler (I'm assuming that would start from somewhere in the
webadmin probably).
Thanks,
Itamar
5:51 p.m.
Hi,
I myself have no experience with this so far, but I can quote "blaster"
from the ML:
Blaster wrote:
I haven’t tried this yet, but if I had to move a VM from ESXi to
oVirt
this is how I would do it…
(actually, this is how I did it with Windows 7 guests…)
Shutdown guest on ESXi (or use GhettoVCB to make a snapshot backup
if
you don’t want an outtage)
NFS copy guest from ESXi server to temp storage somewhere
qemu-img convert guest.vmdk -O raw guest.raw
Create an oVirt guest with the appropriate OS type
Add a disk of the same GB to the guest
After oVirt finishes creating the disk, copy the guest.raw file over
the disk image oVirt made
boot guest and install qemu-agent, ovirt-agent, spice-agent (or better
yet, do this before you shutdown on ESXi)
remove VMware tools.
The importing and virt2v procedure seems far to complex and error
prone to me.
Maybe he can add something :)
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
6:06 p.m.
On Fri, Jan 17, 2014 at 4:19 PM, Itamar Heim <iheim(a)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.
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
Thanks,
Itamar
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
11:53 a.m.
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>
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.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
12:05 p.m.
On 01/20/2014 11:53 AM, 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(a)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.
would we focus on integrating with guestconv? how different from
virt-v2v from integration perspective?
> 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.
Rich.
12:18 p.m.
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(a)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
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
12:36 p.m.
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(a)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?
12:39 p.m.
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(a)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
12:47 p.m.
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(a)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(a)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
8:13 a.m.
On 01/17/2014 10:19 AM, Itamar Heim 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.
if you have experience with this, please describe the steps you are using
(also the source platform), and how you would like to see this make simpler
(I'm assuming that would start from somewhere in the webadmin probably).
I have spent most of the day trying to do this, and so far have failed.
Source: VMWare Server 2.0 disk files (.vmx, .vmdk, etc.), about 10 VMs to
transfer.
Eliminating all the false starts and detours along the way, this is what I
have done so far.
* copy my tree of vmware files to local storage;
in case I goof up or get fumble-fingered and need to start over clean
again.
* Set up a 32-bit VM (running Centos 6)
because vmware-vdiskmanager only seems to come in 32 bit in the VDSDK
package I found to download.
I was planning to do this anyway, to run GoogleEarth and other
software that doesn't come in pure-64bit format.
* run vmware-vdiskmanager -R <file-name.vmdk>
to clean up errors that kept next step from happening on about 1/3 of
*.vmdk files.
* run ovftool <office-5/office-5>.vmx <office-5>.ova
to turn .vmx and .vmdk files into .ova files -- long process
* BEAT HEAD AGAINST WALL because virt-v2v.x86_64 0.9.1-5.el6_5 from Centos
updates doesn't seem to know about .ova files. I was following the
instructions in
Red_Hat_Enterprise_Virtualization-3.3-Beta-V2V_Guide-en-US.pdf guide, but I
figured out that the v2v they are talking about has an "-i ova" option,
while the help file for the version I am using does not list ova as an
option for -i, and if I try to use it, it tells me that it is an invalid
option, and if I leave it off it goes off looking for a qemu///system to
attach to. help files for v2v say nothing at all about .ova files.
I am wondering where to find a v2v program that knows about .ova files, or
else am I going to have to import all my VMWare files to my (non-ovirt) KVM
host, and then drag them into ovirt from libvirt?
My setup:
All hosts running Centos 6.5, fully up to date.
2 hosts
engine running in KVM VM, hosted on a non-oVirt KVM host.
gluster replica 3 file system across 2 ovirt hosts and on KVM host.
Going to bed now to give head some rest.
Ted Miller
Elkhart, IN, USA
12:25 p.m.
On Sun, Jan 19, 2014 at 7:13 AM, Ted Miller wrote:
* BEAT HEAD AGAINST WALL because virt-v2v.x86_64 0.9.1-5.el6_5 from Centos
updates doesn't seem to know about .ova files. I was following the
instructions in
Red_Hat_Enterprise_Virtualization-3.3-Beta-V2V_Guide-en-US.pdf guide, but I
figured out that the v2v they are talking about has an "-i ova" option,
while the help file for the version I am using does not list ova as an
option for -i, and if I try to use it, it tells me that it is an invalid
option, and if I leave it off it goes off looking for a qemu///system to
attach to. help files for v2v say nothing at all about .ova files.
I am wondering where to find a v2v program that knows about .ova files, or
else am I going to have to import all my VMWare files to my (non-ovirt) KVM
host, and then drag them into ovirt from libvirt?
I made a bit of research about this
Strange.... I just update a CentOS 6.4 VM to latest 6.5 and see that
there (also matching RHEL 6.5 I think) there is indeed as you wrote:
virt-v2v-0.9.1-5.el6_5.x86_64
And it seems ova is missing as an option...
Instead on a Fedora 19 system with
virt-v2v-0.9.0-3.fc19.x86_64
I have it....
So for any reason was it removed in newer packages?
It seems also strange to see a Fedora package (even if 19 and not 20)
older than a RH EL 6 one ...
RHEL 6 version bumped this way skipping 0.9.0:
* Wed Jun 12 2013 Matthew Booth <mbooth(a)redhat.com> - 0.9.1-1
- Rebase to new upstream release
* Mon Oct 22 2012 Matthew Booth <mbooth(a)redhat.com> - 0.8.9-2
while fedora 19 has been currently stopped at
* Wed Jul 03 2013 Richard W.M. Jones <rjones(a)redhat.com> - 0.9.0-3
- Default to using the appliance backend, since in Fedora >= 18 the
libvirt backend doesn't support the 'iface' parameter which virt-v2v
requires.
- Add BR perl(Sys::Syslog), required to run the tests.
- Remove some cruft from the spec file.
BTW in F20 we do have ova too:
virt-v2v-0.9.0-5.fc20.x86_64
and in fact it has the older version...
For RHEL 6 I remained here:
http://lists.ovirt.org/pipermail/users/2013-May/014457.html
ANd no particular virt-v2v package in rhev source repo
http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/
For sure the rhev 3.3 beta guide is incorrect at the moment
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Vir...
because it says
"
virt-v2v is available on Red Hat Network (RHN) in the Red Hat
Enterprise Linux Server (v.6 for 64-bit x86_64) or Red Hat Enterprise
Linux Workstation (v.6 for x86_64) channel. Ensure the system is
subscribed to the appropriate channel before installing virt-v2v.
"
and some lines below
"
7.1. virt-v2v Parameters
The following parameters can be used with virt-v2v:
-i input Specifies the input method to obtain the guest for
conversion. The default is libvirt. Supported options are:
libvirt
Guest argument is the name of a libvirt domain.
libvirtxml
Guest argument is the path to an XML file containing a libvirt domain.
ova
"
Any light to shed on this?
Thanks
Gianluca
7:34 a.m.
--------------030307010403070106030205
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
I am wide open to suggestions (see discussion at bottom, as usual).
On 1/19/2014 5:25 AM, Gianluca Cecchi wrote:
On Sun, Jan 19, 2014 at 7:13 AM, Ted Miller wrote:
> * BEAT HEAD AGAINST WALL because virt-v2v.x86_64 0.9.1-5.el6_5 from Centos
> updates doesn't seem to know about .ova files. I was following the
> instructions in
> Red_Hat_Enterprise_Virtualization-3.3-Beta-V2V_Guide-en-US.pdf guide, but I
> figured out that the v2v they are talking about has an "-i ova" option,
> while the help file for the version I am using does not list ova as an
> option for -i, and if I try to use it, it tells me that it is an invalid
> option, and if I leave it off it goes off looking for a qemu///system to
> attach to. help files for v2v say nothing at all about .ova files.
>
> I am wondering where to find a v2v program that knows about .ova files, or
> else am I going to have to import all my VMWare files to my (non-ovirt) KVM
> host, and then drag them into ovirt from libvirt?
I made a bit of research about this
Strange.... I just update a CentOS 6.4 VM to latest 6.5 and see that
there (also matching RHEL 6.5 I think) there is indeed as you wrote:
virt-v2v-0.9.1-5.el6_5.x86_64
And it seems ova is missing as an option...
Instead on a Fedora 19 system with
virt-v2v-0.9.0-3.fc19.x86_64
I have it....
So for any reason was it removed in newer packages?
It seems also strange to see a Fedora package (even if 19 and not 20)
older than a RH EL 6 one ...
RHEL 6 version bumped this way skipping 0.9.0:
* Wed Jun 12 2013 Matthew Booth <mbooth(a)redhat.com> - 0.9.1-1
- Rebase to new upstream release
* Mon Oct 22 2012 Matthew Booth <mbooth(a)redhat.com> - 0.8.9-2
while fedora 19 has been currently stopped at
* Wed Jul 03 2013 Richard W.M. Jones <rjones(a)redhat.com> - 0.9.0-3
- Default to using the appliance backend, since in Fedora >= 18 the
libvirt backend doesn't support the 'iface' parameter which virt-v2v
requires.
- Add BR perl(Sys::Syslog), required to run the tests.
- Remove some cruft from the spec file.
BTW in F20 we do have ova too:
virt-v2v-0.9.0-5.fc20.x86_64
and in fact it has the older version...
For RHEL 6 I remained here:
http://lists.ovirt.org/pipermail/users/2013-May/014457.html
ANd no particular virt-v2v package in rhev source repo
http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/
For sure the rhev 3.3 beta guide is incorrect at the moment
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Vir...
because it says
"
virt-v2v is available on Red Hat Network (RHN) in the Red Hat
Enterprise Linux Server (v.6 for 64-bit x86_64) or Red Hat Enterprise
Linux Workstation (v.6 for x86_64) channel. Ensure the system is
subscribed to the appropriate channel before installing virt-v2v.
"
and some lines below
"
7.1. virt-v2v Parameters
The following parameters can be used with virt-v2v:
-i input Specifies the input method to obtain the guest for
conversion. The default is libvirt. Supported options are:
libvirt
Guest argument is the name of a libvirt domain.
libvirtxml
Guest argument is the path to an XML file containing a libvirt domain.
ova
"
Any light to shed on this?
Thanks
Gianluca
I think I have some light, but you'd better get out your rose-colored
glasses, because that is the only way the light will look good. ;(
I spun up a Fedora 20 64-bit VM (in my brand new oVirt environment) to take
advantage of your wonderful discovery. I did a minimal install, then "yum
upgrade", then "yum install virt-v2v" brought in 489MB of dependencies!
This
is what I found (not necessarily in the order I found them).
1. virt-v2v has a missing dependency: perl-Archive-Tar
yum install perl-Archive-Tar
2. virt-v2v would error out fairly early in the conversion process:
Error extracting archive '/media/VMold/vmware.dud/Fedora13A.ova':
/usr/bin/tar: Fedora13A-disk1.vmdk: Wrote only 6144 of 10240 bytes
that error went away when I increased VM memory from 1G to 4G (see below).
3. The *.ova files produced by vmware-vdiskmanager build 835872 (downloaded
yesterday as part of VDDK 5.0) give the following error messages when running
through virt-v2v:
Use of uninitialized value $file in hash element at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line
261, <$manifest> line 2.
Reading from filehandle failed at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line
271.
Though I am not a Perl programmer, I took a look at the code, stuck in some
debugging "print" statements, and came to this conclusion:
The *.ova files produced by my version of vmware-vdiskmanager contain a
"blank" line at the end of the manifest with about 62 spaces in it
(nothing else). "sub _verify_manifest" in the file
"VMwareOVASource.pm"
it throws the error.
Since the line is supposed to have and "=" in it, I added "if ($line
=~
/=/){ .... } around lines 260-262. It works, though it may be very bad perl.
4. The perl code apparently attempts to extract the ENTIRE virtual disk into
memory. After implementing #3, I got errors:
line 109 Error extracting archive
'/media/VMold/vmware.dud/Fedora13A.ova': /usr/bin/tar:
Fedora13A-disk1.vmdk: Wrote only 2048 of 10240 bytes
/usr/bin/tar: Exiting with failure status due to previous errors
at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line
114.
Out of memory!
(in cleanup) open3: fork failed: Cannot allocate memory at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/ExecHelper.pm line 75.
I increased the VM memory from 1G to 4G. Processing a 6-8G virtual disk,
I ran "top" and watched the physical memory go from 3+G to 128K, then
watched the 1G of swap memory disappear, then got the error message above.
5. I chose one of my smallest .ova files (less than 1G), and it fit into
memory, so got past that error. Then I got to the final insult:
virt-v2v: RHEV cannot handle volumes of format vmdk
At that I threw in the towel.
I thought about filing on Bugzilla, but I don't know whether to file 1 bug or
5 or ....
To answer your question Gianluca, yes, I think I know why they pulled out the
*.ova support -- it doesn't work yet.
I checked, but VMWare still seems to be using the *.vmdk naming convention
for their disks, so I don't think I can find another name to make virt-v2v
happy. For now it looks like I am stuck, unless I bounce everything over to
my KVM+virt-manager host, and then import it from there.
That makes two days (at well over 8 hours each) that I have spent trying to
import my VMs, and so far I have nothing to show for my work.
Ted Miller
Elkhart, IN
--------------030307010403070106030205
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I am wide open to suggestions (see discussion at bottom, as usual).<br>
<br>
<div class="moz-cite-prefix">On 1/19/2014 5:25 AM, Gianluca Cecchi
wrote:<br>
</div>
<blockquote
cite="mid:CAG2kNCy2PT_V7cidY-hXYMk2asqO1hMWMdT7U0A0BKyVCBXGnw@mail.gmail.com"
type="cite">
<pre wrap="">On Sun, Jan 19, 2014 at 7:13 AM, Ted Miller wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
* BEAT HEAD AGAINST WALL because virt-v2v.x86_64 0.9.1-5.el6_5 from Centos
updates doesn't seem to know about .ova files. I was following the
instructions in
Red_Hat_Enterprise_Virtualization-3.3-Beta-V2V_Guide-en-US.pdf guide, but I
figured out that the v2v they are talking about has an "-i ova" option,
while the help file for the version I am using does not list ova as an
option for -i, and if I try to use it, it tells me that it is an invalid
option, and if I leave it off it goes off looking for a qemu///system to
attach to. help files for v2v say nothing at all about .ova files.
I am wondering where to find a v2v program that knows about .ova files, or
else am I going to have to import all my VMWare files to my (non-ovirt) KVM
host, and then drag them into ovirt from libvirt?
</pre>
</blockquote>
<pre wrap="">
I made a bit of research about this
Strange.... I just update a CentOS 6.4 VM to latest 6.5 and see that
there (also matching RHEL 6.5 I think) there is indeed as you wrote:
virt-v2v-0.9.1-5.el6_5.x86_64
And it seems ova is missing as an option...
Instead on a Fedora 19 system with
virt-v2v-0.9.0-3.fc19.x86_64
I have it....
So for any reason was it removed in newer packages?
It seems also strange to see a Fedora package (even if 19 and not 20)
older than a RH EL 6 one ...
RHEL 6 version bumped this way skipping 0.9.0:
* Wed Jun 12 2013 Matthew Booth <a class="moz-txt-link-rfc2396E"
href="mailto:mbooth@redhat.com"><mbooth@redhat.com></a> -
0.9.1-1
- Rebase to new upstream release
* Mon Oct 22 2012 Matthew Booth <a class="moz-txt-link-rfc2396E"
href="mailto:mbooth@redhat.com"><mbooth@redhat.com></a> -
0.8.9-2
while fedora 19 has been currently stopped at
* Wed Jul 03 2013 Richard W.M. Jones <a class="moz-txt-link-rfc2396E"
href="mailto:rjones@redhat.com"><rjones@redhat.com></a> -
0.9.0-3
- Default to using the appliance backend, since in Fedora >= 18 the
libvirt backend doesn't support the 'iface' parameter which virt-v2v
requires.
- Add BR perl(Sys::Syslog), required to run the tests.
- Remove some cruft from the spec file.
BTW in F20 we do have ova too:
virt-v2v-0.9.0-5.fc20.x86_64
and in fact it has the older version...
For RHEL 6 I remained here:
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/pipermail/users/2013-May/014457.html&qu...
ANd no particular virt-v2v package in rhev source repo
<a class="moz-txt-link-freetext"
href="http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/...
For sure the rhev 3.3 beta guide is incorrect at the moment
<a class="moz-txt-link-freetext"
href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Ent...
because it says
"
virt-v2v is available on Red Hat Network (RHN) in the Red Hat
Enterprise Linux Server (v.6 for 64-bit x86_64) or Red Hat Enterprise
Linux Workstation (v.6 for x86_64) channel. Ensure the system is
subscribed to the appropriate channel before installing virt-v2v.
"
and some lines below
"
7.1. virt-v2v Parameters
The following parameters can be used with virt-v2v:
-i input Specifies the input method to obtain the guest for
conversion. The default is libvirt. Supported options are:
libvirt
Guest argument is the name of a libvirt domain.
libvirtxml
Guest argument is the path to an XML file containing a libvirt domain.
ova
"
Any light to shed on this?
Thanks
Gianluca
</pre>
</blockquote>
I think I have some light, but you'd better get out your
rose-colored glasses, because that is the only way the light will
look good. ;(<br>
<br>
I spun up a Fedora 20 64-bit VM (in my brand new oVirt environment)
to take advantage of your wonderful discovery. I did a minimal
install, then "yum upgrade", then "yum install virt-v2v" brought
in
489MB of dependencies! This is what I found (not necessarily in the
order I found them).<br>
<br>
1. virt-v2v has a missing dependency: perl-Archive-Tar<br>
yum install perl-Archive-Tar<br>
<br>
2. virt-v2v would error out fairly early in the conversion process:<br>
<blockquote>Error extracting archive
'/media/VMold/vmware.dud/Fedora13A.ova': /usr/bin/tar:
Fedora13A-disk1.vmdk: Wrote only 6144 of 10240 bytes<br>
</blockquote>
that error went away when I increased VM memory from 1G to 4G
(see below).<br>
<br>
3. The *.ova files produced by vmware-vdiskmanager build 835872
(downloaded yesterday as part of VDDK 5.0) give the following error
messages when running through virt-v2v:<br>
<br>
<blockquote>Use of uninitialized value $file in hash element at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm
line 261, <$manifest> line 2.<br>
Reading from filehandle failed at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm
line 271.<br>
</blockquote>
Though I am not a Perl programmer, I took a look at the code, stuck
in some debugging "print" statements, and came to this
conclusion:<br>
<blockquote>The *.ova files produced by my version of
vmware-vdiskmanager contain a "blank" line at the end of the
manifest with about 62 spaces in it (nothing else). "sub
_verify_manifest" in the file "VMwareOVASource.pm" it throws the
error.<br>
<br>
Since the line is supposed to have and "=" in it, I added "if
($line =~ /=/){ .... } around lines 260-262. It works, though it
may be very bad perl.<br>
<br>
</blockquote>
4. The perl code apparently attempts to extract the ENTIRE virtual
disk into memory. After implementing #3, I got errors:<br>
<blockquote>line 109 Error extracting archive
'/media/VMold/vmware.dud/Fedora13A.ova': /usr/bin/tar:
Fedora13A-disk1.vmdk: Wrote only 2048 of 10240
bytes <br>
/usr/bin/tar: Exiting with failure status due to previous
errors <br>
at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm
line 114. <br>
Out of
memory!
<br>
(in cleanup) open3: fork failed: Cannot allocate memory at
/usr/share/perl5/vendor_perl/Sys/VirtConvert/ExecHelper.pm line
75.<br>
<br>
I increased the VM memory from 1G to 4G. Processing a 6-8G
virtual disk, I ran "top" and watched the physical memory go from
3+G to 128K, then watched the 1G of swap memory disappear, then
got the error message above.<br>
</blockquote>
5. I chose one of my smallest .ova files (less than 1G), and it fit
into memory, so got past that error. Then I got to the final
insult:<br>
<blockquote>virt-v2v: RHEV cannot handle volumes of format vmdk<br>
</blockquote>
At that I threw in the towel.<br>
<br>
I thought about filing on Bugzilla, but I don't know whether to file
1 bug or 5 or ....<br>
<br>
To answer your question Gianluca, yes, I think I know why they
pulled out the *.ova support -- it doesn't work yet.<br>
<br>
I checked, but VMWare still seems to be using the *.vmdk naming
convention for their disks, so I don't think I can find another name
to make virt-v2v happy. For now it looks like I am stuck, unless I
bounce everything over to my KVM+virt-manager host, and then import
it from there.<br>
<br>
That makes two days (at well over 8 hours each) that I have spent
trying to import my VMs, and so far I have nothing to show for my
work.<br>
<br>
Ted Miller<br>
Elkhart, IN<br>
<br>
</body>
</html>
--------------030307010403070106030205--
9:59 a.m.
https://rhn.redhat.com/errata/RHBA-2013-1749.html
"""
This update fixes the following bug:
* An update to virt-v2v included upstream support for the import of OVA images
exported by VMware servers. Unfortunately, testing has shown that VMDK images
created by recent versions of VMware ESX cannot be reliably supported, thus this
feature has been withdrawn. (BZ#1028983)
Users of virt-v2v are advised to upgrade to this updated package, which fixes
this bug.
"""
11:23 a.m.
FWIW, importing directly from an ESX server still works:
virt-v2v-host:
- RHEL/CentOS 6.5 physical host ( virt-v2v uses qemu-kvm = extra++ slow on a VM)
- Packages:
virt-v2v-0.9.1-5.el6_5.x86_64
libguestfs-winsupport-1.0-7.el6.x86_64
libguestfs-tools-c-1.20.11-2.el6.x86_64
libguestfs-tools-1.20.11-2.el6.x86_64
libguestfs-1.20.11-2.el6.x86_64
virtio-win-1.6.7-2.el6.noarch ( RHEL only? )
- network acces to:
oVirt export domain (NFS)
esx host(s) to import from (HTTPS)
- virt-v2v has to run as root to mount the oVirt NFS export domain
- Edit ~/.netrc and add a line for the esx host(s) to import from
(change the <> parts):
machine <esx.host.fqdn> login <esxuser> password <esxpassword>
- Fix permissions on netrc file:
chmod 600 ~/.netrc
- Run virt-v2v ( again: change the <> parts, ?no_verify=1 is needed
when esx uses self signed certs)
LIBGUESTFS_DEBUG=1 virt-v2v -ic esx://<esx.host.fqdn>/?no_verify=1 -o
rhev -os <rhev.export.domain.host:/var/exports/export_domain>
--network <target_network_name> <vmname>
Conversion can take quite some time after the disk copy,
especially when virt-v2v removes the vmware tools.
Running on a physical host (or using nested virtualization) helps.
On Mon, Jan 20, 2014 at 8:59 AM, Sander Grendelman
<sander(a)grendelman.com> wrote:
https://rhn.redhat.com/errata/RHBA-2013-1749.html
"""
This update fixes the following bug:
* An update to virt-v2v included upstream support for the import of OVA images
exported by VMware servers. Unfortunately, testing has shown that VMDK images
created by recent versions of VMware ESX cannot be reliably supported, thus this
feature has been withdrawn. (BZ#1028983)
Users of virt-v2v are advised to upgrade to this updated package, which fixes
this bug.
"""
4:56 p.m.
Unfortunately I have not ESX or ESXi server. These VMs were running on a
VMWare Server. Ted
On 1/20/2014 4:23 AM, Sander Grendelman wrote:
FWIW, importing directly from an ESX server still works:
virt-v2v-host:
- RHEL/CentOS 6.5 physical host ( virt-v2v uses qemu-kvm = extra++ slow on a VM)
- Packages:
virt-v2v-0.9.1-5.el6_5.x86_64
libguestfs-winsupport-1.0-7.el6.x86_64
libguestfs-tools-c-1.20.11-2.el6.x86_64
libguestfs-tools-1.20.11-2.el6.x86_64
libguestfs-1.20.11-2.el6.x86_64
virtio-win-1.6.7-2.el6.noarch ( RHEL only? )
- network acces to:
oVirt export domain (NFS)
esx host(s) to import from (HTTPS)
- virt-v2v has to run as root to mount the oVirt NFS export domain
- Edit ~/.netrc and add a line for the esx host(s) to import from
(change the <> parts):
machine <esx.host.fqdn> login <esxuser> password <esxpassword>
- Fix permissions on netrc file:
chmod 600 ~/.netrc
- Run virt-v2v ( again: change the <> parts, ?no_verify=1 is needed
when esx uses self signed certs)
LIBGUESTFS_DEBUG=1 virt-v2v -ic esx://<esx.host.fqdn>/?no_verify=1 -o
rhev -os <rhev.export.domain.host:/var/exports/export_domain>
--network <target_network_name> <vmname>
Conversion can take quite some time after the disk copy,
especially when virt-v2v removes the vmware tools.
Running on a physical host (or using nested virtualization) helps.
On Mon, Jan 20, 2014 at 8:59 AM, Sander Grendelman
<sander(a)grendelman.com> wrote:
> https://rhn.redhat.com/errata/RHBA-2013-1749.html
>
> """
> This update fixes the following bug:
>
> * An update to virt-v2v included upstream support for the import of OVA images
> exported by VMware servers. Unfortunately, testing has shown that VMDK images
> created by recent versions of VMware ESX cannot be reliably supported, thus this
> feature has been withdrawn. (BZ#1028983)
>
> Users of virt-v2v are advised to upgrade to this updated package, which fixes
> this bug.
> """
--
"He is no fool who gives what he cannot keep, to gain what he cannot lose." - -
Jim Elliot
For more information about Jim Elliot and his unusual life, see
http://www.christianliteratureandliving.com/march2003/carolyn.html.
Ted Miller
Design Engineer
HCJB Global Technology Center
2830 South 17th St
Elkhart, IN 46517
574--970-4272 my desk
574--970-4252 receptionist
11:43 a.m.
This is a multi-part message in MIME format.
------=_NextPartTM-000-ccd9a7a9-9ae2-40a0-a795-247b884365d5
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Von: users-bounces(a)ovirt.org [users-bounces(a)ovirt.org]&quot; im
Auftrag v=
on "Itamar Heim [iheim(a)redhat.com]=0A=
Gesendet: Freitag, 17. Januar 2014 16:19=0A=
An: users >> "users(a)ovirt.org"=0A=
Betreff: [Users] Making v2v easier?=0A=
=0A=
I see a lot of threads about v2v pains (mostly from ESX?)=0A=
=0A=
I'm interested to see if we can make this simpler/easier.=0A=
=0A=
if you have experience with this, please describe the steps you are=0A=
using (also the source platform), and how you would like to see this=0A=
make simpler (I'm assuming that would start from somewhere in the=0A=
webadmin probably).=0A=
=0A=
Thanks,=0A=
Itamar=0A=
=0A=
Hello,=0A=
=0A=
for me virt-v2v will be a one-timer until everything is migrated=0A=
into OVirt. If you had hard times to arrange everything and know=0A=
how to deal with it, the tool works quite well. Nevertheless for=0A=
for new users this can be very frustrating. =0A=
=0A=
The two most annoying things are for me:=0A=
=0A=
- Migration is sequential and slow. We have a lot of big SAP systems=0A=
with 250GB++. The infrastructure is backed by a 10G IPoIB network =0A=
that can easily copy files between NFS server at sustained speed of =0A=
500MB/s. virt-v2v cannot go beyond 40MB/s and thus about 2 hours=0A=
to migrate a machine. I understand that the process involves a "long" =0A=
chain ESXNFS->ESX->virt-v2v->OVirtNFS. Maybe one should think =0A=
of providing a parametrization to copy multiple disk images at the =0A=
same time. =0A=
=0A=
- Even worse is to wait 2 hours for the migration to finish and getting=0A=
afterwards errors about missing entries in virt-v2v.db or problems=0A=
during mount of the VM filesystems. Maybe the step or at least a check=0A=
could be issued after the migration of the (small) OS/boot disk.=0A=
=0A=
Markus=0A=
=0A=
------=_NextPartTM-000-ccd9a7a9-9ae2-40a0-a795-247b884365d5
Content-Type: text/plain;
name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="InterScan_Disclaimer.txt"
****************************************************************************
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
Über das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
Vorstand:
Kadir Akin
Dr. Michael Höhnerbach
Vorsitzender des Aufsichtsrates:
Hans Kristian Langva
Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
executive board:
Kadir Akin
Dr. Michael Höhnerbach
President of the supervisory board:
Hans Kristian Langva
Registry office: district court Cologne
Register number: HRB 52 497
****************************************************************************
------=_NextPartTM-000-ccd9a7a9-9ae2-40a0-a795-247b884365d5--
5:20 p.m.
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:
I see a lot of threads about v2v pains (mostly from ESX?)
I'm interested to see if we can make this simpler/easier.
if you have experience with this, please describe the steps you are
using (also the source platform), and how you would like to see this
make simpler (I'm assuming that would start from somewhere in the
webadmin probably).
Thanks,
Itamar
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3959
days inactive
3963
days old
16 comments
9 participants
participants (9)
-
Gianluca Cecchi -
Itamar Heim -
Markus Stockhausen -
Matthew Booth -
René Koch -
Richard W.M. Jones -
Sander Grendelman -
Sven Kieske -
Ted Miller