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

[Denis V. Lunev]

On 03/16/2017 06:20 PM, Daniel P. Berrange wrote:
> On Thu, Mar 16, 2017 at 06:15:27PM +0300, Denis V. Lunev wrote:
>> On 03/16/2017 06:08 PM, Daniel P. Berrange wrote:
>>> On Thu, Mar 16, 2017 at 06:00:46PM +0300, Denis V. Lunev wrote:
>>>> 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
>>>> 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.
>>> We can explicitly allow L2 cache size set in the XML but that
>>> is a pretty poor solution to the problem IMHO, as the mgmt
>>> application has no apriori knowledge of whether a particular
>>> cache size is going to be right for a particular QCow2 image.
>>>
>>> For a sustainable solution, IMHO this really needs to be fixed
>>> in QEMU so it has either a more appropriate default, or if a
>>> single default is not possible, have QEMU auto-tune its cache
>>> size dynamically to suit the characteristics of the qcow2 image.
>> Yes, I agree. That is why I am spoken about the kludge.
>>
>>
>>>> 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.
>>> Sure, you can use <qemu:commandline> passthrough - that is the explicit
>>> temporary workaround - we don't provide any guarantee that your guest
>>> won't break when upgrading either libvirt or QEMU though, hence we
>>> mark it as tainted.
>> No and yes. Yes, <qemu:commandline> partially solves the situation.
>> No this solution has tooo strong drawbacks IMHO. The configuration
>> of this VM could not be changed anymore in any viable way and
>> there are a lot of problems as one disk is absent at libvirt level.
>>
>> Can we add the option when the VM config is tainted and debug
>> scheme enabled specifically to the disk level? This would the best
>> partial solution, which will not ruin other management tasks
>> like backup, disk add etc.
> We really don't want to propagate the custom passthrough into further
> areas of the XML. It is intentionally limited because it is not
> something we want people/apps to use for anything other than a short
> term hack. You should be able to use qemu's  '-set' argument to set
> fields against existing QEMU args, without having to throw away the
> entire libvirt <disk> config built by libvirt.
>
> Regards,
> Daniel
Technically this solves the problem, but still we need to specify options
without such hacks.

Den