Bug 1260590

Created attachment 1070940 [details]
ovf file of guest in export domain

Created attachment 1070941 [details]
screenshot1 of no graphics protocal and wrong video type

Created attachment 1070943 [details]
screenshot2 of no graphics protocal and wrong video type

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>

(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!

Possible fix:
https://github.com/libguestfs/libguestfs/commit/829e3fe7a6ed834939a7a79e453ab873d3328ae1

It adds <Type>video</Type> (not rasd:Type as I said above).

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?

(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.

Fixed upstream:

https://github.com/libguestfs/libguestfs/commit/829e3fe7a6ed834939a7a79e453ab873d3328ae1
https://github.com/libguestfs/libguestfs/commit/c4bc8116d9d586085f96da2e5558c9b366e84925

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.

Created attachment 1071548 [details]
new ovf file

Created attachment 1071549 [details]
screenshot3 for graphics protocoll is none

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.

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?

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

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.

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

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.

Created attachment 1076090 [details]
v2v_debug_log

Created attachment 1076091 [details]
engine.log get from rhevm server

Hi,Richard

Would you pls help to check comment 20,thanks.

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?

(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.

I think this is a separate bug, so I opened: bug 1266930

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.

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