All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: [Qemu-devel] Creating / formatting volumes with non-file based block backends
Date: Wed, 11 May 2016 15:28:41 +0100	[thread overview]
Message-ID: <20160511142840.GJ20333@redhat.com> (raw)

I'm looking once again at the process of creating volumes for QEMU formatted
with LUKS encryption.

For plain files it is easily possible with

  qemu-img create -f luks \
                  --object secret,id=sec0,file=passphrase.txt \
                  -o key-secret=sec0 \
                  demo.luks 10G

where 'demo.luks' is the filename to be created, mapping through to the
block driver API

  int (*bdrv_create)(const char *filename, QemuOpts *opts, Error **errp);

This creates a plain file and then formats it with LUKS.

Now if I want to instead create a non-plain file (eg a glusterfs image)
and format it with LUKS, AFAICT, this is not possible since we can't
specify options / driver for the next level below the LUKS block backend,
we've only got a plain filename.  I'm wondering if perhaps using the JSON
format for the 'filename' parameter value might work, but it would be
desirable to use the regular nested-opts syntax available everywhere else
in the block layer.

A second problem arises if I have an already existing volume that I wish
to merely format with luks. There's no way to skip the create step for
the block backend below the LUKS driver, as create + format are combined
into the same operation. It feels like there's a potential use case for
a separate 'qemu-img format' command which just takes a pre-existing image
and just formats a new image layout on top of it ?

Essentially I would like to be able to create a LUKS formatted image on
top of any QEMU block driver backend that supports the bdrv_create
operation. I would also like to be able to format LUKS onto any pre-existing
image for which there is a QEMU block driver backend with write support.

Any thoughts on this ?  If there's clarity around design / requirements,
I have potential free time for working on this in the 2.7 cycle.

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:[~2016-05-11 14:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20160511142840.GJ20333@redhat.com \
    --to=berrange@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.