[pve-devel] copy_vm: new option -target

Alexandre DERUMIER aderumier at odiso.com
Thu May 2 13:47:40 CEST 2013


I'll test this:


>From 1b3f5a7812b0dd750e5010441708fee1a6117318 Mon Sep 17 00:00:00 2001
From: Alexandre Derumier <aderumier at odiso.com>
Date: Thu, 2 May 2013 13:43:45 +0200
Subject: [PATCH] rbd : add .bdrv_has_zero_init


Signed-off-by: Alexandre Derumier <aderumier at odiso.com>
---
 block/rbd.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/block/rbd.c b/block/rbd.c
index 8cd10a7..d545ebc 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -287,6 +287,11 @@ static int qemu_rbd_set_conf(rados_t cluster, const char *conf)
     return ret;
 }
 
+static int qemu_rbd_has_zero_init(BlockDriverState *bs)
+{
+    return 1;
+}
+
 static int qemu_rbd_create(const char *filename, QEMUOptionParameter *options)
 {
     int64_t bytes = 0;
@@ -958,6 +963,8 @@ static BlockDriver bdrv_rbd = {
     .bdrv_snapshot_delete   = qemu_rbd_snap_remove,
     .bdrv_snapshot_list     = qemu_rbd_snap_list,
     .bdrv_snapshot_goto     = qemu_rbd_snap_rollback,
+    .bdrv_has_zero_init     = qemu_rbd_has_zero_init,
+
 };
 
 static void bdrv_rbd_init(void)
-- 
1.7.10.4

----- 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 13:36:10 
Objet: Re: [pve-devel] copy_vm: new option -target 

maybe this is because in block/rbd.c, we don't have 

static int raw_has_zero_init(BlockDriverState *bs) 
{ 
return bdrv_has_zero_init(bs->file); 
} 

like block/raw.c 

? 



----- 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 13:27:48 
Objet: Re: [pve-devel] copy_vm: new option -target 

>>Oh OK so that's because we create the DISK before we start qemu-img? 
Yes! 

>>But we still loose sparseness? 
I have done test, I think it depend the source. 

qcow2 -> rbd, sparseness 

rbd -> rbd, full. 


Maybe "rbd export" only export allocated block, so make it sparse. 



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

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

Oh OK so that's because we create the DISK before we start qemu-img? But 
we still loose sparseness? 

Stefan 
Am 02.05.2013 13:20, schrieb Alexandre DERUMIER: 
> I have just done a test, and format is correct after qemu-img convert : V2 
> 
> test is from a qcow2 to rbd 
> 
> root at kvmtest1:~/proxmox2/qemu-kvm# qm copy 115 301 --storage rbdtest --full 
> copy drive virtio0 (local:115/vm-115-disk-1.qcow2) 
> transferred: 0 bytes remaining: 16106127360 bytes total: 16106127360 bytes progression: 0.00 % 
> transferred: 323733159 bytes remaining: 15782394201 bytes total: 16106127360 bytes progression: 2.01 % 
> transferred: 645855707 bytes remaining: 15460271653 bytes total: 16106127360 bytes progression: 4.01 % 
> transferred: 969588867 bytes remaining: 15136538493 bytes total: 16106127360 bytes progression: 6.02 % 
> transferred: 1291711414 bytes remaining: 14814415946 bytes total: 16106127360 bytes progression: 8.02 % 
> transferred: 1615444574 bytes remaining: 14490682786 bytes total: 16106127360 bytes progression: 10.03 % 
> transferred: 1937567121 bytes remaining: 14168560239 bytes total: 16106127360 bytes progression: 12.03 % 
> transferred: 2261300281 bytes remaining: 13844827079 bytes total: 16106127360 bytes progression: 14.04 % 
> transferred: 2583422828 bytes remaining: 13522704532 bytes total: 16106127360 bytes progression: 16.04 % 
> transferred: 2907155988 bytes remaining: 13198971372 bytes total: 16106127360 bytes progression: 18.05 % 
> transferred: 3229278535 bytes remaining: 12876848825 bytes total: 16106127360 bytes progression: 20.05 % 
> transferred: 3553011695 bytes remaining: 12553115665 bytes total: 16106127360 bytes progression: 22.06 % 
> transferred: 3875134242 bytes remaining: 12230993118 bytes total: 16106127360 bytes progression: 24.06 % 
> transferred: 4198867402 bytes remaining: 11907259958 bytes total: 16106127360 bytes progression: 26.07 % 
> transferred: 4520989949 bytes remaining: 11585137411 bytes total: 16106127360 bytes progression: 28.07 % 
> transferred: 4844723109 bytes remaining: 11261404251 bytes total: 16106127360 bytes progression: 30.08 % 
> transferred: 5166845657 bytes remaining: 10939281703 bytes total: 16106127360 bytes progression: 32.08 % 
> transferred: 5490578817 bytes remaining: 10615548543 bytes total: 16106127360 bytes progression: 34.09 % 
> transferred: 5812701364 bytes remaining: 10293425996 bytes total: 16106127360 bytes progression: 36.09 % 
> transferred: 6136434524 bytes remaining: 9969692836 bytes total: 16106127360 bytes progression: 38.10 % 
> transferred: 6458557071 bytes remaining: 9647570289 bytes total: 16106127360 bytes progression: 40.10 % 
> transferred: 6782290231 bytes remaining: 9323837129 bytes total: 16106127360 bytes progression: 42.11 % 
> transferred: 7104412778 bytes remaining: 9001714582 bytes total: 16106127360 bytes progression: 44.11 % 
> transferred: 7428145938 bytes remaining: 8677981422 bytes total: 16106127360 bytes progression: 46.12 % 
> transferred: 7750268485 bytes remaining: 8355858875 bytes total: 16106127360 bytes progression: 48.12 % 
> transferred: 8074001645 bytes remaining: 8032125715 bytes total: 16106127360 bytes progression: 50.13 % 
> transferred: 8396124192 bytes remaining: 7710003168 bytes total: 16106127360 bytes progression: 52.13 % 
> transferred: 8719857352 bytes remaining: 7386270008 bytes total: 16106127360 bytes progression: 54.14 % 
> transferred: 9041979899 bytes remaining: 7064147461 bytes total: 16106127360 bytes progression: 56.14 % 
> transferred: 9365713059 bytes remaining: 6740414301 bytes total: 16106127360 bytes progression: 58.15 % 
> transferred: 9687835607 bytes remaining: 6418291753 bytes total: 16106127360 bytes progression: 60.15 % 
> transferred: 10011568766 bytes remaining: 6094558594 bytes total: 16106127360 bytes progression: 62.16 % 
> transferred: 10333691314 bytes remaining: 5772436046 bytes total: 16106127360 bytes progression: 64.16 % 
> transferred: 10657424474 bytes remaining: 5448702886 bytes total: 16106127360 bytes progression: 66.17 % 
> transferred: 10981157634 bytes remaining: 5124969726 bytes total: 16106127360 bytes progression: 68.18 % 
> transferred: 11303280181 bytes remaining: 4802847179 bytes total: 16106127360 bytes progression: 70.18 % 
> transferred: 11627013341 bytes remaining: 4479114019 bytes total: 16106127360 bytes progression: 72.19 % 
> transferred: 11949135888 bytes remaining: 4156991472 bytes total: 16106127360 bytes progression: 74.19 % 
> transferred: 12272869048 bytes remaining: 3833258312 bytes total: 16106127360 bytes progression: 76.20 % 
> transferred: 12594991595 bytes remaining: 3511135765 bytes total: 16106127360 bytes progression: 78.20 % 
> transferred: 12918724755 bytes remaining: 3187402605 bytes total: 16106127360 bytes progression: 80.21 % 
> transferred: 13240847302 bytes remaining: 2865280058 bytes total: 16106127360 bytes progression: 82.21 % 
> transferred: 13564580462 bytes remaining: 2541546898 bytes total: 16106127360 bytes progression: 84.22 % 
> transferred: 13888313622 bytes remaining: 2217813738 bytes total: 16106127360 bytes progression: 86.23 % 
> transferred: 14210436169 bytes remaining: 1895691191 bytes total: 16106127360 bytes progression: 88.23 % 
> transferred: 14534169329 bytes remaining: 1571958031 bytes total: 16106127360 bytes progression: 90.24 % 
> transferred: 14856291876 bytes remaining: 1249835484 bytes total: 16106127360 bytes progression: 92.24 % 
> transferred: 15180025036 bytes remaining: 926102324 bytes total: 16106127360 bytes progression: 94.25 % 
> transferred: 15502147584 bytes remaining: 603979776 bytes total: 16106127360 bytes progression: 96.25 % 
> transferred: 15825880743 bytes remaining: 280246617 bytes total: 16106127360 bytes progression: 98.26 % 
> transferred: 16106127360 bytes remaining: 0 bytes total: 16106127360 bytes progression: 100.00 % 
> 
> # rbd info vm-301-disk-1 
> rbd image 'vm-301-disk-1': 
> size 15360 MB in 3840 objects 
> order 22 (4096 KB objects) 
> block_name_prefix: rbd_data.3c190a6b8b4567 
> format: 2 
> features: layering, striping 
> stripe unit: 4096 KB 
> stripe count: 1 
> 
> 
> 
> ----- Mail original ----- 
> 
> De: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag> 
> À: "Alexandre DERUMIER" <aderumier at odiso.com> 
> Cc: pve-devel at pve.proxmox.com 
> Envoyé: Jeudi 2 Mai 2013 13:16:08 
> Objet: Re: [pve-devel] copy_vm: new option -target 
> 
> Am 02.05.2013 13:05, schrieb 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; 
>> } 
> 
> Yes but with rbd export everything is allocated to 0. 
> 
> Stefan 
> 
_______________________________________________ 
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 



More information about the pve-devel mailing list