RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1213701 - Fail to import win8/win2012 to rhev with error "selected display type is not supported"
Summary: Fail to import win8/win2012 to rhev with error "selected display type is not ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard: V2V
Depends On: 1211231
Blocks: 1288337
TreeView+ depends on / blocked
 
Reported: 2015-04-21 05:50 UTC by tingting zheng
Modified: 2016-11-03 17:50 UTC (History)
9 users (show)

Fixed In Version: libguestfs-1.32.5-5.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 17:50:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
sceenshot of error when try to import guest on rhev (71.47 KB, image/png)
2015-04-21 05:50 UTC, tingting zheng 		no flags Details
Debug log file of conversion win8 to rhev (377.43 KB, text/plain)
2015-04-21 05:52 UTC, tingting zheng 		no flags Details
osinfo file from rhev (15.66 KB, text/plain)
2015-04-22 04:57 UTC, tingting zheng 		no flags Details
Use virt-v2v-1.28.1-1.25 to convert win8 to rhev (379.27 KB, text/plain)
2015-04-23 09:28 UTC, tingting zheng 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2576 0 normal SHIPPED_LIVE Moderate: libguestfs and virt-p2v security, bug fix, and enhancement update 2016-11-03 12:06:51 UTC

Description tingting zheng 2015-04-21 05:50:47 UTC 
Created attachment 1016684 [details]
sceenshot of error when try to import guest on rhev

Description of problem:
Fail to import win8/win2012 to rhev with error "selected display type is not supported" 

Version-Release number of selected component (if applicable):
virt-v2v-1.28.1-1.28.el7.x86_64
libguestfs-1.28.1-1.28.el7.x86_64


How reproducible:
100%

Steps to Reproduce:
1.Use virt-v2v to convert a win8 guest to rhev.
# 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-28.log

2.Guest can be converted successfully,but on rhev try to import the guest,there is error:"selected display type is not supported",see the screenshot.

Actual results:
As decription.

Expected results:
win8/win2012 can be imported to rhev successfully.

Additional info:
1.Tried win8 and win2012,both fails to be imported with the error info.Not sure whether this is a regression caused by fix bug 1213324.
2.Tried win7,no such issue.
Comment 1 tingting zheng 2015-04-21 05:52:43 UTC 
Created attachment 1016685 [details]
Debug log file of conversion win8 to rhev
Comment 3 Richard W.M. Jones 2015-04-21 12:18:08 UTC 
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.
Comment 4 tingting zheng 2015-04-22 04:57:46 UTC 
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.
Comment 5 tingting zheng 2015-04-22 05:16:23 UTC 
(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.
Comment 6 Richard W.M. Jones 2015-04-22 12:41:02 UTC 
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>
Comment 7 Richard W.M. Jones 2015-04-22 14:01:23 UTC 
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.
Comment 8 Richard W.M. Jones 2015-04-22 15:02:44 UTC 
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>
Comment 9 Richard W.M. Jones 2015-04-22 15:14:53 UTC 
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).
Comment 10 tingting zheng 2015-04-23 08:20:29 UTC 
(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.
Comment 11 Richard W.M. Jones 2015-04-23 08:39:41 UTC 
(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.
Comment 12 tingting zheng 2015-04-23 08:47:27 UTC 
(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.
Comment 13 tingting zheng 2015-04-23 09:27:05 UTC 
(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
Comment 14 tingting zheng 2015-04-23 09:28:17 UTC 
Created attachment 1017824 [details]
Use virt-v2v-1.28.1-1.25 to convert win8 to rhev
Comment 15 Richard W.M. Jones 2015-04-23 09:48:24 UTC 
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.
Comment 16 Richard W.M. Jones 2015-04-23 09:49:26 UTC 
(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.
Comment 17 tingting zheng 2015-04-23 10:22:24 UTC 
(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>
Comment 18 Richard W.M. Jones 2015-04-23 10:26:39 UTC 
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.
Comment 20 Richard W.M. Jones 2016-06-22 14:26:56 UTC 
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.
Comment 22 mxie@redhat.com 2016-06-27 12:13:02 UTC 
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
Comment 24 errata-xmlrpc 2016-11-03 17:50:06 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.