All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: stefanha@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] How to specify the full block driver tree on the CLI ?
Date: Thu, 29 Oct 2015 17:15:20 +0900	[thread overview]
Message-ID: <20151029081520.GB32623@redhat.com> (raw)
In-Reply-To: <20151029081115.GA3854@noname.redhat.com>

On Thu, Oct 29, 2015 at 09:11:15AM +0100, Kevin Wolf wrote:
> 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.

Ahh, interesting, I guess I should have just tested it rather than
assuming it doesn't work :-)

> > 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 wonder if my patches to qemu-io & qemu-img here do the right thing to
make this dot syntax work....

   https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg04382.html
   https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg04375.html

> 
> > 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.

Yep, very helpful thanks.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

  reply	other threads:[~2015-10-29  8:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28 23:58 [Qemu-devel] How to specify the full block driver tree on the CLI ? Daniel P. Berrange
2015-10-29  8:11 ` Kevin Wolf
2015-10-29  8:15   ` Daniel P. Berrange [this message]
2015-10-29  8:31     ` Kevin Wolf

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=20151029081520.GB32623@redhat.com \
    --to=berrange@redhat.com \
    --cc=kwolf@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.