[Users] Making v2v easier?

Mon Jan 20 05:34:01 UTC 2014

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 at redhat.com> - 0.9.1-1
> - Rebase to new upstream release
>
> * Mon Oct 22 2012 Matthew Booth <mbooth at redhat.com> - 0.8.9-2
>
> while fedora 19 has been currently stopped at
>
> * Wed Jul 03 2013 Richard W.M. Jones <rjones at 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_Virtualization/3.2/html-single/V2V_Guide/index.html#chap-V2V_Guide-Installing_virt_v2v
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140120/7f8986aa/attachment-0001.html>