Re: [libvirt] [RFC] finegrained disk driver options control

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