QCOW2 to RBD format 2 in one step

QCOW2 to RBD format 2 in one step

[Wido den Hollander]

Hi,

While working on the CloudStack code for 4.2 I'm running into some 
problems with QCOW2 and RBD format 2.

A quick cap of the problem:

CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.

When a VM is deployed, this image will be copied (once) from Secondary 
Storage to Primary Storage, this is done by qemu-img which does the 
conversion.

When the image is on Primary Storage it will be copied to the 
destination volume and the Instance/VM is started.

In that last step I want to use layering, but the problem is that my 
image is RBD format 1 due to the qemu-img copy.

I can skip the qemu-img copy, but I have to find a way to go from QCOW2 
to RBD format 2 in preferably one step. There is a issue about this in 
the tracker [0], but that won't be finished on time.

Another idea would be to do QCOW2 -> RAW -> RBD format 2, but that extra 
step will take a lot of time. It would also require some temporary 
storage on the hypervisor.

I also thought of creating the RBD image prior to converting to it, but 
that fails, since qemu-img won't let you convert to a already existing 
image.

Any brights ideas? Maybe even doing the QCOW2 -> RAW format in memory? 
In Java?

The goal is to go from QCOW2 to RBD format 2 in one step.

[0]: http://tracker.ceph.com/issues/4897

-- 
Wido den Hollander
42on B.V.

Phone: +31 (0)20 700 9902
Skype: contact42on

Re: QCOW2 to RBD format 2 in one step

[Leen Besselink]

On Tue, May 14, 2013 at 12:16:32PM +0200, Wido den Hollander wrote:
> Hi,
> 

Hi Wido,

> While working on the CloudStack code for 4.2 I'm running into some
> problems with QCOW2 and RBD format 2.
> 
> A quick cap of the problem:
> 
> CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.
> 
> When a VM is deployed, this image will be copied (once) from
> Secondary Storage to Primary Storage, this is done by qemu-img which
> does the conversion.
> 
> When the image is on Primary Storage it will be copied to the
> destination volume and the Instance/VM is started.
> 
> In that last step I want to use layering, but the problem is that my
> image is RBD format 1 due to the qemu-img copy.
> 
> I can skip the qemu-img copy, but I have to find a way to go from
> QCOW2 to RBD format 2 in preferably one step. There is a issue about
> this in the tracker [0], but that won't be finished on time.
> 
> Another idea would be to do QCOW2 -> RAW -> RBD format 2, but that
> extra step will take a lot of time. It would also require some
> temporary storage on the hypervisor.
> 
> I also thought of creating the RBD image prior to converting to it,
> but that fails, since qemu-img won't let you convert to a already
> existing image.
> 
> Any brights ideas? Maybe even doing the QCOW2 -> RAW format in
> memory? In Java?
> 

I'm no expert, but would it be possible to change qemu-img to support writing RAW to standard out ?

So you can run qemu-img convert and pipe that drectly to the rbd import command ?

rbd import already supports standard in I believe.

Then you don't need any temporary storage.

Maybe something more efficient than RAW is possible as well ?

> The goal is to go from QCOW2 to RBD format 2 in one step.
> 
> [0]: http://tracker.ceph.com/issues/4897
> 
> -- 
> Wido den Hollander
> 42on B.V.
> 
> Phone: +31 (0)20 700 9902
> Skype: contact42on
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: QCOW2 to RBD format 2 in one step

[Wido den Hollander]

On 05/14/2013 12:34 PM, Leen Besselink wrote:
> On Tue, May 14, 2013 at 12:16:32PM +0200, Wido den Hollander wrote:
>> Hi,
>>

Hi Leen,

