Bug 1550947 - Problems with CD attachment when Windows* 'Operating System' is chosen for VM
Summary: Problems with CD attachment when Windows* 'Operating System' is chosen for VM
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: 4.2.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Arik
QA Contact: meital avital
URL:
Whiteboard:
Depends On: 1552194
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-02 11:08 UTC by Radek Duda
Modified: 2018-04-16 12:15 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-04-16 12:15:58 UTC
oVirt Team: Virt
Embargoed:


Attachments (Terms of Use)
engine.log after step 2 (10.17 KB, text/plain)
2018-03-02 11:08 UTC, Radek Duda
no flags Details
engine.log after step 4 (13.81 KB, text/plain)
2018-03-02 11:12 UTC, Radek Duda
no flags Details
engine.log after step 8 (12.70 KB, text/plain)
2018-03-02 11:15 UTC, Radek Duda
no flags Details

Description Radek Duda 2018-03-02 11:08:13 UTC
Created attachment 1403002 [details]
engine.log after step 2

Description of problem:
If I choose Windows* operating system to VM, ovirt-engine attaches RHEV* CD from ISO domain. I do not know, if this is a proper behaviour as I cannot attach arbitrary CD then (I doubt it). 


Version-Release number of selected component (if applicable):
host (rhel7.5):
vdsm-4.20.19-1.el7ev.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.14.x86_64
libvirt-client-3.9.0-13.el7.x86_64

engine: rhv-4.2.2.1-0.1.el7
ovirt-engine-4.2.2.1-0.1.el7.noarch

How reproducible:
always

Steps to Reproduce:
1. Create some VM in RHV, set some Windows as 'Operating System'
2. run it -> to VM is attached latest RHEV* ISO ...!?
3. power VM down
4. Set 'Attach CD' and choose some arbitrary CD from the list, run VM
5. run it -> to VM is attached latest RHEV* ISO ...!? ..still
6. power VM down
7. Set some other OS as operating system (e.g. 'Other OS') or uncheck 'Attach CD'
8. run the VM


Actual results:
No CD is attached to VM (even if other OS is chosen in step 7.), error in engine.log. I didn't manage to find any way to attach any CD then except recreation of VM.

Expected results:
To VM is attached desired CD, no CD is attached if 'Attach CD' checkbox is unchecked

Additional info:

Comment 1 Radek Duda 2018-03-02 11:12:16 UTC
Created attachment 1403003 [details]
engine.log after step 4

RHEV-toolsSetup_4.1_5.iso is still attached (although different ISO image was chosen)
There is warning in the log:

2018-03-02 12:09:33,207+01 WARN  [org.ovirt.engine.core.vdsbroker.libvirt.VmDevicesConverter] (ForkJoinPool-1-worker-0) [] unmanaged disk with path '/rhev/data-center/mnt/10.37.175.3:_nfs_iso/b85e609a-c9dc-4d14-bfd9-03b6c2c93fba/images/11111111-1111-1111-1111-111111111111/RHEV-toolsSetup_4.1_5.iso' is ignored

Comment 2 Radek Duda 2018-03-02 11:15:42 UTC
Created attachment 1403004 [details]
engine.log after step 8

chosen 'Other OS' as 'Operating System'
error emerges:

2018-03-02 12:13:58,822+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmDevicesMonitoring] (ForkJoinPool-1-worker-4) [] VM 'd1d8018f-a24b-43e6-863f-8e861639fbfa' managed non pluggable device was removed unexpectedly from libvirt: 'VmDevice:{id='VmDeviceId:{deviceId='77975f08-db8e-4274-ad0d-01126a3af7b2', vmId='d1d8018f-a24b-43e6-863f-8e861639fbfa'}', device='cdrom', type='DISK', specParams='[path=w7_64_redmark_02.iso]', address='', managed='true', plugged='false', readOnly='true', deviceAlias='ide0-1-0', customProperties='[]', snapshotId='null', logicalName='null', hostDevice=''}'

