Libguestfs - Nov 2009 - Windows port of daemon?

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

On Thu, Nov 19, 2009 at 03:40:32PM +0000, Richard W.M. Jones
wrote:
> Discuss?
Well deafening silence all round :-)  I'll add some other thoughts.

The obvious base for this seems to be Windows PE (Preinstallation
Environment), a kind of small kernel-only/appliance environment for
Windows:

https://secure.wikimedia.org/wikipedia/en/wiki/Windows_PE

Can Windows PE use a serial console?  How much RAM does it require?
Can it operate without any form of graphics / video card?

The current Linux appliance is well-behaved: It outputs messages to
the serial console (which libguestfs clients can capture[1] or
ignore).  It doesn't require a graphical display (no X, SDL etc).  It
exits cleanly if the daemon dies.  Can a Windows appliance do the
same?

I know next to nothing about how to create such images.  Maybe someone
can help here?  We'd need either the equivalent of an febootstrap-type
appliance builder, or (more likely) a well-documented manual process.
Because we don't want to build this as part of 'make', having a
manual
process that people can follow, backed up with legal binary downloads
is reasonable.

Porting guestfsd should be straightforward.  There is the issue of how
many external commands to port, because a few guestfsd functions are
implemented by running some external command like /sbin/parted.  Most
are standard utilities which should exist on Windows already via other
projects such as MinGW.  I would say: as many as already exist and/or
can be easily compiled on Windows, and any that are hard to port don't
bother too much.

A final note: This is different from porting libguestfs (ie. the
client library) to run on Windows, which is a worthwhile project in
itself but completely separate from this project.

Rich.

[1] http://libguestfs.org/guestfs.3.html#guestfs_set_log_message_callback

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

On Thu, Nov 19, 2009 at 03:40:32PM +0000, Richard W.M. Jones wrote:
> 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)
Could you please tell more technical details? We support NTFS attributes, 
volume management, etc for years. Thanks.

	Szaka