From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZriIu-0007W7-2y for qemu-devel@nongnu.org; Thu, 29 Oct 2015 04:11:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZriIt-00040z-4B for qemu-devel@nongnu.org; Thu, 29 Oct 2015 04:11:24 -0400 Date: Thu, 29 Oct 2015 09:11:15 +0100 From: Kevin Wolf Message-ID: <20151029081115.GA3854@noname.redhat.com> References: <20151028235824.GB663@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151028235824.GB663@redhat.com> Subject: Re: [Qemu-devel] How to specify the full block driver tree on the CLI ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: stefanha@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org Am 29.10.2015 um 00:58 hat Daniel P. Berrange geschrieben: > As previously mentioned, I'm working on support for LUKS full disk > encryption in QEMU. I have a simple driver implemented that works > on top of plain files. eg I can launch qemu-io thus: > > $ qemu-io /home/berrange/VirtualMachines/demo.luks-aes-cbc-plain-sha256 > > and it'll probe the luks format & instantiate my "luks" block driver impl > on top of the "file" driver. IIUC, I should be able to layer this format > driver on top of any of the QEMU block driver backends though. In particular > I want to be able to layer it on top of any of the network drivers (RBD, > iSCSI and glusterfs). This part should work automatically as well if you just use the right URL. qemu probes the format even if you're using a non-file protocol. > I'm struggling to figure out the right syntax to > specify this to QEMU though, using either qemu-io, or the system emulators > with the -drive arg. Are there any docs somewhere about the way to > structure the command line arguments to build up a stack of block drivers. You have a two options. The one that is universal (that is, it works in all places that open an image), but a bit awkward to use manually is the json: pseudo-protocol. The "filename" then contains a JSON object of the QAPI BlockdevOptions type. The QAPI schema (qapi/block-core.json) is probably the best documentation you get. When specifying JSON objects on the -drive command line option, don't forget to escape commas by doubling. For example: qemu-system-x86_64 -drive file='json:{"driver":"luks",,\ "secret":"x",,"file":{"driver":"file",,"filename":"test.luks"}}' In qemu proper, you can use a dot syntax for -drive instead: qemu-system-x86_64 -drive \ driver=luks,\ secret=x,\ file.driver=file,\ file.filename=test.luks In qemu-io, you can't use such syntax on the command line, but the open command supports an -o option that accepts the same dot syntax. Note that qemu-img can't deal with this stuff yet, so you'll have trouble creating an image with such a specification. I guess you need to create it as a local file first and then use non-qemu tools to copy it somewhere where it's exported by rbd, iscsi or gluster. > I'd like to figure out the following combinations, for qemu-io, qemu-img > and system emulator -drive syntax. > > - luks -> file > - qcow2 -> luks -> file This is the only case that isn't exactly the same as the example above. I guess eventually we'll want to make qemu probe on top of luks, so that you can just specify file=foo.qcow2.luks and it works. For now, you have to be explicit and nest a level deeper: qemu-system-x86_64 -drive \ driver=qcow2,\ file.driver=luks,\ file.secret=x,\ file.file.driver=file,\ file.file.filename=test.luks Or the same structure in JSON, of course. > - luks -> rbd > - luks -> iscsi > - luks -> glusterfs > > Currently the only required QemuOpt for the luks driver is the ID of > a secret to provide the password. Hope that helps. Kevin