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

[Ronen Hod <rhod@redhat.com>]

On 06/22/2011 09:55 PM, 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.
>
> 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.
>
> - ?
>
> 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).
>
> - 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?
>
The windows drivers are an issue. You do not want to compile them since 
you need the hard-to-get Microsoft certification. Now that you have to 
provide them in binary mode, the question is whether it makes sense to 
treat the Windows agent differently.
Other than building the windows drivers, I don't see an issue.
Ronen.