Bug 1571239

Michal, could you fill in some details here, such as what the
tools ISO is called, where it is located, what is the file inside
the ISO we should use, where can we download the tools ISO for testing ...?

the iso is passed to virt-v2v (in oVirt and old CFME v2v integrations) for all Windows conversions using VIRTIO_WIN variable. The ISO is system-wide, supplied by oVirt repos (or RHV channel), and put to iso domain - so it's accessible to all hosts at once. The conversion hosts do not have the virtio-win package installed.

See https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2-beta/html-single/virtual_machine_management_guide/#sect-Installing_Guest_Agents_and_Drivers

It's a superset of virtio-win package, it also contains agents (qemu,ovirt,spice) and graphical installer for manual installations, and signed version of rhev-apt.exe

As for the rhev-apt...it seems there is no functional difference as the rhev-apt in libguestfs seem to work ok despite its signature expired. Still, since you can assume that when the iso is supplied it would have a more up-to-date versionof rhev-apt I believe it can use that one first, and only fall back to /usr/share/virt when not found.

Tomas, can you please doublecheck what's exactly going on in the integrated oVirt GUI v2v (that's the only one which really works flawlessly right now) - virt-v2v code doesn't do anything with ovirt-guest-agent AFAICT (it just calls rhev-apt.exe "the agent" in a comment which is not incorrect)...it may also be that it installs ovirt-ga because rhev-apt does that on boot and it just so happens that since we always use oVirt/RHV tools iso it has additional packages and installs them too.

(In reply to Michal Skrivanek from comment #4)
> the iso is passed to virt-v2v (in oVirt and old CFME v2v integrations) for
> all Windows conversions using VIRTIO_WIN variable. The ISO is system-wide,
> supplied by oVirt repos (or RHV channel), and put to iso domain - so it's
> accessible to all hosts at once. The conversion hosts do not have the
> virtio-win package installed.
> 
> See
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2-
> beta/html-single/virtual_machine_management_guide/#sect-
> Installing_Guest_Agents_and_Drivers
> 
> It's a superset of virtio-win package, it also contains agents
> (qemu,ovirt,spice) and graphical installer for manual installations, and
> signed version of rhev-apt.exe
> 
> As for the rhev-apt...it seems there is no functional difference as the
> rhev-apt in libguestfs seem to work ok despite its signature expired. Still,
> since you can assume that when the iso is supplied it would have a more
> up-to-date versionof rhev-apt I believe it can use that one first, and only
> fall back to /usr/share/virt when not found.

The installer on RHV tools ISO is located at:

  \RHEV-Application Provisioning Tool.msi

> 
> Tomas, can you please doublecheck what's exactly going on in the integrated
> oVirt GUI v2v (that's the only one which really works flawlessly right now)
> - virt-v2v code doesn't do anything with ovirt-guest-agent AFAICT (it just
> calls rhev-apt.exe "the agent" in a comment which is not incorrect)...it may
> also be that it installs ovirt-ga because rhev-apt does that on boot and it
> just so happens that since we always use oVirt/RHV tools iso it has
> additional packages and installs them too.

When importing using oVirt/RHV GUI:

- For oVirt nothing magical happens and it's users task to attach the tools ISO and install the tools after the conversion manually.

- For RHV we automatcially attach the tools ISO when the VM boots at which point rhev-apt steps in and installs/updates the drivers and tools from the ISO. After that the user may need to restart the VM because some things don't get loaded right away (is this documented?). BUT for this to work the VM has to have correct Guest OS defined, which is user's responsibility (in the import dialog)!

Note for self, there is something called msiexec which can apparently
install MSIs non-interactively.

As for the other tools (and drivers, duh) it is possible to copy the installer from ISO and run it on first start

- u/s: ovirt-guest-tools-setup.exe (~ 50 MB), can be silently installed using '/S' argument

- d/s: RHEV-toolsSetup.exe (~ 120 MB), also sinlently installable but requires an answer file (see attachments) using '-s -f1C:\rhev-setup.iss'. Unfortunately we need two different versions of the answer file -- one for 3.6 and 4.0 installer and one for 4.1 and 4.2 installer because two drivers were added in 4.1 and component list hast to match. There are also separate smaller installers in \tools directory that can be used to detect available components and generate the answer file, or alternatively we could just pick the specific installers (instead of RHEV-toolsSetup.exe) so we don't have to carry the drivers that are already there.

Created attachment 1428519 [details]
Answer file for RHV 3.6 and 4.0 ISO

Created attachment 1428520 [details]
Answer file for RHV 4.1 and 4.2 ISO

This is the root directory of /usr/share/rhv-guest-tools-iso/RHV-toolsSetup_4.2_5.iso

><fs> ll /
total 124798
dr-xr-xr-x  8 root root      2048 Jan  1  2013 .
drwxr-xr-x 19 root root      4096 May  1 11:39 ..
-r-xr-xr-x  1 root root   2944436 Jan  1  2013 CDHashes.txt
dr-xr-xr-x  9 root root      2048 Apr 17 22:15 Drivers
dr-xr-xr-x  2 root root      2048 Apr 17 22:14 Manifest
dr-xr-xr-x  2 root root      2048 Apr 17 22:14 QJScriptLib
-r--r--r--  1 root root       226 Apr 17 22:14 RHEV-Application Provisioning Tool.exe
dr-xr-xr-x  2 root root      2048 Apr 17 22:14 RHEV-apt
-r--r--r--  1 root root 124825856 Apr 17 22:14 RHEV-toolsSetup.exe
dr-xr-xr-x  2 root root      2048 Apr 17 22:14 Upgrade
-r--r--r--  1 root root      1100 Apr 17 22:14 Upgrade.wsf
dr-xr-xr-x  2 root root      4096 Apr 17 22:14 tools

Questions, questions ...

(1) Can we modify RHEV-toolsSetup.exe so it doesn't require an answer
file?  ie. there would be a "just do it" command line option.  Note
that we don't know the version of oVirt/RHV on the target so anything
which depends on knowing that is a non-starter.

(2) Where does ovirt-guest-tools-setup.exe come from?

(3) What is the difference between RHEV-Application Provisioning Tool.exe
and RHEV-toolsSetup.exe?  Do we need both?

(4) If we run ovirt-guest-tools-setup.exe / RHEV-toolsSetup.exe
does that install all the guest agents needed by oVirt / RHV?

For example, RHEV-APT, qemu-ga and ovirt-guest-agent have all
been mentioned at some time, but it's not clear if all of these
have to be installed separately and if they're the same thing or not.

(5) Is any modification needed to the OVF XML that virt-v2v generates?

1) Lev?

