[pve-devel] pve-storage : add $preparecopy argument to alloc_image

[Alexandre DERUMIER]

I'm going to do some tests with qemu-img bypass the file create next week.

Going to weekend ;)

I'll keep you in touch.


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

De: "Alexandre DERUMIER" <aderumier at odiso.com> 
À: "Dietmar Maurer" <dietmar at proxmox.com> 
Cc: pve-devel at pve.proxmox.com 
Envoyé: Vendredi 26 Octobre 2012 18:48:12 
Objet: Re: [pve-devel] pve-storage : add $preparecopy argument to alloc_image 

>>We don't you simply add a new option to 'qemu-img' to skip the 
>>call to bdrv_create? That is just a few line of code, and solves all 
>>your problems? 
the bdrv_create also check if the size of volume if big enough, and if it's available. 
qemu dev seem to want same behavior that for host_device block driver 


"Am 25.10.2012 15:41, schrieb ronnie sahlberg: 
> On Thu, Oct 25, 2012 at 1:02 AM, Kevin Wolf <kwolf at redhat.com> wrote: 
>> Am 25.10.2012 09:52, schrieb Paolo Bonzini: 
>>> Il 25/10/2012 09:46, Kevin Wolf ha scritto: 
>>>>>> 1)add a .bdrv_create in block/iscsi.c ? 
>>>>>> 
>>>>>> (like host_device block driver, only open/close the device and check if size if big enough) 
>>>> Yes, this is the right way. 
>>> 
>>> Could it be a default implementation of .bdrv_create (i.e. something 
>>> you'd do in bdrv_create if the protocol doesn't have it)? 
>> 
>> No, there are block drivers that really can't create images. They should 
>> keep failing. 
> 
> Technically, you can not create new LUNs via the iscsi protocol 
> itself, you can only access pre-existing luns 
> that have been created by some out-of-band method. 
> 
> So basically, with iscsi you can only ever access already preexisting luns. 
> 
> In that case I think requiring a .bdrv_create feels wrong. We are not 
> creating a new LUN here but just opening an already existing LUN. 

This is the very same as with host_device, which has always worked like 
this. Obviously it can't create new block devices, but it can check that 
the preexisting block device is suitable for the requested size and options. 

> What about changing bdrv_create() so that IF there is no .bdrv_create 
> method, then assume it might be a pre-existing file in which case we 
> fallback to use .bdrv_open instead. 

I don't think this is the correct behaviour for all block drivers. It's 
wrong for any driver that would actually require a specific content of 
the image file. For example let's overwrite an existing image: 

$ touch /tmp/test.dmg # Or this could be a real DMG image as well 
$ ./qemu-img create -f dmg /tmp/test.dmg 64M 
Formatting '/tmp/test.dmg', fmt=dmg size=67108864 
qemu-img: Formatting or formatting option not supported for file format 
'dmg' 

After your change it would appear to have succeeded, whereas of course 
it still wouldn't have created the image. 

Kevin" 




But,we can add a flag if you want. 
But I don't know if finally we need qemu-img, if we can use your new backup/restore framework.(I don't know how it's working) 



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

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: pve-devel at pve.proxmox.com 
Envoyé: Vendredi 26 Octobre 2012 18:03:09 
Objet: RE: [pve-devel] pve-storage : add $preparecopy argument to alloc_image 

> >>The suggestion was to modify qemu-img instead. 
> 
> About iscsi ? 
> 
> For the iscsi part, finally, after talking with paolo,kevin, and ronnie 
> 
> The workaround must be done in iscsi.c 

We don't you simply add a new option to 'qemu-img' to skip the 
call to bdrv_create? That is just a few line of code, and solves all 
your problems? 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel