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

Re: [libvirt] [RFC Incomplete Patch] Libvirt + Openvswitch


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?


On Fri, Feb 3, 2012 at 7:18 PM, Laine Stump <laine 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 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.

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