[libvirt] [PATCH] lxc: Do not try to reconnect inactive domain when do lxcStartup
Otherwise if there are inactive lxc domains, lxcStartup will try to reconnect to sockets of these domains, which results in errors in libvirtd log. --- src/lxc/lxc_driver.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index e905302..ef7827b 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -1992,6 +1992,9 @@ lxcReconnectVM(void *payload, const void *name ATTRIBUTE_UNUSED, void *opaque) virDomainObjLock(vm); + if (!virDomainObjIsActive(vm)) + goto cleanup; + priv = vm->privateData; if ((priv->monitor = lxcMonitorClient(driver, vm)) < 0) { goto cleanup; -- 1.7.4
On 04/29/2011 01:21 AM, Osier Yang wrote:
Otherwise if there are inactive lxc domains, lxcStartup will try to reconnect to sockets of these domains, which results in errors in libvirtd log. --- src/lxc/lxc_driver.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
ACK. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
于 2011年04月29日 23:11, Eric Blake 写道:
On 04/29/2011 01:21 AM, Osier Yang wrote:
Otherwise if there are inactive lxc domains, lxcStartup will try to reconnect to sockets of these domains, which results in errors in libvirtd log. --- src/lxc/lxc_driver.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
ACK.
Thanks, applied. Regards Osier
On Fri, Apr 29, 2011 at 03:21:03PM +0800, Osier Yang wrote:
Otherwise if there are inactive lxc domains, lxcStartup will try to reconnect to sockets of these domains, which results in errors in libvirtd log. --- src/lxc/lxc_driver.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index e905302..ef7827b 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -1992,6 +1992,9 @@ lxcReconnectVM(void *payload, const void *name ATTRIBUTE_UNUSED, void *opaque)
virDomainObjLock(vm);
+ if (!virDomainObjIsActive(vm)) + goto cleanup; + priv = vm->privateData; if ((priv->monitor = lxcMonitorClient(driver, vm)) < 0) { goto cleanup;
I don't see how this can be correct. The startup code does: if (virDomainLoadAllConfigs(lxc_driver->caps, &lxc_driver->domains, lxc_driver->configDir, lxc_driver->autostartDir, 0, NULL, NULL) < 0) goto cleanup; virHashForEach(lxc_driver->domains.objs, lxcReconnectVM, lxc_driver); So, at the point 'lxcReconnectVM' is called 'virDomainIsActive' will return false for *every* single VM, even ones that *are* active. You can't use 'virDomainIsActive' in this way, until we've loaded the live state XML, which is later on in the lxcReconnectVM method. So, AFAICT, this patch means we will never reconnect to any LXC VMs now. The correct solution, is to refactor LXC driver startup to work the same way as the QEMU driver startup. - Load all the live state XML files (to pick up running VMs) - Reconnect to all VMs - Load all the persistent config XML files (to pick up any additional inactive guets) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 05/03/2011 07:09 AM, Daniel P. Berrange wrote:
On Fri, Apr 29, 2011 at 03:21:03PM +0800, Osier Yang wrote:
Otherwise if there are inactive lxc domains, lxcStartup will try to reconnect to sockets of these domains, which results in errors in libvirtd log. --- src/lxc/lxc_driver.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
I don't see how this can be correct.
So, AFAICT, this patch means we will never reconnect to any LXC VMs now.
The correct solution, is to refactor LXC driver startup to work the same way as the QEMU driver startup.
- Load all the live state XML files (to pick up running VMs) - Reconnect to all VMs - Load all the persistent config XML files (to pick up any additional inactive guets)
Osier, can you get this done before 0.9.1, or are we better off reverting commit 0e7f7f85 for the release and resolving this post-release? -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Tue, May 03, 2011 at 09:19:59AM -0600, Eric Blake wrote:
On 05/03/2011 07:09 AM, Daniel P. Berrange wrote:
On Fri, Apr 29, 2011 at 03:21:03PM +0800, Osier Yang wrote:
Otherwise if there are inactive lxc domains, lxcStartup will try to reconnect to sockets of these domains, which results in errors in libvirtd log. --- src/lxc/lxc_driver.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
I don't see how this can be correct.
So, AFAICT, this patch means we will never reconnect to any LXC VMs now.
The correct solution, is to refactor LXC driver startup to work the same way as the QEMU driver startup.
- Load all the live state XML files (to pick up running VMs) - Reconnect to all VMs - Load all the persistent config XML files (to pick up any additional inactive guets)
Osier, can you get this done before 0.9.1, or are we better off reverting commit 0e7f7f85 for the release and resolving this post-release?
I vote for reverting it, since the original "problem" was merely a harmless message in the logs which isn't a release show stopper. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 05/03/2011 09:37 AM, Daniel P. Berrange wrote:
Osier, can you get this done before 0.9.1, or are we better off reverting commit 0e7f7f85 for the release and resolving this post-release?
I vote for reverting it, since the original "problem" was merely a harmless message in the logs which isn't a release show stopper.
I've gone ahead and pushed the reversion commit. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
于 2011年05月04日 00:11, Eric Blake 写道:
On 05/03/2011 09:37 AM, Daniel P. Berrange wrote:
Osier, can you get this done before 0.9.1, or are we better off reverting commit 0e7f7f85 for the release and resolving this post-release?
I vote for reverting it, since the original "problem" was merely a harmless message in the logs which isn't a release show stopper.
I've gone ahead and pushed the reversion commit.
Yeah, Dan is right, Thanks for doing this, Eric, will send another patch to fix the problem. Regards Osier
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Osier Yang