On Fri, Feb 22, 2008 at 11:07:15AM +0000, Richard W.M. Jones wrote: > On Fri, Feb 22, 2008 at 10:47:44AM +0000, Mark McLoughlin wrote: > > On Fri, 2008-02-22 at 05:16 -0500, Daniel Veillard wrote: > > > > > I also agree to some extend with Mark, the on disk > > > storage should probably go in the network description. But that's > > > orthogonal to the API side :) > > > > Heh, no it's not orthogonal ... XML *is* the API for this kind of stuff > > across libvirt :-) > > Sort of. XML is used as a way to avoid making any ABI guarantees. > > I had a look at the implementation of the network XML. There are > three calls which matter: > > virNetworkDefineXML > > Define the network from the XML definition, but don't start it up. > > Saves the XML into a private directory so that it will be loaded > when libvirtd restarts (and depending on the autostart setting may > also be started up automatically). > > The current implementation always completely recreates the > internal network definitions from scratch. > > virNetworkCreateXML > > Start up the network from the XML definition. > > As far as I can see, this doesn't persist the XML so the network > will disappear after libvirtd is restarted. > > The current implementation always completely recreates the > internal network definitions from scratch. > > virNetworkUndefine > > Stops the network. > > Deletes the config file and autostart setting from the private > directory. > > The first two calls need to be changed to look for incremental changes > in the XML, since its better to avoid fully restarting dnsmasq, and we > certainly don't want to try taking down the bridge. We can't change the semantics of these calls. virNetworkDefineXML() explicitly does not affect the current live config, saving the config to take effect next time the network is started. This is the same semantics as the virDomainDefineXML() call, and the virStoragePoolDefineXML() calls. To do live updates, we'd need API similar to the domain device hot attach and detach APIs Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list