I think there's some demand internally for a version of libguestfs
where the appliance part actually runs on Windows. So I'm creating
this thread to discuss the issue.
The reason to want a Windows appliance at all is twofold: (1) better
support for NTFS filesystems and Windows-native filesystem features
(attributes, volume management etc), and (2) so we can run Windows
CMD.EXE commands using the guestfs_command/guestfs_run API.
The alternate architecture seems like it would be something like this:
+-----------------+ +-----------------+
| libguestfs.so | <--------> | guestfsd |
| (library) | | (appliance) |
+-----------------+ | Windows kernel |
running on Linux +-----------------+
in qemu
I think exactly the same RPC protocol should be used. In fact,
guestfsd would be the exact same code, just ported so it compiles on
Windows. Possibly this guestfsd would support some specific Windows
commands as well as the current core of commands, but the current
appliance has some very Linux-specific commands (eg. the LVM stuff) so
that's not such an issue.
You'd need to be able to select which appliance to use via the API,
eg: guestfs_set_distro to alter the distro field (currently this is
hard-coded to something like "fedora-12" -- see $libdir/guestfs/*).
There are of course obvious licensing/legal issues around how to build
and ship the appliance. Linux builds could not include the Windows
appliance, but users could use or download their own. We can use the
Fedora MinGW project or Debian equivalent for cross-builds of the
daemon.
Discuss?
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://et.redhat.com/~rjones/libguestfs/
See what it can do:
http://et.redhat.com/~rjones/libguestfs/recipes.html