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:
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
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=''}'
(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
(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.
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).
(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).
(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.
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..?
(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.
> 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
(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.
ok I have created RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1552600
" 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
the rest is tracked in the new RFE, I believe we do not need to keep this one open