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.
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