On Fri, Jul 10, 2015 at 09:00:14AM +0200, Ján Tomko wrote:
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
How does this relate to this patch?
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list