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(a)redhat.com>
> ---
> 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