On Fri, Sep 23, 2016 at 05:42:41PM -0400, John Ferlan wrote:
On 09/02/2016 07:41 AM, Michal Privoznik wrote:https://bugzilla.redhat.com/show_bug.cgi?id=1368417 So far, when it comes to 'virsh update-device --config' of disks we are limiting ourselves for just the disk source update and just for CDROMs and floppies. This makes no sense. Especially if you look around and see that we already allow full update to graphics and net devices. So let's just take whatever XML user wants to have there and replace our internal definition with it. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> --- src/qemu/qemu_driver.c | 26 +++++++------------------- 1 file changed, 7 insertions(+), 19 deletions(-)Crazy this has been this way since 0.9.0 (commit id 'f37c29c8a'). Although this patch certainly does more than just ensure the startupPolicy adjustment works for --config as well as --live (which is the basis of the bug). I would think to "just fix" the bug/issue "DISK" could be added to that negative if condition, which leaves just LUN as a type that wouldn't be updateable (since startupPolicy is updated in the subsequent code). I guess the question is - is there something in the DISK or LUN specific usages that shouldn't be just updated or something that could be lost if we simply delete the old one without copying "something" in (_virDomainDiskDef is used for a lot and especially that private piece which could be of concern). The text in the last paragraph of virDomainUpdateDeviceFlags just doesn't give me enough of a hint why FLOPPY and CDROM were specifically singled out.
It has been that way because we can't update everything LIVE. And CONFIG just followed (or was left to rot in the fiery pits of I'm-not-touching-this-code land). Basically, update with CONFIG is the same thing that you would do with 'virsh edit', just for a particular device. And we allow everything to be edited and saved there. So ther eis no reason for restricting anything here in this function, unless there's some requirement in the callers. And since there is one caller that uses this to modify a temporary definition (and updates the domain only after everything else succeeded) I see no reason why this couldn't go in. So from me it's an ACK. Feel free to chime in if you have other ideas. Martin
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list