>
> Hi Wido,
>
>> While working on the CloudStack code for 4.2 I'm running into some
>> problems with QCOW2 and RBD format 2.
>>
>> A quick cap of the problem:
>>
>> CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.
>>
>> When a VM is deployed, this image will be copied (once) from
>> Secondary Storage to Primary Storage, this is done by qemu-img which
>> does the conversion.
>>
>> When the image is on Primary Storage it will be copied to the
>> destination volume and the Instance/VM is started.
>>
>> In that last step I want to use layering, but the problem is that my
>> image is RBD format 1 due to the qemu-img copy.
>>
>> I can skip the qemu-img copy, but I have to find a way to go from
>> QCOW2 to RBD format 2 in preferably one step. There is a issue about
>> this in the tracker [0], but that won't be finished on time.
>>
>> Another idea would be to do QCOW2 -> RAW -> RBD format 2, but that
>> extra step will take a lot of time. It would also require some
>> temporary storage on the hypervisor.
>>
>> I also thought of creating the RBD image prior to converting to it,
>> but that fails, since qemu-img won't let you convert to a already
>> existing image.
>>
>> Any brights ideas? Maybe even doing the QCOW2 -> RAW format in
>> memory? In Java?
>>
>
> I'm no expert, but would it be possible to change qemu-img to support writing RAW to standard out ?
>

No, qemu-img can't write to stdout. Due to various formats it supports.

> So you can run qemu-img convert and pipe that drectly to the rbd import command ?
>

If qemu-img would support writing to stdout there is the problem that 
I'm not using the rbd tool, but Java bindings for librbd and librados. 
I'm trying to avoid executing from Java.

> rbd import already supports standard in I believe.
>
> Then you don't need any temporary storage.
>
> Maybe something more efficient than RAW is possible as well ?
>
>> The goal is to go from QCOW2 to RBD format 2 in one step.
>>
>> [0]: http://tracker.ceph.com/issues/4897
>>
>> --
>> Wido den Hollander
>> 42on B.V.
>>
>> Phone: +31 (0)20 700 9902
>> Skype: contact42on
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Wido den Hollander
42on B.V.

Phone: +31 (0)20 700 9902
Skype: contact42on

Re: QCOW2 to RBD format 2 in one step

[Damien Churchill]

On 14 May 2013 12:52, Wido den Hollander <wido@42on.com> wrote:
>
> No, qemu-img can't write to stdout. Due to various formats it supports.
>

You could probably use qemu-nbd to mount the image as a nbd device and
then read from that using all the standard gear. Although I've never
actually used qemu-nbd myself...

Re: QCOW2 to RBD format 2 in one step

[Leen Besselink]

On Tue, May 14, 2013 at 01:52:28PM +0200, Wido den Hollander wrote:
> On 05/14/2013 12:34 PM, Leen Besselink wrote:
> >On Tue, May 14, 2013 at 12:16:32PM +0200, Wido den Hollander wrote:
> >>Hi,
> >>
> 
> Hi Leen,
> 
> >
> >Hi Wido,
> >
> >>While working on the CloudStack code for 4.2 I'm running into some
> >>problems with QCOW2 and RBD format 2.
> >>
> >>A quick cap of the problem:
> >>
> >>CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.
> >>
> >>When a VM is deployed, this image will be copied (once) from
> >>Secondary Storage to Primary Storage, this is done by qemu-img which
> >>does the conversion.
> >>
> >>When the image is on Primary Storage it will be copied to the
> >>destination volume and the Instance/VM is started.
> >>
> >>In that last step I want to use layering, but the problem is that my
> >>image is RBD format 1 due to the qemu-img copy.
> >>
> >>I can skip the qemu-img copy, but I have to find a way to go from
> >>QCOW2 to RBD format 2 in preferably one step. There is a issue about
> >>this in the tracker [0], but that won't be finished on time.
> >>
> >>Another idea would be to do QCOW2 -> RAW -> RBD format 2, but that
> >>extra step will take a lot of time. It would also require some
> >>temporary storage on the hypervisor.
> >>
> >>I also thought of creating the RBD image prior to converting to it,
> >>but that fails, since qemu-img won't let you convert to a already
> >>existing image.
> >>
> >>Any brights ideas? Maybe even doing the QCOW2 -> RAW format in
> >>memory? In Java?
> >>
> >
> >I'm no expert, but would it be possible to change qemu-img to support writing RAW to standard out ?
> >
> 
> No, qemu-img can't write to stdout. Due to various formats it supports.
> 

