Bug 1260590 - Wrong graphics protocal and video type set for guest after convert to rhev 3.6 by virt-v2v
Wrong graphics protocal and video type set for guest after convert to rhev 3....
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs (Show other bugs)
7.2
x86_64 Unspecified
high Severity high
: pre-dev-freeze
: 7.2
Assigned To: Richard W.M. Jones
Virtualization Bugs
V2V
:
Depends On: 1261446
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-07 06:37 EDT by tingting zheng
Modified: 2015-11-19 02:03 EST (History)
13 users (show)

See Also:
Fixed In Version: libguestfs-1.28.1-1.53.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 02:03:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
v2v debug info (8.89 KB, text/plain)
2015-09-07 06:37 EDT, tingting zheng
no flags Details
ovf file of guest in export domain (4.57 KB, text/plain)
2015-09-07 06:38 EDT, tingting zheng
no flags Details
screenshot1 of no graphics protocal and wrong video type (89.49 KB, image/jpeg)
2015-09-07 06:39 EDT, tingting zheng
no flags Details
screenshot2 of no graphics protocal and wrong video type (113.24 KB, image/jpeg)
2015-09-07 06:40 EDT, tingting zheng
no flags Details
new ovf file (4.76 KB, text/plain)
2015-09-09 00:20 EDT, zhoujunqin
no flags Details
screenshot3 for graphics protocoll is none (165.22 KB, image/png)
2015-09-09 00:21 EDT, zhoujunqin
no flags Details
v2v_debug_log (434.77 KB, text/plain)
2015-09-23 02:34 EDT, zhoujunqin
no flags Details
engine.log get from rhevm server (9.42 KB, text/plain)
2015-09-23 02:35 EDT, zhoujunqin
no flags Details

  None (edit)
Description tingting zheng 2015-09-07 06:37:52 EDT
Created attachment 1070939 [details]
v2v debug info

Description:
Wrong graphics protocal and video type set for guest after convert to rhev 3.6 by virt-v2v

Version:
libguestfs-1.28.1-1.51.el7.x86_64
libvirt-1.2.17-7.el7.x86_64
virt-v2v-1.28.1-1.51.el7.x86_64
rhevm-3.6.0-0.12.master.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1.Prepare a spice+qxl guest.
# virsh dumpxml rhel7.2
  <graphics type='spice' autoport='yes'>
      <image compression='off'/>
    </graphics>
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

2.Use virt-v2v to convert the guest to rhev3.6.
# virt-v2v -o rhev -os 10.66.4.243:/v2v_export -n ovirtmgmt rhel7.2 -v -x | tee /tmp/v2v-rhel7.2-new.log 

3.Check ovf file in export domain,it's qxl.
      <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>

4.After conversion,import the guest from export domain to data domain,the graphics protocal of guest is none and driver type is cirrus,so console will be disabled,see screenshot 1 and screenshot 2.

Actual results:
As description.

Expected results:
The graphics protocal and video type are kept the same after import guest from export domain.

Additional info:
The bug can not be reproduced on rhev 3.5.
Attached virt-v2v debug log and ovf file in export domain.
Comment 1 tingting zheng 2015-09-07 06:38:39 EDT
Created attachment 1070940 [details]
ovf file of guest in export domain
Comment 2 tingting zheng 2015-09-07 06:39:52 EDT
Created attachment 1070941 [details]
screenshot1 of no graphics protocal and wrong video type
Comment 3 tingting zheng 2015-09-07 06:40:27 EDT
Created attachment 1070943 [details]
screenshot2 of no graphics protocal and wrong video type
Comment 4 Richard W.M. Jones 2015-09-07 07:39:08 EDT
A question for the RHEV experts.  Is this XML correct (especially
ResourceType)?

      <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 5 Richard W.M. Jones 2015-09-07 08:19:38 EDT
