Bug 1958398 - "This VM has no graphic display device" error after upgrade from RHV 4.3 to RHV 4.4 for some VMs
Summary: "This VM has no graphic display device" error after upgrade from RHV 4.3 to R...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.4.4
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ovirt-4.4.8
: ---
Assignee: Shmuel Melamud
QA Contact: Guilherme Santos
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-07 20:08 UTC by Robert McSwain
Modified: 2024-06-14 01:29 UTC (History)
6 users (show)

Fixed In Version: ovirt-engine-4.4.8.3
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-09-08 14:12:04 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2021:3460 0 None None None 2021-09-08 14:12:16 UTC
oVirt gerrit 116013 0 master MERGED core: Plug video devices on import 2021-08-03 08:56:11 UTC

Description Robert McSwain 2021-05-07 20:08:34 UTC
Issue:
After upgrade to RHV 4.4 from 4.3, using Storage Domain importing, some VMs return "This VM has no graphic display device". upon attempting to open a console for the VM

Customer has found that putting these VMs back in a 4.3 environment returns them to working normally: 

> I detached the storage domain from RHV-4.4 and attached it back to RHV-4.3. 

> After I imported and started VMs in RHV-4.4, I realized that I couldn't access some of them with the console.  See attached screenshot, the error is "This VM has no graphic display device".

> I've re-created the console issue with a test storage domain.  When its storage domain is attached to RHV-4.3, the console works.  But once it's attached to RHV-4.4, I'm getting that "This VM has no graphic display device" error. 

Workarounds:

Customer has found that a new VM in the environment does not have this issue, and further that enabling and disabling "Headless mode" permanently resolves this issue for VMs: 

> I enabled "headless mode" for the original VM in trouble, started it up, shut it down, disabled "headless mode" - the issue was resolved, the console works now.

All VMs affected by this do need a full VM reboot and 'headless' state change to resolve the issue.

Comment 2 Arik 2021-05-09 20:54:48 UTC
Looking at the database, the first problematic VM is set with:
arik=# select type, device, is_managed, is_plugged from vm_device where vm_id='a79973de-278f-4252-a657-3d231291aef5';
    type    |    device     | is_managed | is_plugged 
------------+---------------+------------+------------
 video      | qxl           | t          | f
 graphics   | spice         | t          | t
 graphics   | vnc           | t          | t
 controller | usb           | t          | t

The fact that the video/qxl device is unplugged, together with the fix for bz 1729424 explains why the VM starts with:
<video>
  <model type="none"/>
</video>

However, it is not clear why the video device of the imported VM is set as unplugged (it is set as unplugged during import for sure, since we see video with model.type=none at the first attempt to run the VM after it's imported).

Comment 4 Arik 2021-05-10 11:11:48 UTC
Need to think if this might be related somehow to bz 1844274

Comment 8 Arik 2021-06-27 16:49:03 UTC
(In reply to Arik from comment #2)
> (it is set as unplugged during import for sure, since we see video
> with model.type=none at the first attempt to run the VM after it's imported).

OK, so this part is incorrect.
The device could not get unplugged during import, we import the devices as they are in the OVF.
This means the video device must have been unplugged during the time the VM was in the 4.3 environment (one way that leads to that is running the VM with run-once + headless mode).
In 4.3, in case a VM without no plugged device is started, the VM gets an unmanaged cirrus device (that's why from the user's point of view it appeared as it worked on the 4.3 environment).
However, due to bz 1729424, such VM starts in 4.4 with video device with model=none and thus the console doesn't work.

As video devices are not hot-pluggable, we can safely set them as plugged on import to overcome this issue.

Comment 10 Guilherme Santos 2021-08-24 19:25:55 UTC
Verified on:
ovirt-engine-4.4.8.1-0.9.el8ev.noarch

Steps:
1. created two VMs on a 4.3.11 env
2. set one vm as headless mode and left the other vm as default console configuration
3. exported the vms and imported in the 4.4.8 env
4. run both vms

Results:
both vms started successfully

Comment 11 Arik 2021-08-25 07:42:00 UTC
(In reply to Guilherme Santos from comment #10)
> Verified on:
> ovirt-engine-4.4.8.1-0.9.el8ev.noarch
> 
> Steps:
> 1. created two VMs on a 4.3.11 env
> 2. set one vm as headless mode and left the other vm as default console
> configuration

I'm afraid that doesn't produce the desired state -
we want to have a video device set as unplugged in 4.3.11
when you set the VM as headless, there is no video device and with default console configuration there is a plugged video device.

So can please check in the vm devices tab whether the video device of any of these VMs was unplugged?
If it's not unplugged then a possible way to achieve this is by creating a VM with default console and then start it in run-once mode as headless

> 3. exported the vms and imported in the 4.4.8 env
> 4. run both vms
> 
> Results:
> both vms started successfully

We don't only need to check that the VM starts but also that we can open a console to that VM

Comment 12 Arik 2021-08-25 09:40:28 UTC
Moving back to ON_QA for visibility

Comment 14 Guilherme Santos 2021-09-06 11:44:58 UTC
Hi Arik, thank you for all the info. Indeed, I checked the video device in the 4.3.11 vm and it was plugged.
I retested from scratch following the step you mentioned (VM with default configurations and run once as headless) and I confirmed that device was unplugged before I exported the VM.
Then, I imported the vm in the 4.4.8 env successfully, also ran it and consoled on it successfully
So verified (same versions as comment #10).

Comment 18 errata-xmlrpc 2021-09-08 14:12:04 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 (RHV Manager (ovirt-engine) [ovirt-4.4.8]), 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://access.redhat.com/errata/RHBA-2021:3460

Comment 19 meital avital 2022-08-08 20:02:33 UTC
Due to QE capacity, we are not going to cover this issue in our automation


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