[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Creating / formatting volumes with non-file based block bac

From: Daniel P. Berrange
Subject: [Qemu-devel] Creating / formatting volumes with non-file based block backends
Date: Wed, 11 May 2016 15:28:41 +0100
User-agent: Mutt/1.6.0 (2016-04-01)

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.

|: 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 via email to

[Prev in Thread] Current Thread [Next in Thread]