Patchwork [4/6] qemu-img: add-cow will not support convert

login
register
mail settings
Submitter Robert Wang
Date June 13, 2012, 2:36 p.m.
Message ID <1339598189-17933-4-git-send-email-wdongxu@linux.vnet.ibm.com>
Download mbox | patch
Permalink /patch/164700/
State New
Headers show

Comments

Robert Wang - June 13, 2012, 2:36 p.m.
add-cow file can't live alone, must together will image_file and backing_file.
If we implement qemu-img convert operation for add-cow file format, we must
create image_file and backing_file manually, that will be confused for users,
so we just ignore add-cow format while doing converting.

Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
---
 qemu-img.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
Kevin Wolf - June 14, 2012, 10:51 a.m.
Am 13.06.2012 16:36, schrieb Dong Xu Wang:
> add-cow file can't live alone, must together will image_file and backing_file.
> If we implement qemu-img convert operation for add-cow file format, we must
> create image_file and backing_file manually, that will be confused for users,
> so we just ignore add-cow format while doing converting.
> 
> Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>

NACK.

This stupid "let's drop the feature, it might confuse users" attitude is
known from Gnome, but not from qemu.

There's no technical reason to forbid it and anyone who manages to
create a valid add-cow image will also be able to specify the very same
options to a convert command. Also, having image format specific code in
qemu-img is evil.

Kevin
Robert Wang - June 14, 2012, 2:06 p.m.
On Thu, Jun 14, 2012 at 6:51 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 13.06.2012 16:36, schrieb Dong Xu Wang:
>> add-cow file can't live alone, must together will image_file and backing_file.
>> If we implement qemu-img convert operation for add-cow file format, we must
>> create image_file and backing_file manually, that will be confused for users,
>> so we just ignore add-cow format while doing converting.
>>
>> Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
>
> NACK.
>
> This stupid "let's drop the feature, it might confuse users" attitude is
> known from Gnome, but not from qemu.
>
> There's no technical reason to forbid it and anyone who manages to
> create a valid add-cow image will also be able to specify the very same
> options to a convert command. Also, having image format specific code in
> qemu-img is evil.
>

If I implement add-cow convert command, I am wondering which method should
I use:
1) create add-cow, and its backing_file, and its image_file,  then we
need 3 files.
2) create add-cow(with all bitmap marked to allocated), and its
image_file, then we
    need 2 files.

2) will be easier, I should let .add-cow file can live only with
image_file, without backing_file.

I think both 1) and 2) need add code to qemu-img.c. Or I will have to create
image_file automaticly in add_cow_create function.

Can you give some comments on how to implement convert? Thanks.

> Kevin
>
Kevin Wolf - June 14, 2012, 2:11 p.m.
Am 14.06.2012 16:06, schrieb Dong Xu Wang:
> On Thu, Jun 14, 2012 at 6:51 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 13.06.2012 16:36, schrieb Dong Xu Wang:
>>> add-cow file can't live alone, must together will image_file and backing_file.
>>> If we implement qemu-img convert operation for add-cow file format, we must
>>> create image_file and backing_file manually, that will be confused for users,
>>> so we just ignore add-cow format while doing converting.
>>>
>>> Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
>>
>> NACK.
>>
>> This stupid "let's drop the feature, it might confuse users" attitude is
>> known from Gnome, but not from qemu.
>>
>> There's no technical reason to forbid it and anyone who manages to
>> create a valid add-cow image will also be able to specify the very same
>> options to a convert command. Also, having image format specific code in
>> qemu-img is evil.
>>
> 
> If I implement add-cow convert command, I am wondering which method should
> I use:
> 1) create add-cow, and its backing_file, and its image_file,  then we
> need 3 files.
> 2) create add-cow(with all bitmap marked to allocated), and its
> image_file, then we
>     need 2 files.
> 
> 2) will be easier, I should let .add-cow file can live only with
> image_file, without backing_file.
> 
> I think both 1) and 2) need add code to qemu-img.c. Or I will have to create
> image_file automaticly in add_cow_create function.
> 
> Can you give some comments on how to implement convert? Thanks.

