[Top][All Lists]

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

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

From: Eric Blake
Subject: Re: [Qemu-devel] Request for clarification on qemu-img convert behavior zeroing target host_device
Date: Thu, 13 Dec 2018 08:17:44 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 12/13/18 7:12 AM, De Backer, Fred (Nokia - BE/Antwerp) wrote:

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.

Known issue; Nir and Rich have posted a previous thread on the topic, and the conclusion is that we need to make qemu-img smarter about NOT requesting pre-zeroing of devices where that is more expensive than just zeroing as we go.

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 

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

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?

It's a performance bug. qemu-img convert has to ensure that the destination reads 0 (rather than is uninitialized), but the way in which it does so needs to be more careful about destinations that do not have efficient block status or bulk zeroing capabilities.

* 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?

Using -S 0 avoids sparseness, which may introduce its own set of problems if you were expecting the destination to be sparse.

* If the behavior is expected: is there some pointer to 
documentation/changelogs I can read about this?

Reading the mentioned thread will give some more insight, and hopefully qemu 4.0 will either improve the behavior by default or at least add knobs so that you can tweak the behavior based on your needs.

This message (including any attachments) contains confidential information

Such disclaimers are unenforceable on publicly-archived lists. Still, you may want to consider using a different email address that doesn't spam list readers with your employer's legalese gobbledygook.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

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