2) it's the upstream equivalent of RHV-toolsSetup, installing everything including unsigned drivers

3) APT is the automatic updater, works with d/s only tools iso, update to latest version when it founds the tools CD attached. We attach it automatically on VM run when the guest reported tools/drivers are older than what's available in ISO domain.
ovirt-guest-tools-setup.exe and RHV-toolsSetup.exe are standalone manual installers.

4) yes, it does install all of them - i.e. drivers, qemu-ga, ovirt-ga, vdagent.

5) you mean for the installers to work? No, just the OS type needs to be Windows-kind for that auto-attaching of tools iso.

(In reply to Richard W.M. Jones from comment #12)

> (1) Can we modify RHEV-toolsSetup.exe so it doesn't require an answer
> file?  ie. there would be a "just do it" command line option.  Note
> that we don't know the version of oVirt/RHV on the target so anything
> which depends on knowing that is a non-starter.

There's no need. You don't have to know the version. The check can be based on the existance of installers in \tools. -- If \tools\RHV-RNG.msi exists use answer file #1 if not use answer file #2. Alternatively, the content list in answer file can be completely generated from the list of files in \tools.

Of course, not having to use answer file would be best. However it seems to be something mandated by the InstalShield so I just fear it may not be possible to get rid of it.


(In reply to Michal Skrivanek from comment #13)

> 4) yes, it does install all of them - i.e. drivers, qemu-ga, ovirt-ga,
> vdagent.

It also installs rhev-apt (in case of RHV-toolsSetup.exe) so if we use this one we don't need to install rhev-apt separately.

So in summary it looks like:

(a) We should run either:

  ovirt-guest-tools-setup.exe /s

or:

  RHV-toolsSetup.exe -s -f1C:\rhev-setup.iss

where \rhev-setup.iss is an answer file generated somehow
to be determined.

I still don't know exactly where I can get ovirt-guest-tools-setup.exe.
Is it on another ISO somewhere?  Where is that ISO?  I need to test
this so I need an ISO to test it with.

(b) The answer file could be generated from the contents of the
ISO, but I don't have precise instructions how to do that.

(c) We don't need to install rhev-apt any longer, nor bundle it
with virt-v2v.  This would replace that code.

(d) This would all be a lot simpler if RHV-toolsSetup.exe had a
"just work" command line option instead of needing either interactivity
or an answer file.

(In reply to Richard W.M. Jones from comment #15)
> So in summary it looks like:
> 
> (a) We should run either:
> 
>   ovirt-guest-tools-setup.exe /s
> 
> or:
> 
>   RHV-toolsSetup.exe -s -f1C:\rhev-setup.iss
> 
> where \rhev-setup.iss is an answer file generated somehow
> to be determined.
> 
> I still don't know exactly where I can get ovirt-guest-tools-setup.exe.
> Is it on another ISO somewhere?  Where is that ISO?  I need to test
> this so I need an ISO to test it with.

You can get the latest ISO for oVirt 4.2 here:

  http://resources.ovirt.org/pub/ovirt-4.2/rpm/el7/noarch/ovirt-guest-tools-iso-4.2-1.el7.centos.noarch.rpm

> 
> (b) The answer file could be generated from the contents of the
> ISO, but I don't have precise instructions how to do that.

I can provide you with the instructions if this is the road we want to take. -- As opposed to having two fixed answer files (and risking there will be third in the future).

> (c) We don't need to install rhev-apt any longer, nor bundle it
> with virt-v2v.  This would replace that code.

What about the case where RHV-tools ISO is not available during conversion? Do we still want to handle those cases? (Michal?)

> (d) This would all be a lot simpler if RHV-toolsSetup.exe had a
> "just work" command line option instead of needing either interactivity
> or an answer file.

Indeed. Lat's wait for Lev.

(In reply to Tomáš Golembiovský from comment #16)

> What about the case where RHV-tools ISO is not available during conversion?
> Do we still want to handle those cases? (Michal?)

this should be the responsibility of the caller. I think supplying the exact file path and making sure that file is accessible on the actual conversion host should be easy enough. We can even use option to the wrapper so it's easier for CFME and then keep using the env variable towards virt-v2v itself.

> > (d) This would all be a lot simpler if RHV-toolsSetup.exe had a
> > "just work" command line option instead of needing either interactivity
> > or an answer file.
> Indeed. Lat's wait for Lev.

if the answer file is mandatory it can perhaps be just created at build time and placed on the iso.

Very long conversation about this on IRC.  The take-away is that
what we're doing now, just installing RHEV-APT is sufficient
(although we should move to a newer version).  I think we can
probably continue to bundle RHEV-APT with virt-v2v too since that
is simplest for everyone.

What exactly is this BZ waiting for? Any update? Is this done?

I'm going to close this since I think it's irrelevant now that Tomas
has done all the other guest agent work in v2v.