qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* Migration with ``drive-mirror`` + NBD will let quorum qcow2 image become larger
@ 2020-05-19  8:32 Tao Xu
  2020-05-19  9:15 ` Kevin Wolf
  0 siblings, 1 reply; 4+ messages in thread
From: Tao Xu @ 2020-05-19  8:32 UTC (permalink / raw)
  To: Alberto Garcia, Zhang Chen, Kevin Wolf, Max Reitz, John Snow; +Cc: qemu-devel

Hi,

I am using ``drive-mirror`` + NBD for live storage migration. But I find 
that if I use a qcow2 image(virtual size: 10 GiB, disk size: 1.8 GiB) as 
a child of quorum, then the destination image become larger(virtual 
size: 10 GiB, disk size: 10 GiB). However if I use a qcow2 image 
directly, then the destination image(virtual size: 10 GiB, disk size: 
1.8 GiB) will be equal to the source.

So I am wondering if my usage is wrong or it is expected with 
quorum+drive-mirror?

P.S. Detail:

1) [On *destination* Host]: qemu-img create -f qcow2 fedora32.qcow2 10G
Formatting 'fedora32.qcow2', fmt=qcow2 size=10737418240 
cluster_size=65536 lazy_refcounts=off refcount_bits=16

qemu-img info fedora32.qcow2
image: fedora32.qcow2
file format: qcow2
virtual size: 10 GiB (10737418240 bytes)
disk size: 196 KiB
cluster_size: 65536
Format specific information:
     compat: 1.1
     lazy refcounts: false
     refcount bits: 16
     corrupt: false

Boot the QEMU using:

disk_path=fedora32.qcow2
net_param="-netdev 
tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper 
-device rtl8139,id=e0,netdev=hn0"
cmdline="qemu-system-x86_64 \
-enable-kvm \
-m 2G -smp 4 -qmp stdio -bios OVMF.fd \
-monitor telnet:127.0.0.1:4444,nowait,server -vnc :7 -rtc base=utc \
-cpu host -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device usb-tablet,id=input0,bus=usb.0,port=1 $net_param \
-drive if=none,id=parent0,file.filename=$disk_path,driver=qcow2 \
-incoming tcp:0:8888"
exec $cmdline

[On *destination* QEMU]:
{'execute':'qmp_capabilities'}
{'execute': 'nbd-server-start', 'arguments': {'addr': {'type': 'inet', 
'data': {'host': '192.168.0.33', 'port': '8889'} } } }
{'execute': 'nbd-server-add', 'arguments': {'device': 'parent0', 
'writable': true } }

2) [On *source* Host]:

Boot the QEMU using:

disk_path=fedora32.qcow2
net_param="-netdev 
tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper 
-device rtl8139,id=e0,netdev=hn0"
cmdline="qemu-system-x86_64 \
-enable-kvm \
-m 2G -smp 4 -qmp stdio -bios OVMF.fd \
-monitor telnet:127.0.0.1:4444,nowait,server -vnc :7 -rtc base=utc \
-cpu host -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device usb-tablet,id=input0,bus=usb.0,port=1 $net_param \
-drive 
if=virtio,id=colo-disk0,driver=quorum,vote-threshold=1,children.0.file.filename=$disk_path,children.0.driver=qcow2"
exec $cmdline

[On *source* QEMU]:

{'execute':'qmp_capabilities'}
{'execute': 'drive-mirror', 'arguments':{ 'device': 'colo-disk0', 
'job-id': 'resync', 'target': 'nbd://192.168.0.33:8889/parent0', 'mode': 
'existing', 'format': 'nbd', 'sync': 'full'} }

{"timestamp": {"seconds": 1589902560, "microseconds": 107418}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "created", "id": "resync"}}
{"timestamp": {"seconds": 1589902560, "microseconds": 107487}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "running", "id": "resync"}}
{"return": {}}
{"timestamp": {"seconds": 1589902721, "microseconds": 439095}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "ready", "id": "resync"}}
{"timestamp": {"seconds": 1589902721, "microseconds": 439194}, "event": 
"BLOCK_JOB_READY", "data": {"device": "resync", "len": 10739253248, 
"offset": 10739253248, "speed": 0, "type": "mirror"}}

3)[On *destination* Host]:
qemu-img info fedora32.qcow2
image: fedora32.qcow2
file format: qcow2
virtual size: 10 GiB (10737418240 bytes)
disk size: 10 GiB
cluster_size: 65536
Format specific information:
     compat: 1.1
     lazy refcounts: false
     refcount bits: 16
     corrupt: false
4)But if [On *source* Host] boot qemu using:

disk_path=fedora32.qcow2
net_param="-netdev 
tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper 
-device rtl8139,id=e0,netdev=hn0"
cmdline="qemu-system-x86_64 \
-enable-kvm \
-m 2G -smp 4 -qmp stdio -bios OVMF.fd \
-monitor telnet:127.0.0.1:4444,nowait,server -vnc :7 -rtc base=utc \
-cpu host -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device usb-tablet,id=input0,bus=usb.0,port=1 $net_param \
-drive if=virtio,id=parent0,file.filename=$disk_path,driver=qcow2"
exec $cmdline

Then [On *destination* Host]:

qemu-img info fedora32.qcow2
image: fedora32.qcow2
file format: qcow2
virtual size: 10 GiB (10737418240 bytes)
disk size: 1.8 GiB
cluster_size: 65536
Format specific information:
     compat: 1.1
     lazy refcounts: false
     refcount bits: 16
     corrupt: false


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Migration with ``drive-mirror`` + NBD will let quorum qcow2 image become larger
  2020-05-19  8:32 Migration with ``drive-mirror`` + NBD will let quorum qcow2 image become larger Tao Xu
@ 2020-05-19  9:15 ` Kevin Wolf
  2020-05-19 14:49   ` Alberto Garcia
  0 siblings, 1 reply; 4+ messages in thread
From: Kevin Wolf @ 2020-05-19  9:15 UTC (permalink / raw)
  To: Tao Xu; +Cc: John Snow, Zhang Chen, Alberto Garcia, qemu-devel, Max Reitz

Am 19.05.2020 um 10:32 hat Tao Xu geschrieben:
> Hi,
> 
> I am using ``drive-mirror`` + NBD for live storage migration. But I find
> that if I use a qcow2 image(virtual size: 10 GiB, disk size: 1.8 GiB) as a
> child of quorum, then the destination image become larger(virtual size: 10
> GiB, disk size: 10 GiB). However if I use a qcow2 image directly, then the
> destination image(virtual size: 10 GiB, disk size: 1.8 GiB) will be equal to
> the source.
> 
> So I am wondering if my usage is wrong or it is expected with
> quorum+drive-mirror?

This seems to be because the quorum block driver doesn't implement the
.bdrv_co_block_status interface, so the mirror block job can't know that
some blocks are unallocated/zeroed, but will copy everything.

I'm not sure if quorum can even implement this interface because the
allocation status in different quorum children may differ and voting
might not make sense. But maybe it could return a limited set of flags
at least so that the mirror job can get the BDRV_BLOCK_ZERO information
if the quorum children agree on it.

tl;dr: With quorum + drive-mirror it is currently expected.

Kevin



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Migration with ``drive-mirror`` + NBD will let quorum qcow2 image become larger
  2020-05-19  9:15 ` Kevin Wolf