Comment 3 Arik 2018-03-05 12:36:12 UTC
(In reply to Radek Duda from comment #0)
Radek, did you set the boot sequence of the VM to include a CD?
Please note the chooseCd method in [1] - the "attached CD" will actually be attached to the VM only if the VM is set to boot from CD (not necessarily as the first boot option though) or there is no RHV guest tools ISO to attach.
(just to be clear - I don't argue that this is the right behavior, I'm only saying that if the boot sequence doesn't include CD then the end-result is expected according to the code).

[1] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommand.java#L447

Comment 4 Arik 2018-03-05 12:39:27 UTC
(In reply to Radek Duda from comment #1)
> 2018-03-02 12:09:33,207+01 WARN 
> [org.ovirt.engine.core.vdsbroker.libvirt.VmDevicesConverter]
> (ForkJoinPool-1-worker-0) [] unmanaged disk with path
> '/rhev/data-center/mnt/10.37.175.3:_nfs_iso/b85e609a-c9dc-4d14-bfd9-
> 03b6c2c93fba/images/11111111-1111-1111-1111-111111111111/RHEV-toolsSetup_4.
> 1_5.iso' is ignored

That kind of errors are supposed to be fixed in the latest 4.2.2 build.

Comment 5 Radek Duda 2018-03-05 14:36:30 UTC
Hi Arik,
I tested the VM and it does not matter if CD is or is not in a boot sequence. CD could be attached even if it is not in boot sequence. For example I have chosen 'Operating system'='Other OS', first boot device='Network (PXE)', second boot device='[None]'. If I choose to not attach CD:
from XML:
..

    <disk type="file" device="cdrom" snapshot="no">
      <driver name="qemu" type="raw" error_policy="report"/>
      <source file="" startupPolicy="optional"/>
      <target dev="hdc" bus="ide"/>
      <readonly/>
      <address bus="1" controller="0" unit="0" type="drive" target="0"/>
    </disk>
..

if I attach CD (virtio-win-1.9.0.iso):

    <disk type="file" device="cdrom" snapshot="no">
      <driver name="qemu" type="raw" error_policy="report"/>
      <source file="/rhev/data-center/mnt/10.37.175.3:_nfs_iso/b85e609a-c9dc-4d14-bfd9-03b6c2c93fba/images/11111111-1111-1111-1111-111111111111/virtio-win-1.9.0.iso" startupPolicy="optional"/>
      <target dev="hdc" bus="ide"/>
      <readonly/>
      <address bus="1" controller="0" unit="0" type="drive" target="0"/>
    </disk>

so CD is attached even if I choose only Network (PXE) boot (like in the presented case)
that works, so try Windows machine now:


'Operating system'='Windows'*:

CD is not attached (and no CD in boot sequence):
...
    <disk type="file" device="cdrom" snapshot="no">
      <driver name="qemu" type="raw" error_policy="report"/>
      <source file="/rhev/data-center/mnt/10.37.175.3:_nfs_iso/b85e609a-c9dc-4d14-bfd9-03b6c2c93fba/images/11111111-1111-1111-1111-111111111111/RHEV-toolsSetup_4.1_5.iso" startupPolicy="optional"/>
      <target dev="hdc" bus="ide"/>
      <readonly/>
      <address bus="1" controller="0" unit="0" type="drive" target="0"/>
    </disk>
...
Why RHEV tools ISO is attached? Is it on purpose? If so, the code should be updated to search first for the latest RHV-toolsSetup* and not latest RHEV-toolsSetup* (I have both isos named like this in the directory)

if I attach CD (virtio-win-1.9.0.iso):
...
    <disk type="file" device="cdrom" snapshot="no">
      <driver name="qemu" type="raw" error_policy="report"/>
      <source file="/rhev/data-center/mnt/10.37.175.3:_nfs_iso/b85e609a-c9dc-4d14-bfd9-03b6c2c93fba/images/11111111-1111-1111-1111-111111111111/RHEV-toolsSetup_4.1_5.iso" startupPolicy="optional"/>
      <target dev="hdc" bus="ide"/>
      <readonly/>
      <address bus="1" controller="0" unit="0" type="drive" target="0"/>
    </disk>
...
As you said, if CD is not a boot device, "attached CD" should not be attached, but VM of 'Other OS' type behaves differently (see above). Actually I do not see any reason why not to attach CD if it is not in boot sequence (I like the way it behaves in case of OS other than Windows*). Attaching or not attaching CD should not depend on 'Operating system'. If 'attach CD' check-box is meant only for boot sequence, it should be disabled if CD-ROM is not chosen to the boot sequence then. But I would rather avoid it since apart from 'Change CD' in foreign menu this is the only way to attach CD to the VM.


if I uncheck 'Attach CD' checkbox then, no disk is present in XML and 

2018-03-05 14:16:32,993+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmDevicesMonitoring] (ForkJoinPool-1-worker-0) [] VM '3aa94ff7-8d25-413b-a343-7a1690919bfa' managed non pluggable device was removed unexpectedly from libvirt: 'VmDevice:{id='VmDeviceId:{deviceId='08cb9fdc-a458-486f-8d32-eaa41d8316ae', vmId='3aa94ff7-8d25-413b-a343-7a1690919bfa'}', device='cdrom', type='DISK', specParams='[path=virtio-win-1.9.0.iso]', address='', managed='true', plugged='false', readOnly='true', deviceAlias='ide0-1-0', customProperties='[]', snapshotId='null', logicalName='null', hostDevice=''}'

emerges in engine.log.

Moreover I am then unable to attach any CD to VM like this using foreign menu of remote-viewer ('Change CD' in its menu).

Comment 6 Arik 2018-03-05 14:57:34 UTC
(In reply to Radek Duda from comment #5)
Right, I forgot to mention that it indeed depends on the OS type - the RHV guest tools ISO is automatically attached only if the guest OS is Windows-based (and there is an active ISO domain that contains RHV guest tools ISO).

Comment 7 Arik 2018-03-05 15:07:59 UTC
(In reply to Radek Duda from comment #5)
Ah there are several parts there...

> Why RHEV tools ISO is attached? Is it on purpose? If so, the code should be
> updated to search first for the latest RHV-toolsSetup* and not latest
> RHEV-toolsSetup* (I have both isos named like this in the directory)

Yeah, that's a config value. If the tools' ISO name was changed and it has not been updated then it should.

> Moreover I am then unable to attach any CD to VM like this using foreign
> menu of remote-viewer ('Change CD' in its menu).

I guess that happens because of the issue you noted in comment 2 that causes the CD device to be unplugged (can you please verify that it is indeed the case, that the CD device is unplugged?) - that should be fixed in the latest 4.2.2 build.

Comment 8 Radek Duda 2018-03-05 15:36:31 UTC
yes this happened after
2018-03-05 14:16:32,993+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmDevicesMonitoring] (ForkJoinPool-1-worker-0) [] VM '3aa94ff7-8d25-413b-a343-7a1690919bfa' managed non pluggable device was removed unexpectedly from libvirt: 'VmDevice:{id='VmDeviceId:{deviceId='08cb9fdc-a458-486f-8d32-eaa41d8316ae', vmId='3aa94ff7-8d25-413b-a343-7a1690919bfa'}', device='cdrom', type='DISK', specParams='[path=virtio-win-1.9.0.iso]', address='', managed='true', plugged='false', readOnly='true', deviceAlias='ide0-1-0', customProperties='[]', snapshotId='null', logicalName='null', hostDevice=''}'

so no cd-rom device is attached to VM.


I think the issue that 'Attach CD' have no impact on Windows* VM (see step 5 from comment #0 or comment #5), while to 'Other OS' and linux VMs is CD attached should be corrected as well. What if user for examlple wants to use some different version of RHEV-tools..?

Comment 9 Arik 2018-03-05 15:45:19 UTC
(In reply to Radek Duda from comment #8)
> yes this happened after
> 2018-03-05 14:16:32,993+01 ERROR
> [org.ovirt.engine.core.vdsbroker.monitoring.VmDevicesMonitoring]
> (ForkJoinPool-1-worker-0) [] VM '3aa94ff7-8d25-413b-a343-7a1690919bfa'
> managed non pluggable device was removed unexpectedly from libvirt:
> 'VmDevice:{id='VmDeviceId:{deviceId='08cb9fdc-a458-486f-8d32-eaa41d8316ae',
> vmId='3aa94ff7-8d25-413b-a343-7a1690919bfa'}', device='cdrom', type='DISK',
> specParams='[path=virtio-win-1.9.0.iso]', address='', managed='true',
> plugged='false', readOnly='true', deviceAlias='ide0-1-0',
> customProperties='[]', snapshotId='null', logicalName='null', hostDevice=''}'
> 
> so no cd-rom device is attached to VM.

So please try that with latest 4.2.2 build.

> 
> 
> I think the issue that 'Attach CD' have no impact on Windows* VM (see step 5
> from comment #0 or comment #5),

It has an impact but only if the boot sequence includes CD-ROM or there is no RHV/ovirt guest tools available on the ISO domain.

> while to 'Other OS' and linux VMs is CD
> attached should be corrected as well. What if user for examlple wants to use
> some different version of RHEV-tools..?

Then the user can make the RHEV/ovirt tools he wants to use to be the latest one on the ISO domain.

Comment 10 Radek Duda 2018-03-06 15:44:10 UTC
> So please try that with latest 4.2.2 build.

I tried - the error is not there any more.
But after step 4. from commen #0 there is still attached RHEV-tools


> It has an impact but only if the boot sequence includes CD-ROM or there is
> no RHV/ovirt guest tools available on the ISO domain.

yes that is a point: 'Other OS' or Linux OS reacts differently on the checkbox then Windows OS. Linux attaches ISO from the list, while Windows not - unless there is chosen cd-rom as second boot device. Shouldn't we unify behaviour for all OSes there?

I think for Windows OS the best would be to detect, whether there is any RHEV-tools in ISO domain - if so, then automatically check 'Attach CD' checkbox and choose latest RHEV-tools ISO from the list next to checkbox by default (during VM creation period). User can then easily decide whether he wants to attach RHEV-tools and of what version or some different ISO. And it then behaves the same for all OSes - always attaches CD from the list if the checkbox is marked.

> 
> > while to 'Other OS' and linux VMs is CD
> > attached should be corrected as well. What if user for examlple wants to use
> > some different version of RHEV-tools..?
> 
> Then the user can make the RHEV/ovirt tools he wants to use to be the latest
> one on the ISO domain.

this is really awkward

Comment 11 Arik 2018-03-06 21:33:18 UTC
(In reply to Radek Duda from comment #10)
Radek, let's separate two different things:

1. Incorrect behavior: things that don't follow the design.
The error you've mentioned regarding unmanaged devices - obviously that's an incorrect behavior but seems to be fixed already.
Not being able to attach CD in step 4 - if the CD doesn't change when the boot sequence of the VM includes a CD then we have a regression and so it also belongs to this category.

2. Design changes: proposal to change the existing design.
For example, enabling to select RHV tools that are not the latest on the ISO domain, unifying things for different operating systems, etc.
As I wrote before, I agree with some of the things you wrote but they should be handled as separate RFEs and prioritized accordingly. IMHO, these are very low priority things that don't really affect our users/customers so they may not worth the time.

Comment 12 Radek Duda 2018-03-07 12:24:35 UTC
ok I have created RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1552600

Comment 13 Michal Skrivanek 2018-04-16 12:14:56 UTC
" If so, the code should be updated to search first for the latest RHV-toolsSetup* and not latest RHEV-toolsSetup* " - that's being addressed by bug 1552194

Comment 14 Michal Skrivanek 2018-04-16 12:15:58 UTC
the rest is tracked in the new RFE, I believe we do not need to keep this one open


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