Laine,
How do I make interfaceid persistent across libvirtd restarts if user did
not specify one in domain XML config file and libvirtd generated it for him
automatically? It seems that different interfaceid is regenerated each time
the libvirtd is restarted.
If I understand correctly then two XML files come into picture:
1. /usr/local/etc/libvirt/qemu/VM1.xml, which stores persistent
*config*for the whole domain life-time (without UUID); and
2. /usr/local/var/run/libvirt/qemu/VM1.xml, which stores the *instantiated
config* with the generated UUID after reading the original
*config*file. But unfortunately after libvirtd is restarted this file
gets
destroyed and has different UUID next time Domain is started.
I guess that my goal would be to update file #1 with the generate UUID. Is
that supported or would the user have to manually specify the UUID in *
config* XML?
Thanks,
Ansis
On Fri, Feb 3, 2012 at 7:18 PM, Laine Stump <laine(a)laine.org> wrote:
On 02/03/2012 10:42 AM, Ansis Atteka wrote:
On Thu, Feb 2, 2012 at 10:10 PM, Laine Stump <laine(a)laine.org> wrote:
>
>>
>> There are a few other places where it may be appropriate to do the
>> bridge removal during error paths; this same search may show you some of
>> them, and some others may show up when you search for where
>> virNetDevTapCreateInBridgePort.
>>
>
Wouldn't it be simpler to do port removal just inside the
networkReleaseActualDevice() function if this is interface that was
attached to an OVS bridge? Would this make any problems to the overall
design? The code seems to work...
No. networkAllocateActualDevice and networkReleaseActualDevice are only
intended to acquire network-specific configuration/resourced for the guest
from a <network> object, and release it later; they shouldn't be used as a
clearing house for general guest interface setup/teardown.
Looking through all this code I've been thinking it might be nice to
create such "clearing house" setup/teardown functions, but what I've seen
so far is that there are places where only some of the full list of
functions are called (don't know if that means missing functionality /
bugs, or genuinely different situations that require a different set of
actions), and am too busy now with other projects to investigate further.
In the meantime, if you can try to make your additions in the (at least)
two places as similar as possible, that will make it easier for us to later
go in and create functions that do complete interface setup/teardown.