qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [RFC] finegrained disk driver options control


From: Denis V. Lunev
Subject: Re: [Qemu-block] [RFC] finegrained disk driver options control
Date: Thu, 16 Mar 2017 18:00:46 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 03/16/2017 05:45 PM, Daniel P. Berrange wrote:
> On Thu, Mar 16, 2017 at 05:08:57PM +0300, Denis V. Lunev wrote:
>> Hello, All!
>>
>> There is a problem in the current libvirt implementation. domain.xml
>> allows to specify only basic set of options, especially in the case
>> of QEMU, when there are really a lot of tweaks in format drivers.
>> Most likely these options will never be supported in a good way
>> in libvirt as recognizable entities.
>>
>> Right now in order to debug libvirt QEMU VM in production I am using
>> very strange approach:
>> - disk section of domain XML is removed
>> - exact command line options to start the disk are specified at the end
>>   of domain.xml whithin <qemu:commandline> as described by Stefan
>>  
>> http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html
>>
>> The problem is that when debug is finished and viable combinations of
>> options is found I can not drop VM in such state in the production. This
>> is the pain and problem. For example, I have spend 3 days with the
>> VM of one customer which blames us for slow IO in the guest. I have
>> found very good combination of non-standard options which increases
>> disk performance 5 times (not 5%). Currently I can not put this combination
>> in the production as libvirt does not see the disk.
>>
>> I propose to do very simple thing, may be I am not the first one here,
>> but it would be nice to allow to pass arbitrary option to the QEMU
>> command line. This could be done in a very generic way if we will
>> allow to specify additional options inside <driver> section like this:
>>
>>     <disk type='file' device='disk'>
>>       <driver name='qemu' type='qcow2' cache='none' io='native'
>> iothread='1'>
>>           <option name='l2-cache-size' value='64M/>
>>           <option name='cache-clean-interval' value='32'/>
>>       </driver>
>>       <source file='/var/lib/libvirt/images/rhel7.qcow2'/>
>>       <target dev='sda' bus='scsi'/>
>>       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>>     </disk>
>>
>> and so on. The meaning (at least for QEMU) is quite simple -
>> these options will just be added to the end of the -drive command
>> line. The meaning for other drivers should be the same and I
>> think that there are ways to pass generic options in them.
> It is a general policy that we do *not* do generic option passthrough
> in this kind of manner. We always want to represent concepts explicitly
> with named attributes, so that if 2 hypervisors support the same concept
> we can map it the same way in the XML
>
> Regards,
> Daniel
OK. How could I change L2 cache size for QCOW2 image?

For 1 Tb disk, fragmented in guest, the performance loss is
around 10 times. 10 TIMES. 1000%. The customer could not
wait until proper fix in the next QEMU release especially
if we are able to provide the kludge specifically for him.

There is an option <qemu:commandline> which specifically
works like this. It is enabled specifically with changed scheme.
OK, we can have this option enabled only under the same
condition. But we have to have a way to solve the problem
at the moment. Not in 3 month of painful dances within
the driver. May be with limitations line increased memory
footprint, but still.

Will it work for you?

Den



reply via email to

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