2:44 a.m.
[These two patches are for discussion only]
Allow FUSE support to be used directly through the API.
This is the second commit.
In order to make this usable from guestfish, we have to
also bind the events API in guestfish. This is the first
commit.
Rich.
2:44 a.m.
New subject: [PATCH 1/2] fish: Allow events to be processed in guestfish.
From: "Richard W.M. Jones" <rjones(a)redhat.com>
Add 'event' and 'delete-event' commands so that event handlers
can be registered and deleted in guestfish. The event handler
is a shell script snippet or host command.
Cc: Pádraig Brady <P(a)draigBrady.com>
---
generator/generator_actions.ml | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/generator/generator_actions.ml b/generator/generator_actions.ml
index dae837b..7d7c7af 100644
--- a/generator/generator_actions.ml
+++ b/generator/generator_actions.ml
@@ -6675,6 +6675,16 @@ them with the help of L</glob> like this:
glob copy-out /home/* .");
+ ("delete_event", (RErr,[], []), -1, [], [],
+ "delete a previously registered event handler",
+ " delete-event name
+
+Delete the event handler which was previously registered as C<name>.
+If multiple event handlers were registered with the same name, they
+are all deleted.
+
+See also the guestfish C<event> command.");
+
("display", (RErr,[], []), -1, [], [],
"display an image",
" display filename
@@ -6706,6 +6716,35 @@ The editor is C<$EDITOR>. However if you use the alternate
commands C<vi> or C<emacs> you will get those corresponding
editors.");
+ ("event", (RErr,[], []), -1, [], [],
+ "register a handler for an event or events",
+ " event name eventset \"shell script ...\"
+
+Register a shell script fragment which is executed when an
+event is raised. See L<guestfs(3)/guestfs_set_event_callback>
+for a discussion of the event API in libguestfs.
+
+The C<name> parameter is a name that you give to this event
+handler. It can be any string (even the empty string) and is
+simply there so you can delete the handler using the guestfish
+C<delete-event> command.
+
+The C<eventset> parameter is a comma-separated list of one
+or more events.
+
+The third and final parameter is the shell script fragment
+(or any external command) that is executed when any of the
+events in the eventset occurs. It is executed using
+C<$SHELL -c>, or if C<$SHELL> is not set then C</bin/sh -c>.
+
+The shell script fragment receives callback parameters as
+arguments C<$1>, C<$2> etc. The actual event that was
+called is available in the environment variable C<$EVENT>.
+
+ event \"\" close \"echo closed\"
+ event messages appliance,library,trace \"echo $*\"
+ event \"\" progress \"echo progress: $3/$4\"");
+
("glob", (RErr,[], []), -1, [], [],
"expand wildcards in command",
" glob command args...
--
1.7.6
2:44 a.m.
New subject: [PATCH 2/2] New APIs: mount-local, umount-local (FUSE support in the API).
From: "Richard W.M. Jones" <rjones(a)redhat.com>
Add FUSE support directly to the API. Instead of needing to
use the external 'guestmount' command, you can mount the
libguestfs filesystem space on a local mountpoint using an
API call from any language.
Cc: Pádraig Brady <P(a)draigBrady.com>
---
generator/generator_actions.ml | 45 ++++++++++++++++++++++++++++++++++++++++
generator/generator_events.ml | 3 ++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/generator/generator_actions.ml b/generator/generator_actions.ml
index 7d7c7af..3d4e5ec 100644
--- a/generator/generator_actions.ml
+++ b/generator/generator_actions.ml
@@ -1644,6 +1644,51 @@ This function must be called before
C<guestfs_launch>.");
"\
This returns the number of virtual CPUs assigned to the appliance.");
+ ("mount_local", (RErr, [String "localmountpoint"], [String
"options"]), -1, [],
+ [], (* tests in fuse subdirectory *)
+ "mount on the local filesystem",
+ "\
+This call exports the libguestfs-accessible filesystem to
+a local mountpoint (directory) called C<localmountpoint>.
+Ordinary reads and writes to files and directories under
+C<localmountpoint> are redirected through libguestfs.
+
+Internally this is currently implemented using FUSE, and
+so this requires that FUSE is available and usable. This
+may require installing a kernel module and/or adding the
+current user to a special C<fuse> group. See the documentation
+for your distro and L<http://fuse.sf.net> for further
+information.
+
+The C<guestfs_mount_local> call does not return until the
+filesystem is I<unmounted> by calling C<guestfs_umount_local>.
+The current thread is involved with the processing of
+filesystem requests. To access the filesystem you need
+to use another thread or process. B<Note> you must I<not>
+make concurrent libguestfs calls on the same handle from
+another thread, except for C<guestfs_umount_local>.
+
+The mountpoint is not immediately available, since there
+is certain setup required. When the mountpoint becomes
+ready to use, the C<MOUNTED> callback is called in the
+current thread. You can register a callback function
+using C<guestfs_set_event_callback>.
+
+To unmount the filesystem, call C<guestfs_umount_local>.
+This may be called from another thread, which is a special
+exception to ordinary libguestfs rules. Two things happen
+when this is called: firstly the C<UNMOUNTED> callback is
+called, and secondly the current call returns.");
+
+ ("umount_local", (RErr, [], []), -1, [],
+ [], (* tests in fuse subdirectory *)
+ "unmount a locally mounted filesystem",
+ "\
+If libguestfs is exporting the filesystem on a local
+mountpoint, then this unmounts it.
+
+See C<guestfs_mount_local> for full documentation.");
+
]
(* daemon_functions are any functions which cause some action
diff --git a/generator/generator_events.ml b/generator/generator_events.ml
index df74af3..ea26cd0 100644
--- a/generator/generator_events.ml
+++ b/generator/generator_events.ml
@@ -37,6 +37,9 @@ let events = [
"trace"; (* call trace messages *)
"enter"; (* enter a function *)
+
+ "mounted"; (* local filesystem mounted and ready
*)
+ "unmounted"; (* local filesystem unmounted *)
]
let events = mapi (fun i name -> name, 1 lsl i) events
--
1.7.6
3:33 a.m.
On 12/14/2011 08:44 AM, Richard W.M. Jones wrote:
[These two patches are for discussion only]
Allow FUSE support to be used directly through the API.
This is the second commit.
In order to make this usable from guestfish, we have to
also bind the events API in guestfish. This is the first
commit.
There's not really enough information here to evaluate the proposed
changes. Can you give an example of what you're trying to do?
In general, though, this feels wrong for a couple of reasons. Firstly, a
callback mechanism implemented with shell scripts is simply hideous.
Imagine trying to use that from another language.
Secondly, mounting filesystems is not the business of the guestfs api,
it's the business of FUSE. I have't actually checked the libfuse API,
but this seems like a function which makes much more sense in that context.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
4:36 a.m.
On Wed, Dec 14, 2011 at 09:33:35AM +0000, Matthew Booth wrote:
On 12/14/2011 08:44 AM, Richard W.M. Jones wrote:
>[These two patches are for discussion only]
>
>Allow FUSE support to be used directly through the API.
>This is the second commit.
>
>In order to make this usable from guestfish, we have to
>also bind the events API in guestfish. This is the first
>commit.
There's not really enough information here to evaluate the proposed
changes. Can you give an example of what you're trying to do?
There's a very specific need for this in OpenStack. We want to be
able to inject files and make other filesystem changes -- and there is
already common code which assumes the guest filesystem is mounted
somewhere. But also we want to call libguestfs APIs such as
guestfs_tune2fs. Currently we can do the mounting bit by calling
guestmount, and we can do the other libguestfs API calls, but we need
to launch libguestfs twice to do this.
Here is Padraig's current OpenStack patch:
https://review.openstack.org/#change,1993
https://review.openstack.org/#change,1994
In general, though, this feels wrong for a couple of reasons.
Firstly, a callback mechanism implemented with shell scripts is
simply hideous. Imagine trying to use that from another language.
This is only for guestfish (which is a shell script tool). How would
you want to capture events in guestfish?
Secondly, mounting filesystems is not the business of the guestfs
api, it's the business of FUSE. I have't actually checked the
libfuse API, but this seems like a function which makes much more
sense in that context.
See above.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
5:06 a.m.
On 12/14/2011 10:36 AM, Richard W.M. Jones wrote:
On Wed, Dec 14, 2011 at 09:33:35AM +0000, Matthew Booth wrote:
> On 12/14/2011 08:44 AM, Richard W.M. Jones wrote:
>> [These two patches are for discussion only]
>>
>> Allow FUSE support to be used directly through the API.
>> This is the second commit.
>>
>> In order to make this usable from guestfish, we have to
>> also bind the events API in guestfish. This is the first
>> commit.
>
> There's not really enough information here to evaluate the proposed
> changes. Can you give an example of what you're trying to do?
There's a very specific need for this in OpenStack. We want to be
able to inject files and make other filesystem changes -- and there is
already common code which assumes the guest filesystem is mounted
somewhere. But also we want to call libguestfs APIs such as
guestfs_tune2fs. Currently we can do the mounting bit by calling
guestmount, and we can do the other libguestfs API calls, but we need
to launch libguestfs twice to do this.
Here is Padraig's current OpenStack patch:
https://review.openstack.org/#change,1993
https://review.openstack.org/#change,1994
Ok, it's an efficiency thing. However, I still think it's the wrong
solution. What you really want to do is use 1 appliance for 2 things. We
already have a mechanism to do that: ATTACH_METHOD_UNIX. Why not update
guestmount to use it?
> In general, though, this feels wrong for a couple of reasons.
> Firstly, a callback mechanism implemented with shell scripts is
> simply hideous. Imagine trying to use that from another language.
This is only for guestfish (which is a shell script tool). How would
you want to capture events in guestfish?
Not quite so hideous, but I remain unconvinced. Use another language?
That's not a flippant suggestion, btw. There comes a point in shell
scripting when you're exceeding what it was designed for.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
6:06 a.m.
On Wed, Dec 14, 2011 at 11:06:24AM +0000, Matthew Booth wrote:
On 12/14/2011 10:36 AM, Richard W.M. Jones wrote:
>On Wed, Dec 14, 2011 at 09:33:35AM +0000, Matthew Booth wrote:
>>On 12/14/2011 08:44 AM, Richard W.M. Jones wrote:
>>>[These two patches are for discussion only]
>>>
>>>Allow FUSE support to be used directly through the API.
>>>This is the second commit.
>>>
>>>In order to make this usable from guestfish, we have to
>>>also bind the events API in guestfish. This is the first
>>>commit.
>>
>>There's not really enough information here to evaluate the proposed
>>changes. Can you give an example of what you're trying to do?
>
>There's a very specific need for this in OpenStack. We want to be
>able to inject files and make other filesystem changes -- and there is
>already common code which assumes the guest filesystem is mounted
>somewhere. But also we want to call libguestfs APIs such as
>guestfs_tune2fs. Currently we can do the mounting bit by calling
>guestmount, and we can do the other libguestfs API calls, but we need
>to launch libguestfs twice to do this.
>
>Here is Padraig's current OpenStack patch:
>
>https://review.openstack.org/#change,1993
>https://review.openstack.org/#change,1994
Ok, it's an efficiency thing. However, I still think it's the wrong
solution. What you really want to do is use 1 appliance for 2
things. We already have a mechanism to do that: ATTACH_METHOD_UNIX.
Why not update guestmount to use it?
>>In general, though, this feels wrong for a couple of reasons.
>>Firstly, a callback mechanism implemented with shell scripts is
>>simply hideous. Imagine trying to use that from another language.
>
>This is only for guestfish (which is a shell script tool). How would
>you want to capture events in guestfish?
Not quite so hideous, but I remain unconvinced. Use another
language? That's not a flippant suggestion, btw. There comes a point
in shell scripting when you're exceeding what it was designed for.
Let me explain this again ...
The guestfish change is only for us to do testing. OpenStack is
written in Python and uses the libguestfs-python API.
What Padraig's current patch is doing is essentially assembling the
command line for guestmount and calling out to it. This is
reminiscent of the bad old days when inspection was part of a separate
set of Perl tools, and we had to coordinate between virt-inspector and
guestfish by assembling command lines.
This would work much better if Padraig was able to do:
g = guestfs.GuestFS ()
g.add_drive_opts (...)
g.launch ()
# Locate the filesystems:
try:
roots = g.inspect_os ()
# mount some stuff
except:
# Inspection failed, backup method:
g.list_filesystems ()
# mount some stuff
g.set_event_callback (callback, guestfs.EVENT_MOUNTED)
g.mount_local ("/tmp/dir")
# In the event callback, start a thread which:
# - injects files
# - modifies network config
# - finally calls g.umount_local ()
# Finally, tune the filesystem
g.tune2fs (...)
You can see this is much cleaner, as well as more efficient, than
constructing command lines and shelling out to guestmount.
(BTW I am making some untested assumptions about libfuse here.
I don't know that this will really work)
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://libguestfs.org
8:17 a.m.
On 12/14/2011 12:06 PM, Richard W.M. Jones wrote:
On Wed, Dec 14, 2011 at 11:06:24AM +0000, Matthew Booth wrote:
> On 12/14/2011 10:36 AM, Richard W.M. Jones wrote:
>> On Wed, Dec 14, 2011 at 09:33:35AM +0000, Matthew Booth wrote:
>>> On 12/14/2011 08:44 AM, Richard W.M. Jones wrote:
>>>> [These two patches are for discussion only]
>>>>
>>>> Allow FUSE support to be used directly through the API.
>>>> This is the second commit.
>>>>
>>>> In order to make this usable from guestfish, we have to
>>>> also bind the events API in guestfish. This is the first
>>>> commit.
>>>
>>> There's not really enough information here to evaluate the proposed
>>> changes. Can you give an example of what you're trying to do?
>>
>> There's a very specific need for this in OpenStack. We want to be
>> able to inject files and make other filesystem changes -- and there is
>> already common code which assumes the guest filesystem is mounted
>> somewhere. But also we want to call libguestfs APIs such as
>> guestfs_tune2fs. Currently we can do the mounting bit by calling
>> guestmount, and we can do the other libguestfs API calls, but we need
>> to launch libguestfs twice to do this.
>>
>> Here is Padraig's current OpenStack patch:
>>
>> https://review.openstack.org/#change,1993
>> https://review.openstack.org/#change,1994
>
> Ok, it's an efficiency thing. However, I still think it's the wrong
> solution. What you really want to do is use 1 appliance for 2
> things. We already have a mechanism to do that: ATTACH_METHOD_UNIX.
> Why not update guestmount to use it?
>
>>> In general, though, this feels wrong for a couple of reasons.
>>> Firstly, a callback mechanism implemented with shell scripts is
>>> simply hideous. Imagine trying to use that from another language.
>>
>> This is only for guestfish (which is a shell script tool). How would
>> you want to capture events in guestfish?
>
> Not quite so hideous, but I remain unconvinced. Use another
> language? That's not a flippant suggestion, btw. There comes a point
> in shell scripting when you're exceeding what it was designed for.
I still don't see why we need the guestfish event callbacks.
Let me explain this again ...
The guestfish change is only for us to do testing. OpenStack is
written in Python and uses the libguestfs-python API.
What Padraig's current patch is doing is essentially assembling the
command line for guestmount and calling out to it. This is
reminiscent of the bad old days when inspection was part of a separate
set of Perl tools, and we had to coordinate between virt-inspector and
guestfish by assembling command lines.
This would work much better if Padraig was able to do:
g = guestfs.GuestFS ()
g.add_drive_opts (...)
g.launch ()
# Locate the filesystems:
try:
roots = g.inspect_os ()
# mount some stuff
except:
# Inspection failed, backup method:
g.list_filesystems ()
# mount some stuff
g.set_event_callback (callback, guestfs.EVENT_MOUNTED)
g.mount_local ("/tmp/dir")
# In the event callback, start a thread which:
# - injects files
# - modifies network config
# - finally calls g.umount_local ()
# Finally, tune the filesystem
g.tune2fs (...)
You can see this is much cleaner, as well as more efficient, than
constructing command lines and shelling out to guestmount.
This is an extension of the libguestfs api in a direction which is best
served by a different tool. I've failed to convince you of this argument
several times before though, so I'll try a different tack ;)
The reason this isn't going to work is that a FUSE filesystem requires a
process to exist which can respond to filesystem events as they occur.
This means that you would have to additionally add functions for
managing FUSE events, at the very least calling the event handler. The
API user would have to integrate these calls into their event loop. If
they didn't have an event loop, they'd have to create one. This isn't
the simplicity you're looking for.
Alternatively, they could fork. The problem is, if you do that you
either need to create a separate appliance (the performance overhead
you're trying to avoid), or create an interface to an existing appliance
over which commands from multiple sources can be serialised (my suggestion).
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
9:13 a.m.
On Wed, Dec 14, 2011 at 02:17:05PM +0000, Matthew Booth wrote:
I still don't see why we need the guestfish event callbacks.
because ...
>The guestfish change is only for us to do testing.
[...]
This is an extension of the libguestfs api in a direction which is
best served by a different tool. I've failed to convince you of this
argument several times before though, so I'll try a different tack
;)
The reason this isn't going to work is that a FUSE filesystem
requires a process to exist which can respond to filesystem events
as they occur. This means that you would have to additionally add
functions for managing FUSE events, at the very least calling the
event handler. The API user would have to integrate these calls into
their event loop. If they didn't have an event loop, they'd have to
create one. This isn't the simplicity you're looking for.
Alternatively, they could fork. The problem is, if you do that you
either need to create a separate appliance (the performance overhead
you're trying to avoid), or create an interface to an existing
appliance over which commands from multiple sources can be
serialised (my suggestion).
I haven't written any code yet so I don't know for certain that it
will work. With that in mind, the architecture is as follows:
guestfs_mount_local doesn't return until the filesystem is unmounted.
The thread running guestfs_mount_local is the one which is processing
FUSE requests. In nuts and bolts terms, guestfs_mount_local calls
fuse_main with certain flags to stop it from forking into the
background (or more likely it'll call some of the lower level libfuse
APIs that fuse_main calls). No event loop integration is needed.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
10:03 a.m.
On 12/14/2011 03:13 PM, Richard W.M. Jones wrote:
On Wed, Dec 14, 2011 at 02:17:05PM +0000, Matthew Booth wrote:
> I still don't see why we need the guestfish event callbacks.
because ...
>> The guestfish change is only for us to do testing.
Can't the test be written in another language?
[...]
> This is an extension of the libguestfs api in a direction which is
> best served by a different tool. I've failed to convince you of this
> argument several times before though, so I'll try a different tack
> ;)
>
> The reason this isn't going to work is that a FUSE filesystem
> requires a process to exist which can respond to filesystem events
> as they occur. This means that you would have to additionally add
> functions for managing FUSE events, at the very least calling the
> event handler. The API user would have to integrate these calls into
> their event loop. If they didn't have an event loop, they'd have to
> create one. This isn't the simplicity you're looking for.
>
> Alternatively, they could fork. The problem is, if you do that you
> either need to create a separate appliance (the performance overhead
> you're trying to avoid), or create an interface to an existing
> appliance over which commands from multiple sources can be
> serialised (my suggestion).
I haven't written any code yet so I don't know for certain that it
will work. With that in mind, the architecture is as follows:
guestfs_mount_local doesn't return until the filesystem is unmounted.
The thread running guestfs_mount_local is the one which is processing
FUSE requests. In nuts and bolts terms, guestfs_mount_local calls
fuse_main with certain flags to stop it from forking into the
background (or more likely it'll call some of the lower level libfuse
APIs that fuse_main calls). No event loop integration is needed.
I just read your original python a little more closely:
g.set_event_callback (callback, guestfs.EVENT_MOUNTED)
g.mount_local ("/tmp/dir")
# In the event callback, start a thread which:
# - injects files
# - modifies network config
# - finally calls g.umount_local ()
The problem with this is that if the event callback does anything to the
newly mounted filesystem without a new thread, it'll deadlock. And even
if you require this, you're opening a can of worms because you'll then
have to make the API threadsafe so you can call g.umount_local() from
the thread.
And please don't forget that I'm also opposed to this in principal, as
mounting filesystems on the host is not the business of the guestfs API.
How about this instead:
g.launch()
g.mount(...)
g.foo()
g.bar()
shell("
guestmount -c /path/to/existing/unix/sock /tmp/dir
... manipulate /tmp/dir ...
umount /tmp/dir
")
g.close()
If you wanted to remove the requirement to exec guestmount, you could
solve that in *guestmount* by exposing it as a library.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
10:40 a.m.
On Wed, Dec 14, 2011 at 04:03:16PM +0000, Matthew Booth wrote:
On 12/14/2011 03:13 PM, Richard W.M. Jones wrote:
>On Wed, Dec 14, 2011 at 02:17:05PM +0000, Matthew Booth wrote:
>>I still don't see why we need the guestfish event callbacks.
>
>because ...
>
>>>The guestfish change is only for us to do testing.
Can't the test be written in another language?
Yes we could.
On the other hand, mount-local (in guestfish) wouldn't
be very useful without some way to access the event API (whether
that method is using shell scripts or something else). eg:
<fs> mount-local /mnt options:allow_root
[ guestfish
doesn't return to the prompt ]
/mnt isn't usable until some short but undefined time later on.
With the event API bindings it'd look like:
><fs> event foo mounted "echo READY"
<fs> mount-local /mnt options:allow_root
[short pause]
READY
When 'READY' is printed, the mount point is ready to use.
[...]
I just read your original python a little more closely:
g.set_event_callback (callback, guestfs.EVENT_MOUNTED)
g.mount_local ("/tmp/dir")
# In the event callback, start a thread which:
# - injects files
# - modifies network config
# - finally calls g.umount_local ()
The problem with this is that if the event callback does anything to
the newly mounted filesystem without a new thread, it'll deadlock.
Right; this is a general and well-known limitation of the libguestfs
API -- you mustn't, except in limited situations, call the same handle
from multiple threads.
http://libguestfs.org/guestfs.3.html#multiple_handles_and_multiple_threads
And even if you require this, you're opening a can of worms
because
you'll then have to make the API threadsafe so you can call
g.umount_local() from the thread.
No, because umount-local will be a special case. Essentially it'll
just call 'fusermount -u' so there's no thread safety issues AFAIK.
And please don't forget that I'm also opposed to this in
principal,
as mounting filesystems on the host is not the business of the
guestfs API.
How about this instead:
g.launch()
g.mount(...)
g.foo()
g.bar()
shell("
guestmount -c /path/to/existing/unix/sock /tmp/dir
... manipulate /tmp/dir ...
umount /tmp/dir
")
g.close()
If you wanted to remove the requirement to exec guestmount, you
could solve that in *guestmount* by exposing it as a library.
I thought about this too, but now this is pretty ugly too isn't it.
There are two problems (at least) ...
(1) Is the protocol stable enough that we should do this? I've been
very caution about libguestfs live so far, for exactly this reason.
(2) How do we interleave protocol requests that could be coming from
both guestmount and the library? For example, where should asynch
events get routed? The protocol isn't really designed for this unless
there's a "g.give_up_connection()" call.
Actually I think this is pretty ugly compared to adding a mount-local
API.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
11:07 a.m.
On 12/14/2011 04:40 PM, Richard W.M. Jones wrote:
On Wed, Dec 14, 2011 at 04:03:16PM +0000, Matthew Booth wrote:
> On 12/14/2011 03:13 PM, Richard W.M. Jones wrote:
>> On Wed, Dec 14, 2011 at 02:17:05PM +0000, Matthew Booth wrote:
>>> I still don't see why we need the guestfish event callbacks.
>>
>> because ...
>>
>>>> The guestfish change is only for us to do testing.
>
> Can't the test be written in another language?
Yes we could.
On the other hand, mount-local (in guestfish) wouldn't
be very useful without some way to access the event API (whether
that method is using shell scripts or something else). eg:
><fs> mount-local /mnt options:allow_root
[ guestfish doesn't return to the prompt ]
/mnt isn't usable until some short but undefined time later on.
With the event API bindings it'd look like:
><fs> event foo mounted "echo READY"
><fs> mount-local /mnt options:allow_root
[short pause]
READY
When 'READY' is printed, the mount point is ready to use.
This is really a symptom of mount-local being a poor fit for the guestfs
API. Note that no other API requires a callback to be usable.
[...]
> I just read your original python a little more closely:
>
> g.set_event_callback (callback, guestfs.EVENT_MOUNTED)
> g.mount_local ("/tmp/dir")
> # In the event callback, start a thread which:
> # - injects files
> # - modifies network config
> # - finally calls g.umount_local ()
>
> The problem with this is that if the event callback does anything to
> the newly mounted filesystem without a new thread, it'll deadlock.
Right; this is a general and well-known limitation of the libguestfs
API -- you mustn't, except in limited situations, call the same handle
from multiple threads.
http://libguestfs.org/guestfs.3.html#multiple_handles_and_multiple_threads
> And even if you require this, you're opening a can of worms because
> you'll then have to make the API threadsafe so you can call
> g.umount_local() from the thread.
No, because umount-local will be a special case. Essentially it'll
just call 'fusermount -u' so there's no thread safety issues AFAIK.
> And please don't forget that I'm also opposed to this in principal,
> as mounting filesystems on the host is not the business of the
> guestfs API.
>
> How about this instead:
>
> g.launch()
> g.mount(...)
> g.foo()
> g.bar()
>
> shell("
> guestmount -c /path/to/existing/unix/sock /tmp/dir
> ... manipulate /tmp/dir ...
> umount /tmp/dir
> ")
>
> g.close()
>
> If you wanted to remove the requirement to exec guestmount, you
> could solve that in *guestmount* by exposing it as a library.
I thought about this too, but now this is pretty ugly too isn't it.
There are two problems (at least) ...
(1) Is the protocol stable enough that we should do this? I've been
very caution about libguestfs live so far, for exactly this reason.
The protocol is supposed to be stable, and I don't think it's been
modified in quite a while.
(2) How do we interleave protocol requests that could be coming from
both guestmount and the library? For example, where should asynch
events get routed? The protocol isn't really designed for this unless
there's a "g.give_up_connection()" call.
You wouldn't interleave commands at all. This would require minimal code
change in the daemon: you'd select() a socket at the top level of the
main loop, then fully handle the received request until completion.
Actually I think this is pretty ugly compared to adding a
mount-local
API.
Let me rewrite with a guestmount api:
g.launch()
g.mount(...)
g.foo()
g.bar()
guestmount_mount(g.sock_path(), '/tmp/dir')
...filesystem stuff...
guestmount_umount('/tmp/dir')
g.close()
Note that there are no callbacks, no threads and no races. The code can
be written sequentially. Also, we're not bringing FUSE into the main API.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
2:35 a.m.
On Wed, Dec 14, 2011 at 05:07:04PM +0000, Matthew Booth wrote:
guestmount_mount(g.sock_path(), '/tmp/dir')
...filesystem stuff...
guestmount_umount('/tmp/dir')
g.close()
Note that there are no callbacks, no threads and no races. The code
can be written sequentially.
There are certainly threads here, although they would have to be
hidden behind the scenes, with a barrier to provide synchronization
before "filesystem stuff" can run.
Also, we're not bringing FUSE into the main API.
Is this such a problem? We could dlopen libfuse if the dependency on
libfuse was a problem ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
5:19 a.m.
On 12/15/2011 08:35 AM, Richard W.M. Jones wrote:
On Wed, Dec 14, 2011 at 05:07:04PM +0000, Matthew Booth wrote:
> guestmount_mount(g.sock_path(), '/tmp/dir')
> ...filesystem stuff...
> guestmount_umount('/tmp/dir')
>
> g.close()
>
> Note that there are no callbacks, no threads and no races. The code
> can be written sequentially.
There are certainly threads here, although they would have to be
hidden behind the scenes, with a barrier to provide synchronization
before "filesystem stuff" can run.
No, there are no threads and (in this example, anyway) no
synchronization is required. There *is* a fork, though.
guestmount_mount() would:
1. Create a new guestfs connection to the existing appliance.
2. Create a new filesystem using the new connection.
3. Mount it.
4. fork() and run the FUSE event loop from the child.
In this case, guestmount_mount() would effectively return after 3, at
which point the filesystem is already safe to use. Although the above
example doesn't require this, it would also be 'safe' to interleave
filesystem access and guestfs commands. The limitations would be that
changing the appliance mounts while it is guestmounted would have
undesirable consequences and, as with all filesystem access, there would
be the potential for read->modify->write races. However, a simple use
case like the one you proposed won't hit these limitations. If required,
a simple locking scheme could be added later. This could be as simple as
total exclusivity for a single client until released.
In working out what guestmount_mount would do, it occurs to me that you
can do this without requiring either multiple connections to the
appliance or a callback mechanism, as long as the caller takes
responsibility for the guestfs handle. Consider
guestfsmount_mount_handle(g, mountpoint), which does:
1. Create a new filesystem using the given handle.
2. Mount it.
3. Create a new thread to run the FUSE event loop.
You could then do:
g.foo()
h = guestmount_mount_handle(g, mp) (h is an opaque handle)
... it is the responsibility of the caller not to use g here ...
guestmount_unmount(mh)
g.bar()
h would contain at least the mountpoint and the thread handle.
guestmount_unmount(mh) would therefore be:
umount(mh->mp)
mh->thread.join()
> Also, we're not bringing FUSE into the main API.
Is this such a problem? We could dlopen libfuse if the dependency on
libfuse was a problem ...
Actually, I may be softening to this if the API can be more like a
regular API call. I think my guestmount_mount_handle example could be
turned into something usable:
g.foo()
g.mount_local(mp)
... g cannot be used here ...
g.unmount_local()
g.bar()
The handle would be stored in g itself, so only 1 mount would be
supported at any one time.
This could be usefully extended in 2 ways I can think of:
Firstly, guestfs could be made threadsafe by simply putting a mutex
around all api calls. That is, calls can be made simultaneously from 2
different threads, but they will run sequentially. This could be
improved upon by redesigning the protocol, but I suspect it would be
perfectly adequate in practice. This would make g usable between calls
to mount_local and unmount_local(), as long as mount points are not
modified and the handle is not closed.
Secondly, the mechanism I described before for connecting to a running
appliance remains generally useful. guestmount could still be updated to
create a handle which uses an existing appliance.
On the face of it, neither of these extensions seems particularly
onerous to implement either.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
4760
days inactive
4761
days old
13 comments
2 participants
participants (2)
-
Matthew Booth -
Richard W.M. Jones