[libvirt] [RFC Incomplete Patch] Libvirt + Openvswitch
Ansis Atteka
aatteka at nicira.com
Fri Feb 3 20:03:57 UTC 2012
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 at 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 at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120203/893b057b/attachment-0001.htm>
More information about the libvir-list
mailing list