On Fri, Nov 03, 2017 at 02:00:46PM +0800, Fam Zheng wrote: > 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.
The vhost-user part can be added later. I think the first step is whether to add a QMP interface to qemu-nbd or use -machine none. Stefan
signature.asc
Description: PGP signature