I meant extending qemu-img to support that, it would probably be less
work than the work needed for the issue below. But the longer I think
about it. It would only be able to do that for RAW. And RAW isn't very
efficient anyway.

> >So you can run qemu-img convert and pipe that drectly to the rbd import command ?
> >
> 
> If qemu-img would support writing to stdout there is the problem
> that I'm not using the rbd tool, but Java bindings for librbd and
> librados. I'm trying to avoid executing from Java.
> 
> >rbd import already supports standard in I believe.
> >
> >Then you don't need any temporary storage.
> >
> >Maybe something more efficient than RAW is possible as well ?
> >
> >>The goal is to go from QCOW2 to RBD format 2 in one step.
> >>
> >>[0]: http://tracker.ceph.com/issues/4897
> >>
> >>--
> >>Wido den Hollander
> >>42on B.V.
> >>
> >>Phone: +31 (0)20 700 9902
> >>Skype: contact42on
> >>--
> >>To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >--
> >To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> -- 
> Wido den Hollander
> 42on B.V.
> 
> Phone: +31 (0)20 700 9902
> Skype: contact42on

Re: QCOW2 to RBD format 2 in one step

[Alexandre DERUMIER]

Hi,

we do it with proxmox,

we create the target rbd volume at format v2 with "rbd .." commands,

then, we use qemu-img convert to copy from qcow2 to rbd.

We have patched qemu-img to be able to write to an existing volume.
(By default qemu-img convert try to create the volume)
https://git.proxmox.com/?p=pve-qemu-kvm.git;a=commit;h=c0cf085da9b6b1d21791dd88c34f7ad7f0b83359


If you want to test, you can try the coming proxmox 3.0 release here:
http://forum.proxmox.com/threads/13733-Proxmox-VE-3-0-RC1-released!?p=73897#post73897

support vm cloning full clone, from any storage (raw,qcow2,lvm,rbd,sheepdog,iscsi) to any storage.
Linked clones are also implemented for rbd :)

Hope It can help.

----- Mail original ----- 

De: "Leen Besselink" <leen@consolejunkie.net> 
À: ceph-devel@vger.kernel.org 
Envoyé: Mardi 14 Mai 2013 14:15:21 
Objet: Re: QCOW2 to RBD format 2 in one step 

On Tue, May 14, 2013 at 01:52:28PM +0200, Wido den Hollander wrote: 
> On 05/14/2013 12:34 PM, Leen Besselink wrote: 
> >On Tue, May 14, 2013 at 12:16:32PM +0200, Wido den Hollander wrote: 
> >>Hi, 
> >> 
> 
> Hi Leen, 
> 
> > 
> >Hi Wido, 
> > 
> >>While working on the CloudStack code for 4.2 I'm running into some 
> >>problems with QCOW2 and RBD format 2. 
> >> 
> >>A quick cap of the problem: 
> >> 
> >>CloudStack stores all the templates on "Secondary Storage" as QCOW2 files. 
> >> 
> >>When a VM is deployed, this image will be copied (once) from 
> >>Secondary Storage to Primary Storage, this is done by qemu-img which 
> >>does the conversion. 
> >> 
> >>When the image is on Primary Storage it will be copied to the 
> >>destination volume and the Instance/VM is started. 
> >> 
> >>In that last step I want to use layering, but the problem is that my 
> >>image is RBD format 1 due to the qemu-img copy. 
> >> 
> >>I can skip the qemu-img copy, but I have to find a way to go from 
> >>QCOW2 to RBD format 2 in preferably one step. There is a issue about 
> >>this in the tracker [0], but that won't be finished on time. 
> >> 
> >>Another idea would be to do QCOW2 -> RAW -> RBD format 2, but that 
> >>extra step will take a lot of time. It would also require some 
> >>temporary storage on the hypervisor. 
> >> 
> >>I also thought of creating the RBD image prior to converting to it, 
> >>but that fails, since qemu-img won't let you convert to a already 
> >>existing image. 
> >> 
> >>Any brights ideas? Maybe even doing the QCOW2 -> RAW format in 
> >>memory? In Java? 
> >> 
> > 
> >I'm no expert, but would it be possible to change qemu-img to support writing RAW to standard out ? 
> > 
> 
> No, qemu-img can't write to stdout. Due to various formats it supports. 
> 

