qemu-discuss
[Top][All Lists]
Advanced

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

Re: [Qemu-discuss] [kubevirt-dev] Re: Converting qcow2 image on the fly


From: Richard W.M. Jones
Subject: Re: [Qemu-discuss] [kubevirt-dev] Re: Converting qcow2 image on the fly to raw format
Date: Thu, 19 Jul 2018 21:39:35 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

I did the original work using AFL to fuzz qemu-img and find
problematic images.  From that work Dan & I suggested some fairly low
limits (10 seconds IIRC).  See:

https://bugs.launchpad.net/qemu/+bug/1462944
https://bugs.launchpad.net/qemu/+bug/1462949

A lot more problematic images were found (at least 16), but I cannot
recall if we filed bugs for all of them.  Note the images do not need
to be qcow2, since someone can upload any old thing to your service
and cause you problems.

On Thu, Jul 19, 2018 at 11:00:14PM +0300, Nir Soffer wrote:
> The 30 seconds cpu_time time limit confuses me; it was added in:
> https://github.com/openstack/nova/commit/011ae614d5c5fb35b2e9c22a9c4c99158f6aee20
>
> The patch references this bug:
> https://bugs.launchpad.net/nova/+bug/1705340

It looks as if those original limits were too low and they have been
increased.  For RHV I think you should go with the same settings that
OpenStack is using.

> The bug show that qemu-img info took more then 8 seconds real time:
> 
> /usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:355
> 2017-07-19 19:47:42.849 7 DEBUG oslo_concurrency.processutils
> [req-7ed3314d-1c11-4dd8-b612-f8d9c022417f
> ff236d57a57dd42cb5811c998e30fca1a76233873b9f08330f725fb639c8b025
> 9776d48734a24c23a4aef51cb78cc269 - - -] CMD "/usr/bin/python2 -m
> oslo_concurrency.prlimit --as=1073741824 --cpu=16 -- env LC_ALL=C
> LANG=C qemu-img info
> /var/lib/nova/instances/_base/41ebff725eab55d368f97bc79ddeea47df894145.part"
> returned: 0 in 8.639s execute
> 
> How the size of the snapshot can slow down reading the qcow2 header?

Since the original bugs were found using fuzzing I didn't spend much
time working out exactly why the code was slow in certain situations.

> Is this relevant for qemu-img-rhev 2.10?

Yes, for all versions of qemu-img.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top



reply via email to

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