Bug 1213701

Created attachment 1016685 [details]
Debug log file of conversion win8 to rhev

Tingting, sorry about this.  Could you attach a copy of the
following file, which should be on your RHEV-M server:

  /usr/share/ovirt-engine/conf/osinfo-defaults.properties

(It might be in another location, but there should be
a symlink from /etc/ovirt-engine/osinfo.conf.d/... to
the file)

I already have this file from my RHEV-M, but my RHEV-M is
somewhat old, so maybe the contents are different.

Created attachment 1017228 [details]
osinfo file from rhev

Attached the file,my rhev version is 3.4 which is also not the latest,as some debug work is ongoing,I will update it to 3.5 later.

(In reply to tingting zheng from comment #4)
> Created attachment 1017228 [details]
> osinfo file from rhev
> 
> Attached the file,my rhev version is 3.4 which is also not the latest,as
> some debug work is ongoing,I will update it to 3.5 later.

Wrong,rhev version should be 3.5.0-0.32.el6ev.

FWIW virt-v2v (current version and the old version) ignores the
source VM's display, and always adds a qxl device:

            <Item>
                <rasd:Caption>Graphical Controller</rasd:Caption>
                <rasd:InstanceId>5</rasd:InstanceId>
                <rasd:ResourceType>20</rasd:ResourceType>
                <rasd:VirtualQuantity>1</rasd:VirtualQuantity>
                <rasd:Device>qxl</rasd:Device>
            </Item>

Arik or Shahar, do you have any idea about this bug?

My findings so far:

(1) virt-v2v (new and old) always adds a qxl device to the OVF.
If the guest previously had cirrus, or nothing, it is changed to qxl.
(Note this statement only applies to -o rhev & -o vdsm)

(2) In the osinfo file on ovirt, all the Windows >= 8 versions have
something like this:

os.windows_8.devices.display.protocols.value = vnc/cirrus

But not Windows <= 7 versions.

(3) In ovirt-engine, there appears to be some code checking the
osinfo database, and rejecting the guest with the error in this
bug.

Is this a bug in virt-v2v?  OVirt?  osinfo?  Something else?  Any light
you can shed on this would be welcome.

To sum up what we discussed on IRC, my analysis in comment 7 is
correct.  Because there are no qxl drivers for Windows >= 8, oVirt
actively denies this configuration.

Instead we will need to change virt-v2v so it adds a Cirrus card
to Windows >= 8 guests.  The Cirrus configuration looks like this:

15:52 < ahadas> <Item>
15:52 < ahadas>         <rasd:Caption>Graphical Controller</rasd:Caption>
15:52 < ahadas>         <rasd:InstanceId>30c2c435-8aa5-453e-905f-13451229f57b</rasd:InstanceId>
15:52 < ahadas>         <rasd:ResourceType>20</rasd:ResourceType>
15:52 < ahadas>         <rasd:VirtualQuantity>1</rasd:VirtualQuantity>
15:52 < ahadas>         <rasd:SinglePciQxl>false</rasd:SinglePciQxl>
15:52 < ahadas>         <Type>video</Type>
15:52 < ahadas>         <Device>cirrus</Device>
15:52 < ahadas>         <rasd:Address/>
15:52 < ahadas>         <BootOrder>0</BootOrder>
15:52 < ahadas>         <IsPlugged>true</IsPlugged>
15:52 < ahadas>         <IsReadOnly>true</IsReadOnly>
15:52 < ahadas>         <Alias/>
15:52 < ahadas>         <SpecParams>
15:52 < ahadas>           <vram>32768</vram>
15:52 < ahadas>           <heads>1</heads>
15:52 < ahadas>         </SpecParams>
15:52 < ahadas>       </Item>
15:52 < ahadas>       <Item>
15:52 < ahadas>  <Item>
15:52 < ahadas>         <rasd:Caption>Graphical Framebuffer</rasd:Caption>
15:52 < ahadas>         <rasd:InstanceId>a4abe425-b034-4ba0-bc7d-a3df5b61585d</rasd:InstanceId>
15:52 < ahadas>         <rasd:ResourceType>26</rasd:ResourceType>
15:52 < ahadas>         <Type>graphics</Type>
15:52 < ahadas>         <Device>vnc</Device>
15:52 < ahadas>         <rasd:Address/>
15:52 < ahadas>         <BootOrder>0</BootOrder>
15:52 < ahadas>         <IsPlugged>true</IsPlugged>
15:52 < ahadas>         <IsReadOnly>false</IsReadOnly>
15:52 < ahadas>         <Alias/>
15:52 < ahadas>       </Item>

There's an RFE against RHEV-M (supposed to be fixed in 3.5.z)
to enable qxl support for those guests, so we won't need to fix
this in virt-v2v.  Just retest this when the dependent bug
has been fixed (bug 1211231).

(In reply to Richard W.M. Jones from comment #8)
> To sum up what we discussed on IRC, my analysis in comment 7 is
> correct.  Because there are no qxl drivers for Windows >= 8, oVirt
> actively denies this configuration.

Do you mean for all windows>=8,I remember when I verify bug 1190669 with libguestfs-1.28.1-1.25.el7.x86_64+virt-v2v-1.28.1-1.25.el7.x86_64,I can import win8 and win2012R2 guests to rhev with display type as spice.

(In reply to tingting zheng from comment #10)
> (In reply to Richard W.M. Jones from comment #8)
> > To sum up what we discussed on IRC, my analysis in comment 7 is
> > correct.  Because there are no qxl drivers for Windows >= 8, oVirt
> > actively denies this configuration.
> 
> Do you mean for all windows>=8,I remember when I verify bug 1190669 with
> libguestfs-1.28.1-1.25.el7.x86_64+virt-v2v-1.28.1-1.25.el7.x86_64,I can
> import win8 and win2012R2 guests to rhev with display type as spice.

https://bugzilla.redhat.com/show_bug.cgi?id=1190669#c5

AIUI two of those tests output to RHEV, and 5 of the tests output
to local libvirt.

Output to local libvirt is unaffected by this bug.

Output to RHEV currently always adds a qxl card.  If the guest is
Windows >= 8, then you would expect to see this bug.  If it worked,
then that's magic, or something else is going on: for example --
is there some option to override or ignore the display type when
importing from the Export Storage Domain? or it could be an earlier
version of RHEV which didn't know about Windows >= 8 and so wouldn't
have the restriction in the osinfo file.

(In reply to Richard W.M. Jones from comment #11)
> (In reply to tingting zheng from comment #10)
> > (In reply to Richard W.M. Jones from comment #8)
> > > To sum up what we discussed on IRC, my analysis in comment 7 is
> > > correct.  Because there are no qxl drivers for Windows >= 8, oVirt
> > > actively denies this configuration.
> > 
> > Do you mean for all windows>=8,I remember when I verify bug 1190669 with
> > libguestfs-1.28.1-1.25.el7.x86_64+virt-v2v-1.28.1-1.25.el7.x86_64,I can
> > import win8 and win2012R2 guests to rhev with display type as spice.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1190669#c5
> 
> AIUI two of those tests output to RHEV, and 5 of the tests output
> to local libvirt.
> 
> Output to local libvirt is unaffected by this bug.
> 
> Output to RHEV currently always adds a qxl card.  If the guest is
> Windows >= 8, then you would expect to see this bug.  If it worked,
> then that's magic, or something else is going on: for example --
> is there some option to override or ignore the display type when
> importing from the Export Storage Domain? or it could be an earlier
> version of RHEV which didn't know about Windows >= 8 and so wouldn't
> have the restriction in the osinfo file.

:-),I will downgrade libguestfs and try it later.

(In reply to Richard W.M. Jones from comment #11)
> (In reply to tingting zheng from comment #10)
> > (In reply to Richard W.M. Jones from comment #8)
> > > To sum up what we discussed on IRC, my analysis in comment 7 is
> > > correct.  Because there are no qxl drivers for Windows >= 8, oVirt
> > > actively denies this configuration.
> > 
> > Do you mean for all windows>=8,I remember when I verify bug 1190669 with
> > libguestfs-1.28.1-1.25.el7.x86_64+virt-v2v-1.28.1-1.25.el7.x86_64,I can
> > import win8 and win2012R2 guests to rhev with display type as spice.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1190669#c5
> 
> AIUI two of those tests output to RHEV, and 5 of the tests output
> to local libvirt.
> 
> Output to local libvirt is unaffected by this bug.
> 
> Output to RHEV currently always adds a qxl card.  If the guest is
> Windows >= 8, then you would expect to see this bug.  If it worked,
> then that's magic, or something else is going on: for example --
> is there some option to override or ignore the display type when
> importing from the Export Storage Domain? or it could be an earlier
> version of RHEV which didn't know about Windows >= 8 and so wouldn't
> have the restriction in the osinfo file.

Downgrade virt-v2v to:
libguestfs-1.28.1-1.25.el7.x86_64
virt-v2v-1.28.1-1.25.el7.x86_64

Use virt-v2v to convert the same guest and it can be imported rhev successfully.
# virt-v2v -ic xen+ssh://10.66.106.64 -o rhev -os 10.66.90.115:/vol/v2v_auto/auto_export -n rhevm xen-hvm-win8-i386 -of raw -v -x |& tee /tmp/virt-v2v-25.log

Created attachment 1017824 [details]
Use virt-v2v-1.28.1-1.25 to convert win8 to rhev

I don't know why -1.25 would work but -1.28 would not work.  There
are no changes to the OVF generated between the two versions.  There
must be something else going on in your test environment.

(In reply to Richard W.M. Jones from comment #15)
> I don't know why -1.25 would work but -1.28 would not work.  There
> are no changes to the OVF generated between the two versions.  There
> must be something else going on in your test environment.

You could try grabbing the .ovf file from /vol/v2v_auto/auto_export/.....
and see if there are any differences, but as far as I can tell from the
code, there shouldn't be.

(In reply to Richard W.M. Jones from comment #16)
> (In reply to Richard W.M. Jones from comment #15)
> > I don't know why -1.25 would work but -1.28 would not work.  There
> > are no changes to the OVF generated between the two versions.  There
> > must be something else going on in your test environment.
> 
> You could try grabbing the .ovf file from /vol/v2v_auto/auto_export/.....
> and see if there are any differences, but as far as I can tell from the
> code, there shouldn't be.

Compared the ovf with the above 2 versions of virt-v2v,finally found the difference.
With virt-v2v-1.28.1-1.25.el7.x86_64,it sets the guests description as "Unassigned".
 <Info>Guest Operating System</Info>
      <Description>Unassigned</Description>
    </Section>

With virt-v2v-1.28.1-1.25.el7.x86_64,it sets as Windows8.
    <Info>Guest Operating System</Info>
      <Description>Windows8</Description>
    </Section>

Oh I see.  So this is expected.

Bug 1213324 fixed the <Description> field in the OVF, and that fix
was added in -1.27.

When ovirt-engine sees the <Description> field, it looks it up in
the osinfo file.  If the description is "Unassigned" then it won't
match a line containing:

os.windows_8.devices.display.protocols.value = vnc/cirrus

If the description is "Windows8" (or similar) it would hit the above
line.

When ovirt-engine matches that line, it outputs the error in this
bug.

Anyway, this doesn't change what I said in comment 9.  We need to
wait for the dependent bug to be fixed before this bug can be tested.
No change is required for virt-v2v.

I believe:

 - The dependent bug has been fixed in oVirt.

 - There's no work to be done in virt-v2v.

 - It just needs to be retested with the latest virt-v2v & RHEV.

Therefore I'm dev-acking this bug and putting it in MODIFIED, but
there is no actual change to virt-v2v.

According to comment 20

Verify the bug with builds
virt-v2v-1.32.5-6.el7.x86_64
libguestfs-1.32.5-6.el7.x86_64
RHEVM: 3.6.7.2-0.1.el6

Steps:
1.Use virt-v2v to convert win8 and win2012 guest to rhev
1.1 # virt-v2v -ic vpx://root.145.47/data/10.66.4.153/?no_verify=1 esx5.1-win8-x86_64 -o rhev -os 10.73.72.63:/home/nfs_export -on win8-mxie -of raw --password-file /tmp/passwd
1.2 # virt-v2v -ic vpx://root.145.47/data/10.66.4.153/?no_verify=1 esx5.1-win2012-x86_64 -o rhev -os 10.73.72.63:/home/nfs_export -on win2012-mxie -of raw --password-file /tmp/passwd


2.After conversion,import the guests from export domain to data domain successfully 

Result now:
According to step2, the bug has been fixed

So move the bug from ON_QA to VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2576.html