<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">&lt;mbooth@redhat.com&gt;</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">&lt;mbooth@redhat.com&gt;</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">&lt;rjones@redhat.com&gt;</a> - 0.9.0-3
- Default to using the appliance backend, since in Fedora &gt;= 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">http://lists.ovirt.org/pipermail/users/2013-May/014457.html</a>

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/SRPMS/">http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/</a>

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_Enterprise_Virtualization/3.2/html-single/V2V_Guide/index.html#chap-V2V_Guide-Installing_virt_v2v">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</a>

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, &lt;$manifest&gt; 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>