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 -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