Just leave it alone and it will work.

qemu-img convert takes the same options as qemu-img create. So like for
any other image you specify the backing file with -b or -o backing_file,
and for add-cow images to be successfully created you also need to
specify -o image_file.

Kevin
Robert Wang - June 14, 2012, 2:17 p.m.
On Thu, Jun 14, 2012 at 10:11 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 14.06.2012 16:06, schrieb Dong Xu Wang:
>> On Thu, Jun 14, 2012 at 6:51 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>>> Am 13.06.2012 16:36, schrieb Dong Xu Wang:
>>>> add-cow file can't live alone, must together will image_file and backing_file.
>>>> If we implement qemu-img convert operation for add-cow file format, we must
>>>> create image_file and backing_file manually, that will be confused for users,
>>>> so we just ignore add-cow format while doing converting.
>>>>
>>>> Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
>>>
>>> NACK.
>>>
>>> This stupid "let's drop the feature, it might confuse users" attitude is
>>> known from Gnome, but not from qemu.
>>>
>>> There's no technical reason to forbid it and anyone who manages to
>>> create a valid add-cow image will also be able to specify the very same
>>> options to a convert command. Also, having image format specific code in
>>> qemu-img is evil.
>>>
>>
>> If I implement add-cow convert command, I am wondering which method should
>> I use:
>> 1) create add-cow, and its backing_file, and its image_file,  then we
>> need 3 files.
>> 2) create add-cow(with all bitmap marked to allocated), and its
>> image_file, then we
>>     need 2 files.
>>
>> 2) will be easier, I should let .add-cow file can live only with
>> image_file, without backing_file.
>>
>> I think both 1) and 2) need add code to qemu-img.c. Or I will have to create
>> image_file automaticly in add_cow_create function.
>>
>> Can you give some comments on how to implement convert? Thanks.
>
> Just leave it alone and it will work.
>
> qemu-img convert takes the same options as qemu-img create. So like for
> any other image you specify the backing file with -b or -o backing_file,
> and for add-cow images to be successfully created you also need to
> specify -o image_file.
>
"-o image_file", the image_file should be precreated? Or I should created it
manually?
> Kevin
>
Kevin Wolf - June 14, 2012, 2:24 p.m.
Am 14.06.2012 16:17, schrieb Dong Xu Wang:
> On Thu, Jun 14, 2012 at 10:11 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 14.06.2012 16:06, schrieb Dong Xu Wang:
>>> On Thu, Jun 14, 2012 at 6:51 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>>>> Am 13.06.2012 16:36, schrieb Dong Xu Wang:
>>>>> add-cow file can't live alone, must together will image_file and backing_file.
>>>>> If we implement qemu-img convert operation for add-cow file format, we must
>>>>> create image_file and backing_file manually, that will be confused for users,
>>>>> so we just ignore add-cow format while doing converting.
>>>>>
>>>>> Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
>>>>
>>>> NACK.
>>>>
>>>> This stupid "let's drop the feature, it might confuse users" attitude is
>>>> known from Gnome, but not from qemu.
>>>>
>>>> There's no technical reason to forbid it and anyone who manages to
>>>> create a valid add-cow image will also be able to specify the very same
>>>> options to a convert command. Also, having image format specific code in
>>>> qemu-img is evil.
>>>>
>>>
>>> If I implement add-cow convert command, I am wondering which method should
>>> I use:
>>> 1) create add-cow, and its backing_file, and its image_file,  then we
>>> need 3 files.
>>> 2) create add-cow(with all bitmap marked to allocated), and its
>>> image_file, then we
>>>     need 2 files.
>>>
>>> 2) will be easier, I should let .add-cow file can live only with
>>> image_file, without backing_file.
>>>
>>> I think both 1) and 2) need add code to qemu-img.c. Or I will have to create
>>> image_file automaticly in add_cow_create function.
>>>
>>> Can you give some comments on how to implement convert? Thanks.
>>
>> Just leave it alone and it will work.
>>
>> qemu-img convert takes the same options as qemu-img create. So like for
>> any other image you specify the backing file with -b or -o backing_file,
>> and for add-cow images to be successfully created you also need to
>> specify -o image_file.
>>
> "-o image_file", the image_file should be precreated? Or I should created it
> manually?

