Am 25.01.2017 um 20:44 hat Denis V. Lunev geschrieben: > This is what I have exactly started from: > http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/qemu-kvm-rhev-2.6.0-27.el7.src.rpm > > This package starts VM well for the above mentioned configuration: > > <disk type='file' device='cdrom'> > <driver name='qemu' type='raw' cache='none' io='native'/> > <target dev='sdb' bus='scsi'/> > <readonly/> > </disk> > > but the problem comes later at 'change' moment. It reports > > 'Details: internal error: unable to execute QEMU command 'change': > aio=native was specified, but it requires cache.direct=on, which > was not specified.)' > > > Thus partial solution implemented by the RedHat is really > partial and does not work at the second stage. I have started from
That's a downstream problem that is probably worth fixing, but of course not with an upstream patch. Can you create a Bugzilla for this and assign it to Max, John or me? (Putting the rest of us into the CC list) > the problem for me is that each clone() call is costly and counts. That > is why we are trying to avoid it whenever possible. That is why 'native' > mode is MUCH better. Also it would be very nice not to use cached > IO, which is very good for memory overcommit situations. > > Here I am fighting not with the performance, which does not make > any real sense, but with a memory footprint. This makes sense generally, but for empty CD-ROMs, no I/O request is ever made, so neither Linux AIO nor the thread pool is used. You only get a specific cache/aio mode once you actually insert a block driver node to the virtual device. > > Second, all this patch does is revert some changes done by commit > > 91a097e7478940483e76d52217f05bc05b98d5a5, which was very deliberate. > > > > Third, you may then be asking for the recommended way to put an > > aio=native medium into a CD-ROM drive. Good thing you ask, because we > > have a way that we want to recommend but can't because it's still > > considered experimental: > > > > The BDS is added using blockdev-add, with all of the appropriate caching > > and aio options. Then it's inserted into the drive using the > > x-blockdev-insert-medium command, and the drive is closed using > > blockdev-close-tray. > the problem, again, is that with x-blockdev-insert-medium I can not > deal with block driver options, or may be I am missing something. The thing that you insert with x-blockdev-insert-medium is a block driver node that you presumably created with blockdev-add, so you did have a chance to specify whichever options you want. Kevin
