[pve-devel] copy_vm: new option -target

[Alexandre DERUMIER]

>>I also read that we'll loose sparseness with qemu-img as it does raw 

>>export and import. 

I'm not sure about it, qemu-img code is


           if (has_zero_init) {
                /* If the output image is being created as a copy on write image,
                   assume that sectors which are unallocated in the input image
                   are present in both the output's and input's base images (no
                   need to copy them). */
                if (out_baseimg) {
                    if (!bdrv_is_allocated(bs[bs_i], sector_num - bs_offset,
                                           n, &n1)) {
                        sector_num += n1;
                        continue;
                    }
                    /* The next 'n1' sectors are allocated in the input image. Copy
                       only those as they may be followed by unallocated sectors. */
                    n = n1;
                }
            } else {
                n1 = n;
            }



	

Alexandre D e rumier 

Ingénieur Systèmes et Réseaux 


Fixe : 03 20 68 88 85 

Fax : 03 20 68 90 88 


45 Bvd du Général Leclerc 59100 Roubaix 
12 rue Marivaux 75002 Paris 


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

De: "Alexandre DERUMIER" <aderumier at odiso.com> 
À: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag> 
Cc: pve-devel at pve.proxmox.com 
Envoyé: Jeudi 2 Mai 2013 12:57:12 
Objet: Re: [pve-devel] copy_vm: new option -target 

>>The problem is qemu-img here it only supports v1. No one has ported 
>>rbd_create2 or rbd_create3 to qemu-img. 

But rbd_create is for creating the volume right ? 

So it should work I think, As we create the volume before launching qemu-img convert. 
(Note that we have add a patch to qemu-img convert to not create the volume, -C option ) 

Also, I don't understand why using rbd ouput format segfault ? 
official doc say that it should be used : http://ceph.com/docs/master/rbd/qemu-rbd/ 


>>The best way would be to use rbd cp in this case which does all the things. 

But rbd cp is only from rbd to rbd ? 

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

De: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag> 
À: "Alexandre DERUMIER" <aderumier at odiso.com> 
Cc: "Dietmar Maurer" <dietmar at proxmox.com>, pve-devel at pve.proxmox.com 
Envoyé: Jeudi 2 Mai 2013 12:39:32 
Objet: Re: [pve-devel] copy_vm: new option -target 

Hi, 

Am 02.05.2013 12:30, schrieb Alexandre DERUMIER: 
> mmm, good point. 
> 
> We create the volume with format=2, 
> then after qemu-img convert copy from source to target. 
> 
> but maybe qemu-img convert override the format ? seem strange ... 
> 
> Maybe ceph devel list can help ? 
> 
> I'll re-read the qemu-img doc. 

The problem is qemu-img here it only supports v1. No one has ported 
rbd_create2 or rbd_create3 to qemu-img. 

https://github.com/ceph/ceph/blob/master/src/include/rbd/librbd.h#L72 

but rbd in qemu: 
http://git.qemu.org/?p=qemu.git;a=blob;f=block/rbd.c#l364 

I also read that we'll loose sparseness with qemu-img as it does raw 
export and import. 

The best way would be to use rbd cp in this case which does all the things. 

Stefan 

> 
> ----- Mail original ----- 
> 
> De: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag> 
> À: "Alexandre DERUMIER" <aderumier at odiso.com> 
> Cc: "Dietmar Maurer" <dietmar at proxmox.com>, pve-devel at pve.proxmox.com 
> Envoyé: Jeudi 2 Mai 2013 12:15:08 
> Objet: Re: [pve-devel] copy_vm: new option -target 
> 
> Hi Alexandre, 
> 
> have you checked which rbd format qemu-img creates? I mean we have rbd 
> format 1 and format 2. 
> 
> In my tests qemu-img always create the slower and older format v1. But 
> normally if we clone a VM we should have the same settings of source and 
> target disk. 
> 
> Greets, 
> Stefan 
> 
> Am 02.05.2013 11:17, schrieb Alexandre DERUMIER: 
>>>> Ah, OK. I thought we already check that for migrate? 
>> Yes, indeed 
>> 
>> # check if storage is available on both nodes 
>> my $scfg = PVE::Storage::storage_check_node($self->{storecfg}, $sid); 
>> PVE::Storage::storage_check_node($self->{storecfg}, $sid, $self->{node}); 
>> 
>> But not in pve-manager. (I think we display all nodes). 
>> 
>> 
>> But for vm_copy maybe we can readd this check 
>> 
>> 
>> 
>> ----- Mail original ----- 
>> 
>> De: "Dietmar Maurer" <dietmar at proxmox.com> 
>> À: "Alexandre DERUMIER" <aderumier at odiso.com> 
>> Cc: pve-devel at pve.proxmox.com 
>> Envoyé: Jeudi 2 Mai 2013 09:03:46 
>> Objet: RE: copy_vm: new option -target 
>> 
>>>>> I thought we assume a shared storage is always available (unless disabled)? 
>>> It's possible that a shared can be assigned to specific nodes only. (nodes xxxx in 
>>> storage.cfg). 
>>> I have some shared storage in production not shared on all servers in same 
>>> cluster. (because of differents networks) 
>> 
>> Ah, OK. I thought we already check that for migrate? 
>> _______________________________________________ 
>> pve-devel mailing list 
>> pve-devel at pve.proxmox.com 
>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
>> 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel