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

[Greg Kurz]

On Fri, 17 May 2019 15:23:01 +0200
Christian Schoenebeck <address@hidden> wrote:

> On Freitag, 17. Mai 2019 14:30:29 CEST Greg Kurz wrote:
> > 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...  
> 
> With the patch set I have right now, things finally bahave smooth.
> 
> > 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.  
> 
> So your suggestion is actually: don't fix it.
> 

Potentially yes if another approach is satisfying enough, as I wouldn't
want to over-engineer too much around this 9p imposed limitation. The
right thing to do would be to come up with a new version of the protocol
with variable sized QIDs and call it a day.

> "Some" more work for the user is a quantity of how many guests you are 
> running, multiplied by the nested virtualization levels you might have = 
> potentially a lot of work for admins.
> 

Maybe, I don't have enough feedback on 9p use cases to have a clear
picture...

> > Would this approach solve the issues you've been hitting with Samba ?  
> 
> No, because that completely neglects runtime changes on a higher level 
> (host), 

Unless I'm missing something, runtime changes would be neglected as well
with the "vii" property since it is static for the device lifetime.

> plus it completely destroys the fundamental idea about 9p, which is about 
> transparency of the higher level(s).
> 

That's a point indeed, even if again I'm not sure if this is a frequent
case to share a directory tree spanning over multiple devices.

> May I ask, do you have concrete reasons why you want to abondon the entire 
> patch set? Because that's what it sounds to me.
> 

I don't have that much time to spend on 9p maintainership, for both
reviewing and fixing bugs (CVEs most of the time). So, yes it may
sound like I want to drop the patchset, but it's just I need to be
convinced I won't regret having merged a huge change like this...
when I'll have to support it alone later ;-)

For the moment, I'm not convinced by the "vii" solution. It even
motivated my suggestion of having several devices actually, since
the paths you would put in there are known before starting QEMU.

It might take me some more rounds of discussion to decide. I understand
it is frustrating but bear with me :)

> Best regards,
> Christian Schoenebeck

Cheers,

--
Greg