I meant extending qemu-img to support that, it would probably be less 
work than the work needed for the issue below. But the longer I think 
about it. It would only be able to do that for RAW. And RAW isn't very 
efficient anyway. 

> >So you can run qemu-img convert and pipe that drectly to the rbd import command ? 
> > 
> 
> If qemu-img would support writing to stdout there is the problem 
> that I'm not using the rbd tool, but Java bindings for librbd and 
> librados. I'm trying to avoid executing from Java. 
> 
> >rbd import already supports standard in I believe. 
> > 
> >Then you don't need any temporary storage. 
> > 
> >Maybe something more efficient than RAW is possible as well ? 
> > 
> >>The goal is to go from QCOW2 to RBD format 2 in one step. 
> >> 
> >>[0]: http://tracker.ceph.com/issues/4897 
> >> 
> >>-- 
> >>Wido den Hollander 
> >>42on B.V. 
> >> 
> >>Phone: +31 (0)20 700 9902 
> >>Skype: contact42on 
> >>-- 
> >>To unsubscribe from this list: send the line "unsubscribe ceph-devel" in 
> >>the body of a message to majordomo@vger.kernel.org 
> >>More majordomo info at http://vger.kernel.org/majordomo-info.html 
> >-- 
> >To unsubscribe from this list: send the line "unsubscribe ceph-devel" in 
> >the body of a message to majordomo@vger.kernel.org 
> >More majordomo info at http://vger.kernel.org/majordomo-info.html 
> > 
> 
> 
> -- 
> Wido den Hollander 
> 42on B.V. 
> 
> Phone: +31 (0)20 700 9902 
> Skype: contact42on 
-- 
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in 
the body of a message to majordomo@vger.kernel.org 
More majordomo info at http://vger.kernel.org/majordomo-info.html 
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: QCOW2 to RBD format 2 in one step

[Josh Durgin]

On 05/14/2013 07:36 AM, Alexandre DERUMIER wrote:
> Hi,
>
> we do it with proxmox,
>
> we create the target rbd volume at format v2 with "rbd .." commands,
>
> then, we use qemu-img convert to copy from qcow2 to rbd.
>
> We have patched qemu-img to be able to write to an existing volume.
> (By default qemu-img convert try to create the volume)
> https://git.proxmox.com/?p=pve-qemu-kvm.git;a=commit;h=c0cf085da9b6b1d21791dd88c34f7ad7f0b83359

It'd be nice to get that option into upstream qemu.


> If you want to test, you can try the coming proxmox 3.0 release here:
> http://forum.proxmox.com/threads/13733-Proxmox-VE-3-0-RC1-released!?p=73897#post73897
>
> support vm cloning full clone, from any storage (raw,qcow2,lvm,rbd,sheepdog,iscsi) to any storage.
> Linked clones are also implemented for rbd :)

Good to know!

Josh