@ 2020-05-19 14:49   ` Alberto Garcia
  2020-05-20  8:36     ` Tao Xu
  0 siblings, 1 reply; 4+ messages in thread
From: Alberto Garcia @ 2020-05-19 14:49 UTC (permalink / raw)
  To: Kevin Wolf, Tao Xu; +Cc: Zhang Chen, John Snow, qemu-devel, Max Reitz

On Tue 19 May 2020 11:15:44 AM CEST, Kevin Wolf wrote:
> But maybe it could return a limited set of flags at least so that the
> mirror job can get the BDRV_BLOCK_ZERO information if the quorum
> children agree on it.

Yeah, maybe it is possible to implement a conservative version of that
function and fall back to BDRV_BLOCK_DATA | BDRV_BLOCK_ALLOCATED (or
something like that) in the cases where there's no clear alternative.

Berto


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Migration with ``drive-mirror`` + NBD will let quorum qcow2 image become larger
  2020-05-19 14:49   ` Alberto Garcia
@ 2020-05-20  8:36     ` Tao Xu
  0 siblings, 0 replies; 4+ messages in thread
From: Tao Xu @ 2020-05-20  8:36 UTC (permalink / raw)
  To: Alberto Garcia, Kevin Wolf; +Cc: Zhang, Chen, John Snow, qemu-devel, Max Reitz

On 5/19/2020 10:49 PM, Alberto Garcia wrote:
> On Tue 19 May 2020 11:15:44 AM CEST, Kevin Wolf wrote:
>> But maybe it could return a limited set of flags at least so that the
>> mirror job can get the BDRV_BLOCK_ZERO information if the quorum
>> children agree on it.
> 
> Yeah, maybe it is possible to implement a conservative version of that
> function and fall back to BDRV_BLOCK_DATA | BDRV_BLOCK_ALLOCATED (or
> something like that) in the cases where there's no clear alternative.
> 
> Berto
> 

Thank you Kevin and Berto for your suggestion.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-05-20  8:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-19  8:32 Migration with ``drive-mirror`` + NBD will let quorum qcow2 image become larger Tao Xu
2020-05-19  9:15 ` Kevin Wolf
2020-05-19 14:49   ` Alberto Garcia
2020-05-20  8:36     ` Tao Xu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).