(In reply to Richard W.M. Jones from comment #4)
> A question for the RHEV experts.  Is this XML correct (especially
> ResourceType)?
> 
>       <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>

OK I found the Ovirt_ovf_format.odt file and it suggests that
I need a <rasd:Type>Video</rasd:Type> field.  The rest appears OK.

The OvfReader class does consult the Type element, and other
bits of ovirt engine seem to check for it, eg:

  List<VmDevice> videoDevs = getDevicesOfType(VmDeviceGeneralType.VIDEO, vmBase.getManagedDeviceMap());

So I'll add that element.  Expert input from RHEV developers
still welcome!
Comment 6 Richard W.M. Jones 2015-09-07 10:12:49 EDT
Possible fix:
https://github.com/libguestfs/libguestfs/commit/829e3fe7a6ed834939a7a79e453ab873d3328ae1

It adds <Type>video</Type> (not rasd:Type as I said above).
Comment 7 Omer Frenkel 2015-09-08 02:55:29 EDT
You are right, the device type is missing (video)
but also, i see that 
<DefaultDisplayType>1</DefaultDisplayType>
which is cirrus, qxl should be 2
(see org.ovirt.engine.core.common.businessentities.DisplayType )

i guess this bug should be moved to v2v component?
Comment 8 Richard W.M. Jones 2015-09-08 04:07:26 EDT
(In reply to Omer Frenkel from comment #7)
> You are right, the device type is missing (video)

This one is fixed now upstream, but ...

> but also, i see that 
> <DefaultDisplayType>1</DefaultDisplayType>
> which is cirrus, qxl should be 2
> (see org.ovirt.engine.core.common.businessentities.DisplayType )

...! This contradicts the documentation :-(

From http://www.ovirt.org/Ovf :

  DefaultDisplayType: Number,  Display type: vnc = 0, qxl = 1

(which makes no sense because vnc and qxl aren't even the
same sort of thing).

Anyway I can fix this too.

> i guess this bug should be moved to v2v component?

Yes.
Comment 12 zhoujunqin 2015-09-09 00:19:21 EDT
I can reproduce this issue with package:
libguestfs-1.28.1-1.51.el7.x86_64
virt-v2v-1.28.1-1.51.el7.x86_64


Then try to verify this bug with new build:
libvirt-1.2.17-8.el7.x86_64
libguestfs-1.28.1-1.52.el7.x86_64
virt-v2v-1.28.1-1.52.el7.x86_64

Steps:
1.Prepare a spice+qxl guest.

# virsh dumpxml rhel6.7
...
    <graphics type='spice' autoport='yes'>
      <image compression='off'/>
    </graphics>
...
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
...

2.Use virt-v2v to convert the guest to rhev3.6.

# virt-v2v -o rhev -os 10.66.72.27:/home/nfsexport -n ovirtmgmt rhel6.7 -on rhel6.7-verify
[   0.0] Opening the source -i libvirt rhel6.7
[   0.0] Creating an overlay to protect the source from being modified
[   0.0] Opening the overlay
[   3.0] Initializing the target -o rhev -os 10.66.72.27:/home/nfsexport
virt-v2v: warning: cannot write files to the NFS server as 36:36, even 
though we appear to be running as root. This probably means the NFS client 
or idmapd is not configured properly.

You will have to chown the files that virt-v2v creates after the run, 
otherwise RHEV-M will not be able to import the VM.
[   3.0] Inspecting the overlay
[  11.0] Checking for sufficient free disk space in the guest
[  11.0] Estimating space required on target for each disk
[  11.0] Converting Red Hat Enterprise Linux Server release 6.7 (Santiago) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  42.0] Mapping filesystem data to avoid copying unused and blank areas
[  42.0] Closing the overlay
[  42.0] Checking if the guest needs BIOS or UEFI to boot
[  42.0] Copying disk 1/1 to /tmp/v2v.01d2RK/a7b42686-84d7-43f7-a8bd-49ee86572040/images/958d7597-8e45-4b0d-a8a2-8e0f3ad1b90d/89e08541-a803-440d-bcf3-e47bcb195f0e (qcow2)
    (100.00/100%)
[ 100.0] Creating output metadata
[ 100.0] Finishing off

3.After conversion,import the guest from export domain to data domain,check graphics protocal of guest and driver type.

Result after step3:
1.
Graphics protocol: none
Video Type: QXL

Since graphics protocol is none, i cannot connect to this vm. Please see Screenshot3.

2. Check .ovf file:
...
    <VmType>1</VmType>
    <DefaultDisplayType>2</DefaultDisplayType>
...
      <Item>
        <rasd:Caption>Graphical Controller</rasd:Caption>
        <rasd:InstanceId>b6fa7fae-9f32-4614-8f73-e305c28e500b</rasd:InstanceId>
        <rasd:ResourceType>20</rasd:ResourceType>
        <Type>video</Type>
        <rasd:VirtualQuantity>1</rasd:VirtualQuantity>
        <rasd:Device>qxl</rasd:Device>
      </Item>
And i will attach it.

So rjones please help check "Graphics protocol: none" issue, thanks.
Comment 13 zhoujunqin 2015-09-09 00:20:26 EDT
Created attachment 1071548 [details]
new ovf file
Comment 14 zhoujunqin 2015-09-09 00:21:19 EDT
Created attachment 1071549 [details]
screenshot3 for graphics protocoll is none
Comment 15 Richard W.M. Jones 2015-09-09 03:24:59 EDT
Omer: Any idea on why RHEV-M gives "Graphics protocol: none" for
this guest?  You can see the OVF that virt-v2v generates in comment 13.

I had a look at the ovirt-engine code, but it's a twisty maze of
inherited classes.
Comment 16 Richard W.M. Jones 2015-09-09 03:38:50 EDT
Actually I suspect we may need to add a new element to the OVF.
Something like this, but I'm not clear on the details:

<Item>
  <rasd:Caption>Graphical Framebuffer</rasd:Caption>
  <rasd:InstanceId>*GUID HERE*</rasd:InstanceId>
  <rasd:ResourceType>26</rasd:ResourceType>
  <Type>graphics</Type>
  <Device>spice</Device>
</Item>

Omer: Could you confirm that?
Comment 17 Omer Frenkel 2015-09-09 06:33:56 EDT
Excuse the slow response, i missed the updates on the bug..
looking deeper into this, it all seems like a bug in the new ovirt 3.6 feature of allowing spice+vnc for vms.
the DefaultDisplayType number change indeed breaks documentation and also backward compatibility, i will open a bug on this for ovirt to be fixed.
(to keep cirrus=0,qxl=1,vga=2)

it also cause the missing graphics that you see.
it is not a must to add the graphics device you suggest in comment 16
although it would be better, so the engine doesn't need to guess,
but there is a code that creates one if its not listed in the ovf (for backward compatibility) part of the bug is that this code creates the device but not saving it.

i will open a bug for all of the above and will add reference here as well
Comment 18 Omer Frenkel 2015-09-09 06:53:42 EDT
opened:
Bug 1261446 - VM display type changed on import to 3.6 from older version

for fixing regression in display type enumeration and missing graphics device.
Comment 19 Richard W.M. Jones 2015-09-09 08:50:58 EDT
Thanks Omer.

Upstream I changed the DefaultDisplayType back to 1, because we
always desire a qxl device for Windows guests:
https://github.com/libguestfs/libguestfs/commit/e3aee9c14d093d010349567b2f035defceef57df
Comment 20 zhoujunqin 2015-09-23 02:33:22 EDT
Since Bug 1261446 is ON_QA status now, then update my rhevm server to latest tree, with package version: rhevm-3.6.0-0.16.master.el6.noarch

Try to verify this bug with v2v version:
libvirt-1.2.17-9.el7.x86_64
libguestfs-1.28.1-1.55.el7.x86_64
qemu-kvm-rhev-2.3.0-24.el7.x86_64
virt-v2v-1.28.1-1.55.el7.x86_64

steps:
1. Prepare a spice+qxl guest.

# virsh dumpxml rhel7.2-0904

    <graphics type='spice' autoport='yes'>
      <image compression='off'/>
    </graphics>
...
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

2.Use virt-v2v to convert the guest to rhev3.6.
# virt-v2v  -o rhev -os 10.66.72.27:/home/nfsexport -n ovirtmgmt  rhel7.2-0904 -of raw -on rhel7.2-0904-import -v -x |& tee >rhel7.2-0904-import.log

3. After conversion, import guest.

Result: conversion finished successfully, but failed to import guest images with error message:
Failed to import Vm rhel7.2-0904-import to Data Center Default, Cluster Default

4. I will attach v2v debug log:rhel7.2-0904-import.log
   rhevm log when import guest:engine.log

so rjones, please help me have a look, thanks.
Comment 21 zhoujunqin 2015-09-23 02:34 EDT
Created attachment 1076090 [details]
v2v_debug_log
Comment 22 zhoujunqin 2015-09-23 02:35 EDT
Created attachment 1076091 [details]
engine.log get from rhevm server
Comment 23 tingting zheng 2015-09-27 23:17:54 EDT
Hi,Richard

Would you pls help to check comment 20,thanks.
Comment 24 Richard W.M. Jones 2015-09-28 05:06:37 EDT
It's hard to tell from the log, but do you think that
"ACTION_TYPE_FAILED_NAME_ALREADY_USED" means that another
VM with the same name already exists on the oVirt server?
Comment 25 tingting zheng 2015-09-28 05:36:22 EDT
(In reply to Richard W.M. Jones from comment #24)
> It's hard to tell from the log, but do you think that
> "ACTION_TYPE_FAILED_NAME_ALREADY_USED" means that another
> VM with the same name already exists on the oVirt server?

To avoid the above issue,I converted a new guest with another new name to ovirt 3.6,also failed to import to data domain.
Comment 26 Richard W.M. Jones 2015-09-28 10:50:25 EDT
I think this is a separate bug, so I opened: bug 1266930
Comment 27 zhoujunqin 2015-10-14 02:26:29 EDT
According to following message in .ovf file:
...
    <DefaultDisplayType>1</DefaultDisplayType>
...
the DefaultDisplayType has changed back to 1.

And for the import issue in Comment 20 has been tracked in another bug 1269948, move this bug from ON_QA to VERIFIED.
Comment 29 errata-xmlrpc 2015-11-19 02:03:36 EST
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/RHBA-2015-2183.html

Note You need to log in before you can comment on or make changes to this bug.