> Hope It can help.
>
> ----- Mail original -----
>
> De: "Leen Besselink" <leen@consolejunkie.net>
> À: ceph-devel@vger.kernel.org
> Envoyé: Mardi 14 Mai 2013 14:15:21
> Objet: Re: QCOW2 to RBD format 2 in one step
>
> On Tue, May 14, 2013 at 01:52:28PM +0200, Wido den Hollander wrote:
>> On 05/14/2013 12:34 PM, Leen Besselink wrote:
>>> On Tue, May 14, 2013 at 12:16:32PM +0200, Wido den Hollander wrote:
>>>> Hi,
>>>>
>>
>> Hi Leen,
>>
>>>
>>> Hi Wido,
>>>
>>>> While working on the CloudStack code for 4.2 I'm running into some
>>>> problems with QCOW2 and RBD format 2.
>>>>
>>>> A quick cap of the problem:
>>>>
>>>> CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.
>>>>
>>>> When a VM is deployed, this image will be copied (once) from
>>>> Secondary Storage to Primary Storage, this is done by qemu-img which
>>>> does the conversion.
>>>>
>>>> When the image is on Primary Storage it will be copied to the
>>>> destination volume and the Instance/VM is started.
>>>>
>>>> In that last step I want to use layering, but the problem is that my
>>>> image is RBD format 1 due to the qemu-img copy.
>>>>
>>>> I can skip the qemu-img copy, but I have to find a way to go from
>>>> QCOW2 to RBD format 2 in preferably one step. There is a issue about
>>>> this in the tracker [0], but that won't be finished on time.
>>>>
>>>> Another idea would be to do QCOW2 -> RAW -> RBD format 2, but that
>>>> extra step will take a lot of time. It would also require some
>>>> temporary storage on the hypervisor.
>>>>
>>>> I also thought of creating the RBD image prior to converting to it,
>>>> but that fails, since qemu-img won't let you convert to a already
>>>> existing image.
>>>>
>>>> Any brights ideas? Maybe even doing the QCOW2 -> RAW format in
>>>> memory? In Java?
>>>>
>>>
>>> I'm no expert, but would it be possible to change qemu-img to support writing RAW to standard out ?
>>>
>>
>> No, qemu-img can't write to stdout. Due to various formats it supports.
>>
>
> I meant extending qemu-img to support that, it would probably be less
> work than the work needed for the issue below. But the longer I think
> about it. It would only be able to do that for RAW. And RAW isn't very
> efficient anyway.
>
>>> So you can run qemu-img convert and pipe that drectly to the rbd import command ?
>>>
>>
>> If qemu-img would support writing to stdout there is the problem
>> that I'm not using the rbd tool, but Java bindings for librbd and
>> librados. I'm trying to avoid executing from Java.
>>
>>> rbd import already supports standard in I believe.
>>>
>>> Then you don't need any temporary storage.
>>>
>>> Maybe something more efficient than RAW is possible as well ?
>>>
>>>> The goal is to go from QCOW2 to RBD format 2 in one step.
>>>>
>>>> [0]: http://tracker.ceph.com/issues/4897
>>>>
>>>> --
>>>> Wido den Hollander
>>>> 42on B.V.
>>>>
>>>> Phone: +31 (0)20 700 9902
>>>> Skype: contact42on
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>> --
>> Wido den Hollander
>> 42on B.V.
>>
>> Phone: +31 (0)20 700 9902
>> Skype: contact42on

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: QCOW2 to RBD format 2 in one step

[Josh Durgin]

On 05/14/2013 03:16 AM, Wido den Hollander wrote:
> Hi,
>
> While working on the CloudStack code for 4.2 I'm running into some
> problems with QCOW2 and RBD format 2.
>
> A quick cap of the problem:
>
> CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.
>
> When a VM is deployed, this image will be copied (once) from Secondary
> Storage to Primary Storage, this is done by qemu-img which does the
> conversion.
>
> When the image is on Primary Storage it will be copied to the
> destination volume and the Instance/VM is started.
>
> In that last step I want to use layering, but the problem is that my
> image is RBD format 1 due to the qemu-img copy.
>
> I can skip the qemu-img copy, but I have to find a way to go from QCOW2
> to RBD format 2 in preferably one step. There is a issue about this in
> the tracker [0], but that won't be finished on time.
>
> Another idea would be to do QCOW2 -> RAW -> RBD format 2, but that extra
> step will take a lot of time. It would also require some temporary
> storage on the hypervisor.
>
> I also thought of creating the RBD image prior to converting to it, but
> that fails, since qemu-img won't let you convert to a already existing
> image.
>
> Any brights ideas? Maybe even doing the QCOW2 -> RAW format in memory?
> In Java?

