[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] New tool proposal

On Fri, Jun 01, 2012 at 05:11:37PM +0800, Wanlong Gao wrote:
> On 05/28/2012 03:48 PM, Richard W.M. Jones wrote:
> > On Sun, May 27, 2012 at 02:52:59PM +0800, Wanlong Gao wrote:
> >> I looked into this, now Rich, I have a more question,
> >> if we doing like
> >> virt-diff --seed Guest0 -d Guest1 -d Guest2 /etc
> >> We can mount the device of Guest0 to "/", but where the devices from Guest1 and Guest2 can be mounted?
> > 
> > The mkmountpoint call allows you to have multiple "roots":
> > 
> > http://libguestfs.org/guestfs.3.html#guestfs_mkmountpoint
> > 
> > *However*, this won't work for general guests, where for example two
> > guests might have conflicting logical volumes or UUIDs which are
> > duplicated.  It's simply not possible to safely mount multiple guests
> > in a single appliance.  The solution is to use two libguestfs handles.
> It seems hard to launch two libguestfs handles at the same time, right?
> Now, many functions like inspect_mount(), inspect_do_decrypt() use the
> global libguestfs handle without any argument, so, when inspecting two
> different handles, we can't use these functions now, would you like to
> make them being able to handle individual libguestfs handles?

Those functions are part of the guestfish shared code, and guestfish
assumes there's only a single handle open (the global variable 'g').

Of course that's not a limitation of the API, just of guestfish.

Certainly you could modify them so that you have to pass the handle,
if that's going to help for this new virt-diff program.  Or you could
duplicate the code as necessary.

> And, some global values like live, read_only, etc.
> And, we haven't considered that we could launch more than one libguestfs
> handles at the same time, right? Are there some troubles doing things like
> this?

Same thing here.  All of the tools like virt-df, etc which use the
guestfish shared code assume a single handle.  You could change that
assumption, or just copy the code and modify it in your tool,
whichever makes more sense.


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#)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]