From: Fam Zheng <famz@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
Eric Blake <eblake@redhat.com>,
pbonzini@redhat.com, stefanha@redhat.com
Subject: Re: [Qemu-devel] RFC: use case for adding QMP, block jobs & multiple exports to qemu-nbd ?
Date: Fri, 3 Nov 2017 14:00:46 +0800 [thread overview]
Message-ID: <20171103060046.GB18539@lemon> (raw)
In-Reply-To: <20171102120223.GI32533@redhat.com>
On Thu, 11/02 12:02, Daniel P. Berrange wrote:
> One alternative approach to doing this would be to suggest that we should
> instead just spawn qemu-system-x86_64 with '--machine none' and use that
> as a replacement for qemu-nbd, since it already has a built-in NBD server
> which can do many exports at once and arbitrary block jobs.
Here is a crazy idea from KVM Forum discussions that may relate, so mention it
here: we could move the QEMU block layer to a separate program and guest can use
vhost-user-{blk,scsi} for I/O. It is something like this:
master-disk1.qcow2 (qemu-nbd)
^
| backing
|
cache-disk1.qcow2 (qemu-vhost) <-------------.
^ |
| backing | backing
| |
+- vm-a-disk1.qcow2 (qemu-vhost) +- vm-a-disk2.qcow2 (qemu-vhost)
^ ^
| vhost-user-blk | vhost-user-blk
| |
+- VM-1 (qemu-system-XXX) +- VM-2 (qemu-system-XXX)
So on the compute node, there will be N qemu-system-XXX processes (where N is
the number of VMs) and 1 qemu-vhost process.
The hypothetical qemu-vhost program needs to support QMP as well and it runs the
COR/mirroring jobs from master disk to cache disk, just like what you propose to
do with the extended qemu-nbd. The only difference is replacing the local NBD
with vhost-user, which is more efficient.
Fam
next prev parent reply other threads:[~2017-11-03 6:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-02 12:02 [Qemu-devel] RFC: use case for adding QMP, block jobs & multiple exports to qemu-nbd ? Daniel P. Berrange
2017-11-02 16:40 ` [Qemu-devel] [Qemu-block] " Kashyap Chamarthy
2017-11-02 17:04 ` Daniel P. Berrange
2017-11-02 17:50 ` Eric Blake
2017-11-03 10:04 ` Stefan Hajnoczi
2017-11-03 10:16 ` Daniel P. Berrange
2017-11-02 18:06 ` Paolo Bonzini
2017-11-02 21:38 ` Max Reitz
2017-11-03 9:59 ` Stefan Hajnoczi
2017-11-09 13:54 ` Markus Armbruster
2017-11-09 16:02 ` Daniel P. Berrange
2017-11-03 6:00 ` Fam Zheng [this message]
2017-11-03 10:01 ` Stefan Hajnoczi
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=20171103060046.GB18539@lemon \
--to=famz@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@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.