One way that wouldn't require a change in qemu would be adding ceph
configuration options to change the behavior of librbd's rbd_create[2|3]().

For example, there could be just:

rbd_create_default_format UINT default 1

or we could add other options to adjust the rest of the image creation
parameters i.e.:

rbd_create_default_object_order INT default 22

// these only apply to format 2
rbd_create_default_features     UINT64 default 1 # 1 for layering, 3 for 
layering+stripingv2
rbd_create_default_stripe_count UINT64 default 1 # changing requires 
stripingv2 feature
rbd_create_default_stripe_unit  UINT64 default 4194304 # changing to 
non-object size requires stripingv2 feature

For backwards compatibility, the default values preserve the existing
behavior of rbd_create(), but when you run qemu-img you could change
them to create format 2 images and potentially change the striping
as well. These options could be easily backported to cuttlefish
and bobtail.

What do you think?

> The goal is to go from QCOW2 to RBD format 2 in one step.
>
> [0]: http://tracker.ceph.com/issues/4897
>

Re: QCOW2 to RBD format 2 in one step

[Wido den Hollander]

Op 14 mei 2013 om 21:59 heeft "Josh Durgin" <josh.durgin@inktank.com> het volgende geschreven:

> On 05/14/2013 03:16 AM, Wido den Hollander wrote:
>> Hi,
>> 
>> While working on the CloudStack code for 4.2 I'm running into some
>> problems with QCOW2 and RBD format 2.
>> 
>> A quick cap of the problem:
>> 
>> CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.
>> 
>> When a VM is deployed, this image will be copied (once) from Secondary
>> Storage to Primary Storage, this is done by qemu-img which does the
>> conversion.
>> 
>> When the image is on Primary Storage it will be copied to the
>> destination volume and the Instance/VM is started.
>> 
>> In that last step I want to use layering, but the problem is that my
>> image is RBD format 1 due to the qemu-img copy.
>> 
>> I can skip the qemu-img copy, but I have to find a way to go from QCOW2
>> to RBD format 2 in preferably one step. There is a issue about this in
>> the tracker [0], but that won't be finished on time.
>> 
>> Another idea would be to do QCOW2 -> RAW -> RBD format 2, but that extra
>> step will take a lot of time. It would also require some temporary
>> storage on the hypervisor.
>> 
>> I also thought of creating the RBD image prior to converting to it, but
>> that fails, since qemu-img won't let you convert to a already existing
>> image.
>> 
>> Any brights ideas? Maybe even doing the QCOW2 -> RAW format in memory?
>> In Java?
> 
> One way that wouldn't require a change in qemu would be adding ceph
> configuration options to change the behavior of librbd's rbd_create[2|3]().
> 
> For example, there could be just:
> 
> rbd_create_default_format UINT default 1
> 
> or we could add other options to adjust the rest of the image creation
> parameters i.e.:
> 
> rbd_create_default_object_order INT default 22
> 
> // these only apply to format 2
> rbd_create_default_features     UINT64 default 1 # 1 for layering, 3 for layering+stripingv2
> rbd_create_default_stripe_count UINT64 default 1 # changing requires stripingv2 feature
> rbd_create_default_stripe_unit  UINT64 default 4194304 # changing to non-object size requires stripingv2 feature
> 
> For backwards compatibility, the default values preserve the existing
> behavior of rbd_create(), but when you run qemu-img you could change
> them to create format 2 images and potentially change the striping
> as well. These options could be easily backported to cuttlefish
> and bobtail.
> 
> What do you think?

Something like that crossed my mind for a moment and seems like a very good solution!

On existing Ubuntu systems you could simply upgrade librbd and have it all working.

Wido

> 
>> The goal is to go from QCOW2 to RBD format 2 in one step.
>> 
>> [0]: http://tracker.ceph.com/issues/4897
>