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

Re: [Libguestfs] Fwd: Re: VirtFS Query

On Thu, 29 Sep 2011 17:12:22 +0100, "Richard W.M. Jones" <rjones redhat com> wrote:
> On Thu, Sep 29, 2011 at 09:19:03PM +0530, Harsh Bora wrote:
> > Richard, FYI.
> > 
> > On Wed, 28 Sep 2011 17:05:42 +0530, Harsh Bora
> > <harsh linux vnet ibm com> wrote:
> > >Hi Aneesh,
> > >
> > >Richard asked me if we have any plans to provide a solution for this use
> > >case:
> > >
> > >https://www.redhat.com/archives/libguestfs/2011-September/msg00089.html
> > >
> > >IIUC, VirtFS as a rootfs is targeted towards this requirement only,
> > >right? Any inputs ?
> > >
> > 
> > The right way to do this is to use a export path /guest and bind mount
> > needed directories within. VirtFS just export /guest and everything
> > works out easily. I already have autotest driving virtFS as root. So
> > that works easily
> That's not going to work for us.
> Firstly bind mounting requires root, which is no good for libguestfs.

Another alternative suggested by pekka for tools/kvm (native linux kvm)
is to create a directory layout as below

in /guest1-export/ 

 bin -> /host/bin
 sbin -> /host/sbin
 usr -> /host/usr
 lib -> /host/lib

and qemu starts with two export path /guest1-export as root and / of the
common image (or host) as /host on guest. Now 9p resolves symbolic links
in the guest. So which ever directory that need to be shared with host
can have a symlink and everything works 

> Secondly there are no directories that we could bind mount.  We really
> need the flexibility outlined in that email.  Just two examples of
> this (there are more):
>  - /usr/sbin in the appliance is not the same as /usr/sbin on the
>    host.  The appliance version should contain a subset of the host
>    directory, plus at least one extra binary (/usr/sbin/guestfsd).
>  - Because /etc files on the host can be arbitrarily modified, we need
>    to construct our own /etc directory, with files from the host and
>    files that we supply.
> What's may help here is some sort of plugin or passthrough mechanism
> letting us add our own 9p server/plugin without pushing all the
> complexity we need into qemu sources.
> More here:
> http://libguestfs.org/febootstrap.8.html#supermin_appliances

There is some level of plugability with VirtFS server already. You can
look at virtio-9p-local.c, virtio-9p-handle.c and virtio-9p-synth.c in
the example.  git://repo.or.cz/qemu/v9fs.git


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