Bug 1596234

Not sure if related: https://gerrit.ovirt.org/#/c/92445/

Working on reproducing it.

(Originally by Germano Veit Michel)

Didn't reproduce following the same events on our labs. I'll attach vdsm logs.

(Originally by Germano Veit Michel)

(In reply to Germano Veit Michel from comment #3)
> Didn't reproduce following the same events on our labs. I'll attach vdsm
> logs.

Germano, note that this VM must have been started before the engine was updated to 4.2.3 (because the alias of the cd-rom is 'ide0-1-0' rather than a user-lias like 'ua-923802b9-9b05-4a6b-b67b-f2caa1b65578'). It is unlikely to happen for VMs that are started in 4.2.3 and above since we now use user-aliases. So this should be taken into account while trying to reproduce that.

(Originally by Arik Hadas)

(In reply to Germano Veit Michel from comment #0)
> 2018-06-13 09:07:06,632+10 WARN 
> [org.ovirt.engine.core.vdsbroker.libvirt.VmDevicesConverter]
> (EE-ManagedThreadFactory-engineScheduled-Thread-50) [] unmanaged disk with
> path '' is ignored    

This means that we got a device without ID or with a different ID than it used to have before.

> 
> 2018-06-13 09:07:06,638+10 ERROR
> [org.ovirt.engine.core.vdsbroker.monitoring.VmDevicesMonitoring]
> (EE-ManagedThreadFactory-engineScheduled-Thread-50) [] VM
> '33f4ee96-4863-48a8-ae9f-f67a341afc62' managed non pluggable device was
> removed unexpectedly from libvirt:
> 'VmDevice:{id='VmDeviceId:{deviceId='923802b9-9b05-4a6b-b67b-f2caa1b65578',
> vmId='33f4ee96-4863-48a8-ae9f-f67a341afc62'}', device='cdrom', type='DISK',
> specParams='[path=rhel-server-7.4-x86_64-dvd.iso]', address='',
> managed='true', plugged='false', readOnly='true', deviceAlias='ide0-1-0',
> customProperties='[]', snapshotId='null', logicalName='null', hostDevice=''}'

This means that no device was reported with the ID 923802b9-9b05-4a6b-b67b-f2caa1b65578 so we have no correlation for the cd-rom in the database and therefore unplug it.

This reminds me of previous bugs we had where the ID of devices of VMs that were started in previous versions was not preserved when those VMs were migrated to a new version of VDSM.

Milan, were the fixes in that area already available in 4.2.3?

(Originally by Arik Hadas)

Germano, can you please check if the CDROM was ejected? I.e. bug 1593568

(Originally by michal.skrivanek)

(In reply to Arik from comment #6)
> (In reply to Germano Veit Michel from comment #3)
> > Didn't reproduce following the same events on our labs. I'll attach vdsm
> > logs.
> 
> Germano, note that this VM must have been started before the engine was
> updated to 4.2.3 (because the alias of the cd-rom is 'ide0-1-0' rather than
> a user-lias like 'ua-923802b9-9b05-4a6b-b67b-f2caa1b65578'). It is unlikely
> to happen for VMs that are started in 4.2.3 and above since we now use
> user-aliases. So this should be taken into account while trying to reproduce
> that.

Ohh, I would never had noticed this! Thanks, I can try again tomorrow if you think it's necessary.

(In reply to Michal Skrivanek from comment #8)
> Germano, can you please check if the CDROM was ejected? I.e. bug 1593568

Yes it was ejected (no path).

(Originally by Germano Veit Michel)

(In reply to Arik from comment #7)
> This reminds me of previous bugs we had where the ID of devices of VMs that
> were started in previous versions was not preserved when those VMs were
> migrated to a new version of VDSM.
> 
> Milan, were the fixes in that area already available in 4.2.3?

Well, that is incorrect since we're talking about cluster level 4.2 so the engine ignores the device IDs. Need to improve the correlation logic for cd-roms.

(Originally by Arik Hadas)

(In reply to Michal Skrivanek from comment #8)
> Germano, can you please check if the CDROM was ejected? I.e. bug 1593568

This is not related to that bug -- <source> element is present in the domain XML.

(Originally by Milan Zamazal)

Verified:
rhvm-4.2.5-0.1.el7ev
vdsm-4.20.33-1.el7ev.x86_64
libvirt-client-3.9.0-14.el7_5.6.x86_64
qemu-kvm-rhev-2.10.0-21.el7_5.4.x86_64
sanlock-3.6.0-1.el7.x86_64

Verification scenario: 
1. Run VM with cdrom device.
2. Upgrade CL from 4.1 to 4.2.
3. Verify cdrom device is still available and accessible from VM. 
   Migrate VM.
4. Verify cdrom device is available and accessible from VM.
   Reboot VM.
5. After VM reboot completed, verify cdrom device is available and accessible.
Verify cdrom device is listed in engine db:
engine=# select device_id,device,address,is_managed,is_plugged,_update_date,alias from vm_device WHERE vm_id ='c4608698-f036-4345-b52a-c71c2cb4c00c' AND device ='cdrom';
              device_id               | device |                       address                       | is_managed | is_plugged |         _update_date          |  alias   
--------------------------------------+--------+-----------------------------------------------------+------------+------------+-------------------------------+----------
 be5e4018-4c12-4b4d-81d8-2309ab00cafa | cdrom  | {type=drive, bus=1, controller=0, target=0, unit=0} | t          | t          | 2018-07-10 13:35:44.498705+03 | ide0-1-0
(1 row)

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://access.redhat.com/errata/RHBA-2018:2318