From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41163 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPKwa-0001Z7-Rw for qemu-devel@nongnu.org; Thu, 17 Jun 2010 15:40:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPKwZ-0001ND-Ji for qemu-devel@nongnu.org; Thu, 17 Jun 2010 15:40:08 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:39287) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPKwZ-0001N2-H2 for qemu-devel@nongnu.org; Thu, 17 Jun 2010 15:40:07 -0400 Received: by vws5 with SMTP id 5so885555vws.4 for ; Thu, 17 Jun 2010 12:40:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 17 Jun 2010 20:40:06 +0100 Message-ID: Subject: Re: [Qemu-devel] RFC v3: blockdev_add & friends, brief rationale, QMP docs From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Christoph Hellwig , qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Gerd Hoffmann On Thu, Jun 17, 2010 at 1:49 PM, Markus Armbruster wrot= e: > Stefan Hajnoczi writes: > >> On Wed, Jun 16, 2010 at 6:27 PM, Markus Armbruster w= rote: >>> blockdev_add >>> ------------ >>> >>> Add host block device. >>> >>> Arguments: >>> >>> - "id": the host block device's ID, must be unique (json-string) >>> - "format": image format (json-string, optional) >>> =A0 =A0- Possible values: "raw", "qcow2", ... >> >> What is the default when unset? =A0(I expect we'll auto-detect the >> format but this should be documented.) > > For command line and human monitor, we definitely want a sensible > default. =A0I sketched one in section "Command line syntax". =A0I'll quot= e > it for your convenience a few lines down. Ahem...the part that I skipped over ;). I should have read your entire email, thanks for pointing it out. > To let users ask for this explicitely, we could have pseudo-format > "auto". > > We also need a pseudo-format "probe", which guesses the format from the > image contents. =A0Can't be made the default, because it's insecure. In which scenario is probing the image format a security issue? I'm trying to think up scenarios where a cloud user modifies the guest disk image and gets QEMU to re-open the image file as another format, perhaps this would make the cloud owner/admin unhappy. I don't see a threat except for image format drivers have security bugs (corrupt images leading to arbitrary code execution). >>> (2) It's possible to list supported disk formats and protocols by >>> =A0 =A0running QEMU with arguments "-blockdev_add \?". >> >> Is there an query-block-driver command or something in QMP to >> enumerate supported formats and protocols? =A0Not sure how useful this >> would be to the management stack - blockdev_add will probably return >> an error if an attempt is made to open an unsupported file. > > QMP should be "self-documenting": a client should be able to list > commands, their arguments, and possible argument values. =A0Listing > supported formats then becomes "list possible values of command > blockdev_add's argument format". Nice :). >>> blockdev_del >>> ------------ >>> >>> Remove a host block device. >>> >>> Arguments: >>> >>> - "id": the host block device's ID (json-string) >>> >>> Example: >>> >>> -> { "execute": "blockdev_del", "arguments": { "id": "blk1" } } >>> <- { "return": {} } >> >> What about an attached guest device? =A0Will this fail if the virtio-blk >> PCI device is still present? =A0For SCSI I imagine we can usually just >> remove the host block device. =A0For IDE there isn't hotplug support >> AFAIK, what happens? > > Command fails. =A0You have to device_del the device first. =A0Which is on= ly > possible if its bus supports hot-plug. I think this deserves to be in the documentation. Stefan