Following Bug 1620307, virtio-win vfd files were full so they needed a new split (server / desktop drivers). rhvm-setup-plugins needs to be adapted accordingly
Sandro, I understood this is handled by Lev? We will have 2 floppies, fine, no other changes in engine code would be necessary
(In reply to Michal Skrivanek from comment #1) > Sandro, I understood this is handled by Lev? > We will have 2 floppies, fine, no other changes in engine code would be > necessary Assigned to Didi for now, if I'll have enough time I'll handle myself. This will require change within the code that upload VFD into ISO domain.
Is it ok to require virtio-win >= 1.9.6? If yes, this will require a patch to the engine (one will be needed anyway to require newer rhvm-setup-plugins, can be in same patch). If no, we have to adapt the code to work with both old-style and new-style file names.
(In reply to Yedidyah Bar David from comment #4) > Is it ok to require virtio-win >= 1.9.6? > > If yes, this will require a patch to the engine (one will be needed anyway > to require newer rhvm-setup-plugins, can be in same patch). > > If no, we have to adapt the code to work with both old-style and new-style > file names. Current code will work, it only tries to copy files if they are found. We still might want to bump the virtio-win req - we currently require >= 1.8.0.
(In reply to Yedidyah Bar David from comment #5) > > Current code will work, it only tries to copy files if they are found. But emits an ugly warning otherwise. So the question still stands. > We > still might want to bump the virtio-win req - we currently require >= 1.8.0.
(In reply to Yedidyah Bar David from comment #4) > Is it ok to require virtio-win >= 1.9.6? > > If yes, this will require a patch to the engine (one will be needed anyway > to require newer rhvm-setup-plugins, can be in same patch). > > If no, we have to adapt the code to work with both old-style and new-style > file names. ok to require virtio-win >= 1.9.6.
Can you provide verification steps? As I'm not sure where this is used as engine-iso-uploader needs whole path to iso/vfd files anyway.
(In reply to Petr Matyáš from comment #9) > Can you provide verification steps? > As I'm not sure where this is used as engine-iso-uploader needs whole path > to iso/vfd files anyway. iso-uploader is not involved, it's just engine-setup uploading the vfd to iso domain during engine-setup execution for install / upgrade
That said, verification steps are not that trivial, because in 4.2 engine-setup no longer asks about the NFS ISO domain. So you have to do something like this: 1. setup 4.1 engine. Answer 'Yes' to 'Configure an NFS share on this server to be used as an ISO Domain?' (it defaults to 'No'). 2. Check the generated ISO domain contents. It should contain the RHV guest tools ISO and some VFD files. 3. Upgrade to 4.2 using fixed versions (rhvm-setup-plugins-4.2.13 and virtio-win from bug 1620307). 4. Check ISO domain content. It should now include also the new VFD files, as noted in bug 1620307 comment 9.
Is this in any way related to variable OVESETUP_CONFIG/isoPathsToUpload which during upgrade/setup looks like this: 2018-10-05 13:02:29,749+0200 DEBUG otopi.context context.dumpEnvironment:869 ENV OVESETUP_CONFIG/isoPathsToUpload=list:'['/usr/share/virtio-win/virtio-win_x86.vfd', '/usr/share/virtio-win/virtio-win_amd64.vfd', '/usr/share/virtio-win/virtio-win.iso', '/usr/share/ovirt-guest-tools-iso/ovirt-tools-setup.iso', '/usr/share/rhev-guest-tools-iso/rhev-tools-setup.iso', '/usr/share/rhv-guest-tools-iso/RHV-toolsSetup_4.2_8.iso']' Will this look any different on engine upgraded from 4.1?
(In reply to Petr Matyáš from comment #12) > Is this in any way related to variable OVESETUP_CONFIG/isoPathsToUpload > which during upgrade/setup looks like this: > > 2018-10-05 13:02:29,749+0200 DEBUG otopi.context context.dumpEnvironment:869 > ENV > OVESETUP_CONFIG/isoPathsToUpload=list:'['/usr/share/virtio-win/virtio- > win_x86.vfd', '/usr/share/virtio-win/virtio-win_amd64.vfd', > '/usr/share/virtio-win/virtio-win.iso', > '/usr/share/ovirt-guest-tools-iso/ovirt-tools-setup.iso', > '/usr/share/rhev-guest-tools-iso/rhev-tools-setup.iso', > '/usr/share/rhv-guest-tools-iso/RHV-toolsSetup_4.2_8.iso']' > > Will this look any different on engine upgraded from 4.1? This is a great question, which I also asked myself while checking setup logs, but sadly, the answer is "No". This variable was added when we decided to copy this feature to upstream, but we never removed the downstream duplicate nor amended it to use this variable too. You will only see this in the setup logs in the uninstall information. The code does not log anything by itself. I was tempted to spend time and get this all fixed and cleaned up, but this is a deprecated feature (see bug 1554339), so I'd rather not spend time on it.
After installation of 4.1 with rhevm-setup-plugins-4.1.5-1.el7ev.noarch local ISO Domain looks like this: [root@engine ~]# ll /var/lib/exports/iso/061188d4-3076-4e90-8db5-033ec34cd217/images/11111111-1111-1111-1111-111111111111/ total 1654008 -rw-r--r--. 1 vdsm kvm 546744320 Oct 9 11:44 rhev-tools-setup.iso -rw-r--r--. 1 vdsm kvm 546744320 Oct 9 11:44 rhev-tools-setup.iso.20181009114424 -rw-r--r--. 1 vdsm kvm 2949120 Oct 9 11:44 virtio-win_amd64.vfd -rw-r--r--. 1 vdsm kvm 2949120 Oct 9 11:44 virtio-win_amd64.vfd.20181009114419 -rw-r--r--. 1 vdsm kvm 294205440 Oct 9 11:44 virtio-win.iso -rw-r--r--. 1 vdsm kvm 294205440 Oct 9 11:44 virtio-win.iso.20181009114419 -rw-r--r--. 1 vdsm kvm 2949120 Oct 9 11:44 virtio-win_x86.vfd -rw-r--r--. 1 vdsm kvm 2949120 Oct 9 11:44 virtio-win_x86.vfd.20181009114419 After upgrade to 4.2 with rhvm-setup-plugins-4.2.13-1.el7ev.noarch local ISO domain contains: [root@engine ~]# ll /var/lib/exports/iso/061188d4-3076-4e90-8db5-033ec34cd217/images/11111111-1111-1111-1111-111111111111/ total 1654008 -rw-r--r--. 1 vdsm kvm 546744320 Oct 9 11:44 rhev-tools-setup.iso -rw-r--r--. 1 vdsm kvm 546744320 Oct 9 11:44 rhev-tools-setup.iso.20181009114424 -rw-r--r--. 1 vdsm kvm 2949120 Oct 9 11:44 virtio-win_amd64.vfd -rw-r--r--. 1 vdsm kvm 2949120 Oct 9 11:44 virtio-win_amd64.vfd.20181009114419 -rw-r--r--. 1 vdsm kvm 294205440 Oct 9 11:44 virtio-win.iso -rw-r--r--. 1 vdsm kvm 294205440 Oct 9 11:44 virtio-win.iso.20181009114419 -rw-r--r--. 1 vdsm kvm 2949120 Oct 9 11:44 virtio-win_x86.vfd -rw-r--r--. 1 vdsm kvm 2949120 Oct 9 11:44 virtio-win_x86.vfd.20181009114419
Sorry, I misled you. engine-setup does not copy these files on upgrade, only in new setups. So in principle we should close current bug notabug (or wontfix). If you want to still try this, still not sure we'll then also want to document this, you can force engine-setup in 4.2 to create an iso domain, even though it does not ask about it anymore (bug 1332813), by passing OVESETUP_SYSTEM/nfsConfigEnabled=bool:True , either in the answer file or with --otopi-environment.
After trying with OVESETUP_SYSTEM/nfsConfigEnabled=bool:True, which wasn't enough for otopi to ask me about ISO domain, I taken the answer file, added NFS export ACL and mount point and tried again with this answer file, it appeared to work (asked about name for the ISO domain) but upon actual creation the setup failed on: [ ERROR ] Failed to execute stage 'Misc configuration': NUM:42883, DETAILS:function insertstorage_domain_static(uuid, character varying, character varying, character varying, unknown, integer, integer, unknown, integer, boolean, boolean, character varying, character varying, integer, integer, boolean) does not exist I think we can safely move to verify as nobody is ever going to use the changes you've made in this bug as they can't be reached in any sane way.
I do not think we can call this "verified". Moving to assigned for now, will soon need to decide what to do.
Closing NOTABUG. Reason is: 1. Local NFS ISO domain creation by engine-setup was obsoleted and can't be used anymore (officially, at least), see bug 1332813. 2. The feature of copying iso/vfd images to the iso domain only works/worked on new clean installs, so can't be used by upgrading from a version that did support local nfs iso domain. 3. So the request in this bug, to update the list of images to be copied by said feature, is irrelevant in 4.2, as this feature does not exist. 4. Not reverting the code change, as it seems harmless, following my testing and comment 14. Thus not needing to build again rhvm-setup-plugins.