Re: [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii'

[Greg Kurz]

On Fri, 17 May 2019 10:40:48 +0200
Christian Schoenebeck <address@hidden> wrote:

> On Dienstag, 7. Mai 2019 18:16:08 CEST Christian Schoenebeck wrote:
> > Here are the archive links for latest v3 patch set [5(+1) patches total]:
> > 
> > [PATCH v3 0/5] 9p: Fix file ID collisions:
> > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01143.html
> > 
> > [PATCH v3 1/5] 9p: mitigates most QID path collisions:
> > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01142.html
> > 
> > [PATCH v3 2/5] 9P: trivial cleanup of QID path collision mitigation:
> > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01140.html
> > 
> > [PATCH v3 3/5] 9p: persistency of QID path beyond reboots / suspensions:
> > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01144.html
> > 
> > [PATCH v3 4/5] 9p: use variable length suffixes for inode mapping:
> > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01141.html
> > 
> > [PATCH v3 5/5] 9p: adds virtfs 'vii' device parameter
> > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01138.html
> > 
> > And the optional libvirt patch:
> > 
> > [libvirt patch] qemu: adds support for virtfs 9p argument 'vii':
> > https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01223.html
> >   
> > > > Please just have a glimpse on that v3 thread, and before I address the
> > > > details that you requested (I have reviewed them all already and will
> > > > address them), I would like you to ask you for a coarse feedback on
> > > > design/features first.  
> > >   
> > > > Because there are some things where I am unresolved on design level 
> > > > yet:  
> > > 
> > > I'll try but probably not before next week.  
> 
> Hi Greg, you have not forgotten about me, did you? ;-)
> 

Hi Christian,

I have certainly not forgotten but I had (and still have) some more urgent
work to do and I couldn't find time for this... Sorry :)

> Or should I go ahead and provide a v4 next week addressing the issues 
> discussed so far?
> 

Thinking again about the initial issue raised by Antonios, I agree we
should at least detect collisions in the existing 9pfs code and
emit an error rather than silently returning duplicate QIDs to the
client. This would be patch 2 from Antonios's series: only allow
a single host device for a given fs device.

Then, we come to the bulk problem: how to handle the case where we
have multiple devices involved in a directory we want to share ?
Antonios's proposal is a clever way to address the collisions, but
your work proves it isn't enough... Before going forward, I'd like
to consider another approach.

What about:

1) de-compose the shared directory on a per-device basis,
   ie. identify all mount points under the shared directory

2) expose found mount points separately, each with its onw 9p device

3) re-compose the directory tree within the guest using the same topology
   as the host

ie. if you want to share /vm/fs and

/vm/fs on device A
/vm/fs/shares on device B
/vm/fs/tmp on device C

you would start QEMU with

-fsdev local,path=/vm/fs,id=fsdev0... \
-device virtio-9p,fsdev=fsdev0,mount_tag=tag0 \
-fsdev local,path=/vm/fs,id=fsdev1... \
-device virtio-9p,fsdev=fsdev1,mount_tag=tag1 \
-fsdev local,path=/vm/fs,id=fsdev2... \
-device virtio-9p,fsdev=fsdev2,mount_tag=tag2

and /etc/fstab in the guest:

tag0    /       9p      nofail,trans=virtio,version=9p2000.L   0 0
tag1    /shares 9p      nofail,trans=virtio,version=9p2000.L   0 0
tag2    /tmp    9p      nofail,trans=virtio,version=9p2000.L   0 0

This involves some more work for the user but it doesn't require
any changes in QEMU.

Would this approach solve the issues you've been hitting with Samba ?

Cheers,

--
Greg