qemu-devel
[Top][All Lists]
Advanced

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

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


From: Christian Schoenebeck
Subject: Re: [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii'
Date: Fri, 17 May 2019 15:23:01 +0200

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.

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

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

No, because that completely neglects runtime changes on a higher level (host), 
plus it completely destroys the fundamental idea about 9p, which is about 
transparency of the higher level(s).

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.

Best regards,
Christian Schoenebeck



reply via email to

[Prev in Thread] Current Thread [Next in Thread]