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? >