On Fri, Feb 27, 2009 at 02:59:23PM -0800, David Lutterkort wrote:
> On Fri, 2009-02-27 at 10:07 +0200, Dan Kenigsberg wrote:
> > The real issue is, that in this stage, management may have lost
> > connectivity to the node.
>
> What exactly is the scenario here ? Are you trying to manage any old
> node as long as it has libvirt installed ? As soon as you need any sort
> of management-specific code on the node, you might as well implement the
> logic below in your management code.
The scenario is of a central management of multiple nodes, where libvirt
is called through remote:///-style connection. If you have an agent
on each node and don't use libvirt across the network, there's indeed no
problem.
>
> > > if (! newConfigIsWorking()) {
> > > virInterfaceDefine(goodConfig);
> > > virInterfaceRestart(ifaceName);
> > > }
> >
> > How about having netcf/libvirt be aware of what is a goodConfig (with
> > additional API verb), and back it up somewhere? Any change to to network
> > configuration would have immediate effect, but unless explicitly set as
> > "good", reverted on next boot.
>
> While what you suggest will work in theory (with the minor caveat that
> reverting to a "good" config can only be triggered by a restart of
> libvirtd, not a reboot) it is a poor man's workaround for management
> systems that do not provide proper failsafe functionality.
>
> In particular, if you are part of the management system, you have a much
> better idea (on the node) what it means to have a working network
> configuration, and can recover from misconfigured network much more
> gracefully than with the big hammer of a system reboot.
I think I'll have the big hammer in my toolkit, just in case..
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list