On Thu, Jul 09, 2015 at 06:36:00PM +0200, Martin Kletzander wrote:
If one calls update-device with information that is not updatable,
libvirt reports success even though no data were updated. The example
used in the bug linked below uses updating device with <boot order='2'/>
which, in my opinion, is a valid thing to request from user's
perspective. Mainly since we properly error out if user wants to update
such data on a network device for example.
And since there are many things that might happen (update-device on disk
basically knows just how to change removable media), check for what's
changing and moreover, since the function might be usable in other
dirvers (updating only disk path is a valid possibility) let's abstract
it for any two disks.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1007228
---
src/conf/domain_conf.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_driver.c | 3 ++
4 files changed, 117 insertions(+)
+ CHECK_EQ(blkdeviotune.write_iops_sec_max,
+ "blkdeviotune.write_iops_sec_max",
+ true);
+ CHECK_EQ(blkdeviotune.size_iops_sec,
+ "blkdeviotune.size_iops_sec",
+ true);
Last time I tried, the blkiotune values were reset by media change:
https://bugzilla.redhat.com/show_bug.cgi?id=1177093
Jan