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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).