Re: [Qemu-devel] RFC: Qemu Guest Tools ISO

[Alon Levy]

On Wed, Jun 22, 2011 at 01:55:25PM -0500, Michael Roth wrote:
> Goal:
> 
> Provide a mechanism, similar to vmware and virtualbox guest tools
> ISOs, that allows us to easily distribute guest tools (and
> potentially drivers) for linux and windows guests.

What would be the advantage for linux guests, with their package managers 
already
handling this task? I see how it would make testing easier with various linux
distributions, but for management I wonder if it won't be easier to use the
package management system to update the guests same as the hosts.

> 
> Advantages (rough list to start the discussion, feel free to add/comment):
> 
> - Simplify deployment of guest additions. ISO-installable additions
> can be pulled from QEMU/KVM/virtio/etc upstream or external projects
> as needed rather than worked into distros as independent packages.
> Users do not need to worry about installing lists of packages for
> full support. Pre-made ISOs can be pulled into QEMU/KVM in a manner
> similar to BIOSs/option roms.
> 
> - Reduce complexity involved with needing to manage guests with
> outdated/missing tools or drivers. No need to rely on distros to
> pull drivers/features/bug fixes from upstream before relying on
> them; we can assume these fixes/features are immediately available
> from an upstream perspective, and distros can still maintain
> compatibility within a distro-centric environment by shipping
> specific versions of the guest tools ISO (hopefully the version
> committed to qemu.git at time of rebase or newer)
> 
> - Simplify updates: Hypervisor can push guest tools updates by
> building QMP/guest agent interfaces around an ISO.
> 
> - Extend support to older guests (and windows) where new repo
> packages are not a realistic option.
> 

ok, this is relevant to linux guests too.

> - ?
> 
> Disadvantages:
> 
> - Need to test changes to tools against supported distros/platforms
> rather than punting to / or leveraging distro maintainers. KVM
> Autotest would likely be a big part of this.
> 
> - Potentially less integration from a distro-centric perspective.
> Upstream mandates guest tools, distros need to keep up or rebase to
> remain in sync. Can still elect to support specific versions of a
> guest tools ISO, however.
> 
> - ?
> 
> Implementation:
> 
> I hope to follow-up in fairly short order with a basic prototype of
> the tools/workflow to create/install a guest additions ISO. A rough
> overview of the approach I'm currently pursuing:
> 
> - Use PyInstaller (built around pye2exe, linux/windows compatible,
> with logic to pull in required shared libs and windows/tcl/cmd.exe
> support as needed) to generate executables from python scripts.
> 
> - Each project exists as a free-form directory with source code, or
> 32/64 bit pre-compiled binaries, windows-based installers, etc. To
> add to an ISO a symlink to this directory would be added along with
> a python installer script which accepts arch/distro as arguments.
> install/update/uninstall logic handled completely by this install
> script.
> 
> - Top-level installer will iterate through guest additions projects
> and execute installers in turn. (some basic dependency support or
> explicit ordered may be needed).

I'm not sure all drivers have installers. sometimes it will need to install
from inf I think. Should look at how the REHV-M iso does this.

> 
> - Install scripts (top-level and per-project) will be run through a
> set of scripts built around PyInstaller to generate a group of
> executable installers for linux as well as for windows (installers
> can be do-nothings for unsupported platforms, or simply call out to
> other binaries if using, say, an MSI windows installer). Both will
> co-exist on the same ISO, and share the top-level projects directory
> containing the individual code/binaries for individual projects.
> 
> Thoughts?
>