On 06/23/2011 04:29 AM, Alon Levy wrote:
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.
The advantages listed below are in comparison to distro-managed
packaging. The main one I think would be the support matrix for upstream
code:
Certain versions of QEMU ship with certain versions of the ISO, and
support guests with that particular version of the ISO installed.
This is a very enabling assumption to be able to make when working on
new features (or deprecating old ones), and it's simply not one that can
be made for distro-managed tools since there are a number of reasons why
a distro won't update tools in a reasonable timeframe: maintaining
compatability with a down-level host stack they support, distro-specific
additions to various tools, support/packaging policies, etc.
Ideally we maintain backward compatibility with older versions the
ISO/guest tools, but we can elect to break them if need be since we
don't need to worry about supporting guests with older tools that
haven't been updated by the distro; the hypervisor can push required
updates/tools with minimal guest participation beyond the initial guest
tools installation (updates can get pushed automatically from that point
forward).
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.
By installers I mean the python install script you include with the
project, so it's pretty free-form: you can simply copy files over,
install an rpm/deb, execute a binary, make/make install, etc.
- 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?
