Description of problem: RHEV-toolsSetup*.iso has been recently renamed to RHV-toolsSetup*.iso. VM of Windows OS type automatically attaches latest RHEV-toolsSetup*.iso upon start. The name of iso to attach should be now updated to RHV-toolsSetup*.iso, so that if no RHV-toolsSetup*.iso is found then it searches for older RHEV-toolsSetup*.iso Version-Release number of selected component (if applicable): rhv-4.2.2.2-0.1.el7 ovirt-engine-4.2.2.2-0.1.el7.noarch How reproducible: always Steps to Reproduce: 1. have both new RHV-toolsSetup*.iso and older RHEV-toolsSetup*.iso in ISO domain 2.start VM of 'Operating system'=Windows* type Actual results: attached CD to VM is latest RHEV-toolsSetup*.iso Expected results: attached CD to VM is latest RHV-toolsSetup*.iso Additional info:
when exactly does it attach that CD automatically for you? do you have an example?
The CD is attached in the case that any RHEV-toolsSetup*.iso is found in ISO domain, VM is of Windows* type (choose 'Operatin System' = Windows* in VM editor) . I have both RHEV-toolsSetup*.iso and RHV-toolsSetup*.iso and it attaches the older ISO.
right, but per current doc (which is wrong, IMO) you're supposed to upload rhev-guest-tools.iso. I expect that in that case the feature of automatically updating guest tools do not actually work. For a looong time, so apparently we do not have a test case for that!
Lev, this seem to be broken for a long time. What would it take to fix that functionality? Can you please summarize how the tools iso is named, how does the service show up in windows, etc? there's a lot of legacy code in engine which would supposedly still work if things are named right (or update those places to current state) Thanks, michal
The main issue is that we basically used the link to upload the ISO into the ISO domain. That caused the ISO to be always named rhev-tools-setup.iso (or rhv-tools-setup.iso in RHV 4.2). The full filename of the ISO is coded as RHEV-toolsSetup_X.Y_Z.iso (or RHV-toolsSetup_4.2_Z.iso in case of RHV 4.2), where X.Y is the RHEV/RHEV version e.g. 4.1 and Z is the tools release number e.g. 2.
Please note that using engine-setup to create a local NFS ISO domain is deprecated, see bug 1332813, and considered harmful if the engine is a self-hosted-engine. Also, in 4.2, there were several relevant changes in the engine itself, including how to upload and use ISO images. IMO if we want to keep the functionality discussed in this bug, it should be re-implemented from scratch, probably on the engine (not engine-setup), or even in a new tool packaged with the iso image itself. A possible sketch of how this should work: If the engine notices (or is told) that a new iso image is available/installed, it will show some icon/notification/etc in the admin ui, and/or notify using the notifier service. If/when the user then chooses to, the engine will let the user pick a storage domain to upload the iso to (or use a default one if we decide we want a default, or if there is only one, use that, etc), and upload the image there. Allon - makes sense? If so, please take care (open RFEs etc). Thanks. Current bug, if we decide to fix at all, probably applies only to systems upgraded from earlier versions, which did allow creating an ISO domain by engine-setup.
Tal, you're leading the ISO effort - what's your take on this?
This should definitely be written from scratch taking into consideration the ISO on data domains RFE and the future deprecation of the ISO domain. Didi, I'm not sure I know all the fine details here, let's give it a bit of a more detailed design and go on from there
OK, filed for now bug 1554339.
still the bug is relevant - if you name the iso correctly (comment #5) the auto update would work, supposing it would still be on ISO domain. It's also wrong in documentation. For ISOs on data domains...I do not know how those look ups work in other flows.
What's the latest status here? It seems to be stuck on POST on a patch that hasn't moved for a while?
(In reply to Yaniv Kaul from comment #11) > What's the latest status here? It seems to be stuck on POST on a patch that > hasn't moved for a while? I think that we're ready to merge the patches and backport them to 4.2. Will try to push the merge process.
Verified on rhv-release-4.2.3-2-001.noarch vdsm-4.20.26-1.el7ev.x86_64 RHV-WGT-4.2-5 was attached, while both RHV-*-4.2-5 and RHEV-*-4.2-5 were available on the ISO domain
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/RHEA-2018:1473
BZ<2>Jira Resync