[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [RFC] finegrained disk driver options control
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-block] [RFC] finegrained disk driver options control |
Date: |
Thu, 16 Mar 2017 14:45:31 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
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
--
|: 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/ :|
- [Qemu-block] [RFC] finegrained disk driver options control, Denis V. Lunev, 2017/03/16
- Re: [Qemu-block] [RFC] finegrained disk driver options control,
Daniel P. Berrange <=
- Re: [Qemu-block] [RFC] finegrained disk driver options control, Denis V. Lunev, 2017/03/16
- Re: [Qemu-block] [RFC] finegrained disk driver options control, Kevin Wolf, 2017/03/16
- Re: [Qemu-block] [RFC] finegrained disk driver options control, Daniel P. Berrange, 2017/03/16
- Re: [Qemu-block] [RFC] finegrained disk driver options control, Denis V. Lunev, 2017/03/16
- Re: [Qemu-block] [RFC] finegrained disk driver options control, Kevin Wolf, 2017/03/16
- Re: [Qemu-block] [RFC] finegrained disk driver options control, Daniel P. Berrange, 2017/03/18
- Re: [Qemu-block] [RFC] finegrained disk driver options control, Alberto Garcia, 2017/03/20