[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] RFC: use case for adding QMP, block jobs &
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [Qemu-block] RFC: use case for adding QMP, block jobs & multiple exports to qemu-nbd ? |
Date: |
Thu, 2 Nov 2017 19:06:42 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 02/11/2017 13:02, Daniel P. Berrange wrote:
>
> After all that long background explanation, what I'm wondering is whether
> there is any interest / desire to extend qemu-nbd to have more advanced
> featureset than simply exporting a single disk image which must be listed
> at startup time.
>
> - Ability to start qemu-nbd up with no initial disk image connected
> - Option to have a QMP interface to control qemu-nbd
> - Commands to add / remove individual disk image exports
> - Commands for doing the drive-mirror / backing file pivot
>
> It feels like this wouldn't require significant new functionality in either
> QMP or block layer. It ought to be mostly a cache of taking existing QMP
> code and wiring it up in qemu-nbd, and only exposing a whitelisted subset
> of existing QMP commands related to block backends.
I think adding a QMP interface is a good idea; if you're using Unix
sockets I don't see much benefit in using multiple disk image exports
from a single qemu-nbd instance, but maybe you aren't?
At this point it does indeed feel a lot like --machine none. Perhaps we
should just have a new binary /usr/bin/qemu-noguest instead of
augmenting qemu-nbd.
Would you also add rerror/werror support to qemu-nbd at the same time?
Paolo
Re: [Qemu-devel] [Qemu-block] RFC: use case for adding QMP, block jobs & multiple exports to qemu-nbd ?,
Paolo Bonzini <=
Re: [Qemu-devel] [Qemu-block] RFC: use case for adding QMP, block jobs & multiple exports to qemu-nbd ?, Max Reitz, 2017/11/02
Re: [Qemu-devel] RFC: use case for adding QMP, block jobs & multiple exports to qemu-nbd ?, Fam Zheng, 2017/11/03