[libvirt] [PATCH] qemuDomainUpdateDeviceConfig: Allow full disk update

[Martin Kletzander]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160926/f9818072/attachment-0001.sig>