Re: [RFC Incomplete Patch] Libvirt + Openvswitch

Ansis Atteka <aatteka@xxxxxxxxxx> · Fri, 3 Feb 2012 22:03:57 +0200

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:
/usr/local/etc/libvirt/qemu/VM1.xml, which stores persistent config for the whole domain life-time (without UUID); and
/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@xxxxxxxxx> wrote:

    On 02/03/2012 10:42 AM, Ansis Atteka wrote:

            On Thu, Feb 2, 2012 at 10:10 PM, Laine Stump
              <laine@xxxxxxxxx>
              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.

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