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