All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: virtio-fs@redhat.com, Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel@nongnu.org, Vivek Goyal <vgoyal@redhat.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH] virtiofsd: Show submounts
Date: Thu, 30 Apr 2020 15:34:25 +0100	[thread overview]
Message-ID: <20200430143425.GD2184629@redhat.com> (raw)
In-Reply-To: <20200430142013.GI2874@work-vm>

On Thu, Apr 30, 2020 at 03:20:13PM +0100, Dr. David Alan Gilbert wrote:
> * Vivek Goyal (vgoyal@redhat.com) wrote:
> > On Thu, Apr 30, 2020 at 09:58:12AM +0100, Dr. David Alan Gilbert wrote:
> > [..]
> > > > > Even without this patch, the SLAVE stuff worked so if you start the
> > > > > daemon and *then* mount under the shared directory, the guest sees it
> > > > > with or without this patch.
> > > > 
> > > > Hm, I don’t.  Do you really?
> > > 
> > > Yes! With your patch reverted:
> > > 
> > > Start virtiofsd, mount in the guest:
> > > 
> > > host:
> > > # ./virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/dgilbert/virtio-fs/fs  -o log_level=warn -o no_writeback
> > > 
> > > guest:
> > > # mount -t virtiofs myfs /sysroot
> > > 
> > > host:
> > > # findmnt -o +PROPAGATION -N 6100
> > > TARGET SOURCE                                                              FSTYPE OPTIONS                                                      PROPAGATION
> > > /      /dev/mapper/fedora_dgilbert--t580-root[/home/dgilbert/virtio-fs/fs] xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,no private,slave
> > > # mount -t tmpfs /dev/null /home/dgilbert/virtio-fs/fs/tmp
> > > # findmnt -o +PROPAGATION -N 6100
> > > TARGET SOURCE                                                              FSTYPE OPTIONS                                                      PROPAGATION
> > > /      /dev/mapper/fedora_dgilbert--t580-root[/home/dgilbert/virtio-fs/fs] xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,no private,slave
> > > └─/tmp /dev/null                                                           tmpfs  rw,relatime,seclabel                                         private,slave
> > 
> > Why is it showing a mount point at "/tmp". If mount point propagated, then
> > inside guest we should see a mount point at /sysroot/tmp?
> 
> That findmnt is on the host.
> 
> > So there are two things.
> > 
> > A. Propagation of mount from host to virtiofsd.
> > B. Visibility of that mount inside guest over fuse protocol (submount
> >   functionality).
> > 
> > I think A works for me without any patches. But don't think B is working
> > for me. I don't see the submount inside guest. 
> > 
> > > # touch /home/dgilbert/virtio-fs/fs/tmp/hello
> > > 
> > > guest:
> > > # ls -l /sysroot/tmp
> > > total 0
> > > -rw-r--r-- 1 root root 0 Apr 30 08:50 hello
> > 
> > Do a "findmnt /sysroot/tmp" inside guest and see what do you see.
> > 
> > You will be able to see "hello" as long as virtiofsd sees the new
> > mount point, I think. And guest does not have to see that mount point
> > for this simple test to work.
> 
> Right, the guest just sees:
> 
> `-/sysroot                            myfs       virtiof rw,relatime

That is a good thing surely ? If I'm exporting "/sysroot" from the host,
I want the content in "/sysroot/some/sub/mount" to be visible to the
guest, but I don't want the guest to see "/sysroot/some/sub/mount"
as an actual mount point. That would be leaking information about the
host storage setup into the guest. The host admin should be free to
re-arrange submounts in the host OS, to bring more storage space online,
and have this be transparent to the guest OS.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: virtio-fs@redhat.com, qemu-devel@nongnu.org,
	Vivek Goyal <vgoyal@redhat.com>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Virtio-fs] [PATCH] virtiofsd: Show submounts
Date: Thu, 30 Apr 2020 15:34:25 +0100	[thread overview]
Message-ID: <20200430143425.GD2184629@redhat.com> (raw)
In-Reply-To: <20200430142013.GI2874@work-vm>

On Thu, Apr 30, 2020 at 03:20:13PM +0100, Dr. David Alan Gilbert wrote:
> * Vivek Goyal (vgoyal@redhat.com) wrote:
> > On Thu, Apr 30, 2020 at 09:58:12AM +0100, Dr. David Alan Gilbert wrote:
> > [..]
> > > > > Even without this patch, the SLAVE stuff worked so if you start the
> > > > > daemon and *then* mount under the shared directory, the guest sees it
> > > > > with or without this patch.
> > > > 
> > > > Hm, I don’t.  Do you really?
> > > 
> > > Yes! With your patch reverted:
> > > 
> > > Start virtiofsd, mount in the guest:
> > > 
> > > host:
> > > # ./virtiofsd --socket-path=/tmp/vhostqemu -o source=/home/dgilbert/virtio-fs/fs  -o log_level=warn -o no_writeback
> > > 
> > > guest:
> > > # mount -t virtiofs myfs /sysroot
> > > 
> > > host:
> > > # findmnt -o +PROPAGATION -N 6100
> > > TARGET SOURCE                                                              FSTYPE OPTIONS                                                      PROPAGATION
> > > /      /dev/mapper/fedora_dgilbert--t580-root[/home/dgilbert/virtio-fs/fs] xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,no private,slave
> > > # mount -t tmpfs /dev/null /home/dgilbert/virtio-fs/fs/tmp
> > > # findmnt -o +PROPAGATION -N 6100
> > > TARGET SOURCE                                                              FSTYPE OPTIONS                                                      PROPAGATION
> > > /      /dev/mapper/fedora_dgilbert--t580-root[/home/dgilbert/virtio-fs/fs] xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,no private,slave
> > > └─/tmp /dev/null                                                           tmpfs  rw,relatime,seclabel                                         private,slave
> > 
> > Why is it showing a mount point at "/tmp". If mount point propagated, then
> > inside guest we should see a mount point at /sysroot/tmp?
> 
> That findmnt is on the host.
> 
> > So there are two things.
> > 
> > A. Propagation of mount from host to virtiofsd.
> > B. Visibility of that mount inside guest over fuse protocol (submount
> >   functionality).
> > 
> > I think A works for me without any patches. But don't think B is working
> > for me. I don't see the submount inside guest. 
> > 
> > > # touch /home/dgilbert/virtio-fs/fs/tmp/hello
> > > 
> > > guest:
> > > # ls -l /sysroot/tmp
> > > total 0
> > > -rw-r--r-- 1 root root 0 Apr 30 08:50 hello
> > 
> > Do a "findmnt /sysroot/tmp" inside guest and see what do you see.
> > 
> > You will be able to see "hello" as long as virtiofsd sees the new
> > mount point, I think. And guest does not have to see that mount point
> > for this simple test to work.
> 
> Right, the guest just sees:
> 
> `-/sysroot                            myfs       virtiof rw,relatime

