From: Christian Schoenebeck via Qemu-devel <qemu-devel@nongnu.org>
To: qemu-devel@nongnu.org
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"Christian Schoenebeck" <qemu_oss@crudebyte.com>,
"Greg Kurz" <groug@kaod.org>,
"Antonios Motakis" <antonios.motakis@huawei.com>
Subject: Re: [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii'
Date: Fri, 17 May 2019 15:23:01 +0200 [thread overview]
Message-ID: <1723391.cvQaRflHa6@silver> (raw)
In-Reply-To: <20190517143029.25454663@bahia.lan>
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
next prev parent reply other threads:[~2019-05-17 13:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 14:37 [Qemu-devel] [PATCH v3 0/5] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-04-23 11:30 ` [Qemu-devel] [PATCH v3 1/5] 9p: mitigates most QID path collisions Christian Schoenebeck via Qemu-devel
2019-05-07 12:42 ` Daniel P. Berrangé
2019-05-07 13:11 ` Christian Schoenebeck via Qemu-devel
2019-05-07 13:13 ` Daniel P. Berrangé
2019-04-23 11:35 ` [Qemu-devel] [PATCH v3 2/5] 9P: trivial cleanup of QID path collision mitigation Christian Schoenebeck via Qemu-devel
2019-05-07 12:43 ` Daniel P. Berrangé
2019-04-23 11:41 ` [Qemu-devel] [PATCH v3 3/5] 9p: persistency of QID path beyond reboots / suspensions Christian Schoenebeck via Qemu-devel
2019-05-03 14:51 ` [Qemu-devel] [PATCH v3 4/5] 9p: use variable length suffixes for inode mapping Christian Schoenebeck via Qemu-devel
2019-05-05 21:41 ` [Qemu-devel] [PATCH v3 5/5] 9p: adds virtfs 'vii' device parameter Christian Schoenebeck via Qemu-devel
2019-05-06 17:58 ` [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii' Christian Schoenebeck via Qemu-devel
2019-05-07 9:55 ` Greg Kurz
2019-05-07 12:23 ` Christian Schoenebeck via Qemu-devel
2019-05-07 15:42 ` Greg Kurz
2019-05-07 16:16 ` Christian Schoenebeck via Qemu-devel
2019-05-17 8:40 ` Christian Schoenebeck via Qemu-devel
2019-05-17 12:30 ` Greg Kurz
2019-05-17 13:23 ` Christian Schoenebeck via Qemu-devel [this message]
2019-05-17 14:47 ` Greg Kurz
2019-05-17 20:53 ` Christian Schoenebeck via Qemu-devel
2019-05-20 14:05 ` Greg Kurz
2019-05-22 16:03 ` Christian Schoenebeck via Qemu-devel
2019-06-03 6:57 ` Greg Kurz
2019-06-03 9:17 ` Christian Schoenebeck via Qemu-devel
2019-05-07 12:57 ` Daniel P. Berrangé
2019-05-07 13:48 ` Christian Schoenebeck via Qemu-devel
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=1723391.cvQaRflHa6@silver \
--to=qemu-devel@nongnu.org \
--cc=antonios.motakis@huawei.com \
--cc=berrange@redhat.com \
--cc=groug@kaod.org \
--cc=qemu_oss@crudebyte.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.