Yes, it must already exist. Just like with qemu-img create. To convert
an existing qcow2 image that has a backing file 'base.img' to an add-cow
image, you would use something like:

$ qemu-img create -f raw target.img 4G
$ qemu-img convert -O add-cow -o image_file=target.img -B base.img
source.qcow2 target.add-cow

Kevin
Robert Wang - June 14, 2012, 2:26 p.m.
On Thu, Jun 14, 2012 at 10:24 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 14.06.2012 16:17, schrieb Dong Xu Wang:
>> On Thu, Jun 14, 2012 at 10:11 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>>> Am 14.06.2012 16:06, schrieb Dong Xu Wang:
>>>> On Thu, Jun 14, 2012 at 6:51 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>>>>> Am 13.06.2012 16:36, schrieb Dong Xu Wang:
>>>>>> add-cow file can't live alone, must together will image_file and backing_file.
>>>>>> If we implement qemu-img convert operation for add-cow file format, we must
>>>>>> create image_file and backing_file manually, that will be confused for users,
>>>>>> so we just ignore add-cow format while doing converting.
>>>>>>
>>>>>> Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com>
>>>>>
>>>>> NACK.
>>>>>
>>>>> This stupid "let's drop the feature, it might confuse users" attitude is
>>>>> known from Gnome, but not from qemu.
>>>>>
>>>>> There's no technical reason to forbid it and anyone who manages to
>>>>> create a valid add-cow image will also be able to specify the very same
>>>>> options to a convert command. Also, having image format specific code in
>>>>> qemu-img is evil.
>>>>>
>>>>
>>>> If I implement add-cow convert command, I am wondering which method should
>>>> I use:
>>>> 1) create add-cow, and its backing_file, and its image_file,  then we
>>>> need 3 files.
>>>> 2) create add-cow(with all bitmap marked to allocated), and its
>>>> image_file, then we
>>>>     need 2 files.
>>>>
>>>> 2) will be easier, I should let .add-cow file can live only with
>>>> image_file, without backing_file.
>>>>
>>>> I think both 1) and 2) need add code to qemu-img.c. Or I will have to create
>>>> image_file automaticly in add_cow_create function.
>>>>
>>>> Can you give some comments on how to implement convert? Thanks.
>>>
>>> Just leave it alone and it will work.
>>>
>>> qemu-img convert takes the same options as qemu-img create. So like for
>>> any other image you specify the backing file with -b or -o backing_file,
>>> and for add-cow images to be successfully created you also need to
>>> specify -o image_file.
>>>
>> "-o image_file", the image_file should be precreated? Or I should created it
>> manually?
>
> Yes, it must already exist. Just like with qemu-img create. To convert
> an existing qcow2 image that has a backing file 'base.img' to an add-cow
> image, you would use something like:
>
> $ qemu-img create -f raw target.img 4G
> $ qemu-img convert -O add-cow -o image_file=target.img -B base.img
> source.qcow2 target.add-cow
>
> Kevin
>
Got it, thanks

Patch

diff --git a/qemu-img.c b/qemu-img.c
index c8a70ff..0bce61c 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -756,6 +756,12 @@  static int img_convert(int argc, char **argv)
         }
     }
 
+    if (strcmp(out_fmt, "add-cow") == 0) {
+        error_report("Convert operation does not support %s format.", out_fmt);
+        ret = -1;
+        goto out;
+    }
+
     /* Find driver and parse its options */
     drv = bdrv_find_format(out_fmt);
     if (!drv) {