That is a good thing surely ? If I'm exporting "/sysroot" from the host,
I want the content in "/sysroot/some/sub/mount" to be visible to the
guest, but I don't want the guest to see "/sysroot/some/sub/mount"
as an actual mount point. That would be leaking information about the
host storage setup into the guest. The host admin should be free to
re-arrange submounts in the host OS, to bring more storage space online,
and have this be transparent to the guest OS.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  parent reply	other threads:[~2020-04-30 14:38 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 13:35 [PATCH] virtiofsd: Show submounts Max Reitz
2020-04-24 13:35 ` [Virtio-fs] " Max Reitz
2020-04-27 17:59 ` Dr. David Alan Gilbert
2020-04-27 17:59   ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-28  6:06   ` Max Reitz
2020-04-28  6:06     ` [Virtio-fs] " Max Reitz
2020-04-28  9:59     ` Dr. David Alan Gilbert
2020-04-28  9:59       ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-28 10:13       ` Max Reitz
2020-04-28 10:13         ` [Virtio-fs] " Max Reitz
2020-04-28 10:19         ` Dr. David Alan Gilbert
2020-04-28 10:19           ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-28  8:46   ` Daniel P. Berrangé
2020-04-28  8:46     ` [Virtio-fs] " Daniel P. Berrangé
2020-04-28 14:51   ` Stefan Hajnoczi
2020-04-28 14:51     ` [Virtio-fs] " Stefan Hajnoczi
2020-04-28 14:58     ` Daniel P. Berrangé
2020-04-28 14:58       ` [Virtio-fs] " Daniel P. Berrangé
2020-04-28 19:07     ` Miklos Szeredi
2020-04-28 19:07       ` Miklos Szeredi
2020-04-28 19:15       ` Dr. David Alan Gilbert
2020-04-28 19:15         ` Dr. David Alan Gilbert
2020-04-29  7:59         ` Miklos Szeredi
2020-04-29  7:59           ` Miklos Szeredi
2020-04-29  9:26           ` Miklos Szeredi
2020-04-29  9:26             ` Miklos Szeredi
2020-04-29 12:34             ` Vivek Goyal
2020-04-29 12:34               ` Vivek Goyal
2020-04-29 12:41               ` Vivek Goyal
2020-04-29 12:41                 ` Vivek Goyal
2020-04-29  8:31         ` Max Reitz
2020-04-29  8:31           ` Max Reitz
2020-04-29  8:52           ` Miklos Szeredi
2020-04-29  8:52             ` Miklos Szeredi
2020-04-29  9:31             ` Max Reitz
2020-04-29  9:31               ` Max Reitz
2020-04-29 14:57   ` Dr. David Alan Gilbert
2020-04-29 14:57     ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-29 15:35     ` Vivek Goyal
2020-04-29 15:35       ` [Virtio-fs] " Vivek Goyal
2020-04-30  8:06     ` Max Reitz
2020-04-30  8:06       ` [Virtio-fs] " Max Reitz
2020-04-30  8:58       ` Dr. David Alan Gilbert
2020-04-30  8:58         ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-30  9:21         ` Max Reitz
2020-04-30  9:21           ` [Virtio-fs] " Max Reitz
2020-04-30 11:38           ` Max Reitz
2020-04-30 11:38             ` [Virtio-fs] " Max Reitz
2020-04-30 13:56         ` Vivek Goyal
2020-04-30 13:56           ` [Virtio-fs] " Vivek Goyal
2020-04-30 14:20           ` Dr. David Alan Gilbert
2020-04-30 14:20             ` [Virtio-fs] " Dr. David Alan Gilbert
2020-04-30 14:24             ` Vivek Goyal
2020-04-30 14:24               ` [Virtio-fs] " Vivek Goyal
2020-04-30 14:34             ` Daniel P. Berrangé [this message]
2020-04-30 14:34               ` Daniel P. Berrangé
2020-04-30 14:41               ` Vivek Goyal
2020-04-30 14:41                 ` [Virtio-fs] " Vivek Goyal
2020-04-30 14:47                 ` Daniel P. Berrangé
2020-04-30 14:47                   ` [Virtio-fs] " Daniel P. Berrangé
2020-04-30 15:41                   ` Vivek Goyal
2020-04-30 15:41                     ` [Virtio-fs] " Vivek Goyal
2020-05-01 17:53 ` Dr. David Alan Gilbert
2020-05-01 17:53   ` [Virtio-fs] " Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200430143425.GD2184629@redhat.com \
    --to=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtio-fs@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.