qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Request for clarification on qemu-img convert behavior zero


From: De Backer, Fred (Nokia - BE/Antwerp)
Subject: [Qemu-devel] Request for clarification on qemu-img convert behavior zeroing target host_device
Date: Thu, 13 Dec 2018 13:12:12 +0000

Hi,

We're using Openstack Ironic to deploy baremetal servers. During the deployment 
process an agent (ironic-python-agent) running on Fedora linux uses qemu-img to 
write a qcow2 file to a blockdevice.

Recently we saw a change in behavior of qemu-img. Previously we were using 
Fedora 27 containing a fedora packaged version of qemu-img v2.10.2 
(qemu-img-2.10.2-1.fc27.x86_64.rpm); now we use Fedora 29 containing a fedora 
packaged version of qemu-img v3.0.0 (qemu-img-3.0.0-2.fc29.x86_64.rpm).

The command that is run by the ironic-python-agent (the same in both FC27 and 
FC29) is: qemu-img -t directsync -O host_device /tmp/image.qcow2 /dev/sda

We observe that in Fedora 29 the qemu-img, before imaging the disk, it fully 
zeroes it. Taking into account the disk size, the whole process now takes 35 
minutes instead of 50 seconds. This causes the ironic-python-agent operation to 
time-out. The Fedora 27 qemu-img doesn't do that.

Scanning through the qemu-img source code, we found that adding -S 0 to the 
command on Fedora 29 qemu-img restores the behavior as observed in Fedora 27 
qemu-img.

Looking through the changelogs of qemu I couldn't find this behavior change 
documented.

Now the questions:
* Is this the expected/required behavior that qemu-img first zeroes the 
complete target disk before writing the image. In other words: is this a 
qemu-img bug?
* Is applying the -S 0 parameter a safe/sound/sensible thing to do to revert to 
the old behavior. In other words: can I write a bug against the 
ironic-python-agent to start using this parameter?
* If the behavior is expected: is there some pointer to 
documentation/changelogs I can read about this?

Thanks,
Regards,

Fred De Backer
SME Video Integration Engineer,
IP/Optical Networks, Nokia
address@hidden

Nokia Bell NV I Copernicuslaan 50, 2018 Antwerpen I BTW BE 0404 621 642 RPR 
Antwerpen I BNP Paribas Fortis 220-0002334-42 I IBAN BE 77 2200 0023 3442 I BIC 
GEBABEBB

<<
This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law. If you 
are not the intended recipient, you should delete this message. Any disclosure, 
copying, or distribution of this message, or the taking of any action based on 
it, is strictly prohibited without the prior consent of its author.
>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]