Re: [PATCHv2 2/4] network: change location of network state xml files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/23/2014 09:52 PM, John Ferlan wrote:
>
> On 04/17/2014 07:43 AM, Laine Stump wrote:
>> For some reason these have been stored in /var/lib, although other
>> drivers (e.g. qemu and lxc) store their state files in /var/run.
>>
>> It's much nicer to store state files in /var/run because it is
>> automatically cleared out when the system reboots. We can then use
>> existence of the state file as a convenient indicator of whether or
>> not a particular network is active.
>>
>> Since changing the location of the state files by itself will cause
>> problems in the case of a *live* upgrade from an older libvirt that
>> uses /var/lib (because current status of active networks will be
>> lost), the network driver initialization has been modified to migrate
>> any network state files from /var/lib to /var/run.
>>
>> This will not help those trying to *downgrade*, but in practice this
>> will only be problematic in two cases
>>
>> 1) If there are networks with network-wide bandwidth limits configured
>>    *and in use* by a guest during a downgrade to "old" libvirt. In this
>>    case, the class ID's used for that network's tc rules, as well as
>>    the currently in-use bandwidth "floor" will be forgotten.
>>
>> 2) If someone does this: 1) upgrade libvirt, 2) downgrade libvirt, 3)
>>    modify running state of network (e.g. add a static dhcp host, etc),
>>    4) upgrade. In this case, the modifications to the running network
>>    will be lost (but not any persistent changes to the network's
>>    config).
>> ---
>> change from V1:
>>
>> * merged previous 2/5 & 3/5 into a single patch that changes the
>>   location and migrates old state files, to avoid potential problems
>>   by people trying to use git bisect.
>>
>> * move the files with a direct copy, rather than reading/parsing the
>>   XML then formatting/writing it. Note (hopefully) correct use of
>>   readdir!
>>
>> * put the migration into a separate static function
>>
>> * don't put oldStateDir in driverState, as we only use it once during
>>   initialization.
>>
>> * only attempt migration when running privileged, since the
>>   unprivileged state location hasn't changed.
>>
>>  src/network/bridge_driver.c | 97 ++++++++++++++++++++++++++++++++++++++++++---
>>  1 file changed, 91 insertions(+), 6 deletions(-)
>>
> ACK; however... Your call if you want to wait for virDirRead() from:
>
> http://www.redhat.com/archives/libvir-list/2014-April/msg00745.html
>
> Then refactor your for (;;) loop to use it...

I think I would rather push it as-is, then send a separate patch to
switch to virDirRead() (unless ncopa adds that to his series). The
reason I'd rather keep it separate is to decrease the number of
prerequisite patches in case this one is backported.


>
> I'm "assuming" the files cannot be adjusted during the period when
> libvirt is "migrating" by any other "legal" :-) means.

No, the network driver is unusable by anyone until
networkStateInitialize() returns success.

> Just typing "out
> loud" since your v1 would lock the network object and save the status in
> the new location.

That was just a by-product of using a higher level method to do the copy
(read status into the network list, then write the status back out).

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]