[Top][All Lists]

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

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

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

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

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'
          <option name='l2-cache-size' value='64M/>
          <option name='cache-clean-interval' value='32'/>
      <source file='/var/lib/libvirt/images/rhel7.qcow2'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>

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.

Any opinion?


reply via email to

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