>>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" <aderum...@odiso.com>
À: "Stefan Priebe - Profihost AG" <s.pri...@profihost.ag>
Cc: pve-devel@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.pri...@profihost.ag>
À: "Alexandre DERUMIER" <aderum...@odiso.com>
Cc: "Dietmar Maurer" <diet...@proxmox.com>, pve-devel@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.pri...@profihost.ag>
> À: "Alexandre DERUMIER" <aderum...@odiso.com>
> Cc: "Dietmar Maurer" <diet...@proxmox.com>, pve-devel@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" <diet...@proxmox.com>
>> À: "Alexandre DERUMIER" <aderum...@odiso.com>
>> Cc: pve-devel@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@pve.proxmox.com
>> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
