9:14 a.m.
Hi guys,
one of my VM has disappeared in libvirtd. I still can see the process
with ps and the configuration file is as well there. But it is not
displayed or found with virt-manger/virsh.
virsh list shows only 4 of 5, but there is no real error message.
I restarted the daemon without solving the problem. Any idea what to do?
Here some info:
Compiled against library: libvir 0.9.13
Using library: libvir 0.9.13
Using API: QEMU 0.9.13
Running hypervisor: QEMU 0.12.1
uname -a
Linux 2.6.32-220.17.1.el6.x86_64 #1 SMP Wed May 16 00:01:37 BST 2012
x86_64 x86_64 x86_64 GNU/Linux
It's a CentOS 6
so far
Akendo
11:35 a.m.
On 08/16/2012 08:14 AM, Akendo wrote:
Hi guys,
one of my VM has disappeared in libvirtd. I still can see the process
with ps and the configuration file is as well there. But it is not
displayed or found with virt-manger/virsh.
virsh list shows only 4 of 5, but there is no real error message.
I restarted the daemon without solving the problem. Any idea what to do?
Most likely, this happened because you upgraded libvirt versions, and
the file in /var/run/libvirt/qemu corresponding to the disappearing
guest contained information placed by the older libvirt that the newer
libvirt does not understand. Could you please locate and send that xml
file for analysis, along with more precise information about your
current libvirt, and whether or not you just recently upgraded libvirt?
Also, were there any messages in libvirtd.log around the point where
you restarted libvirtd, about unrecognized XML for the disappearing guest?
Here some info:
Compiled against library: libvir 0.9.13
Was this self-built from upstream tarballs? And if so, did you remember
to also apply the RHEL-specific patches that were present on the older
distro version of libvirt? After all,
It's a CentOS 6
CentOS 6 ships a version of libvirt based on RHEL, and RHEL 6.3 only
ships with libvirt 0.9.10 + patches. Some of those patches are
important to preserve if you want a clean upgrade path.
Is the disappearing guest one that you don't mind restarting? If so,
and my guess about upgrading to self-built libvirt is correct, then
downgrade back to the libvirt that you had previously installed (you
should then see the guest listed again), stop it, then upgrade to the
new libvirt, and now you should be able to start the guest. And if that
does work, comparing the two versions of /var/run/libvirt/qemu/$dom.xml
(old libvirt vs. new libvirt) may help us identify what specific patch
from the old libvirt is causing grief in the self-built new libvirt.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
10:38 a.m.
On 08/16/2012 06:35 PM, Eric Blake wrote:
On 08/16/2012 08:14 AM, Akendo wrote:
> Hi guys,
>
> one of my VM has disappeared in libvirtd. I still can see the process
> with ps and the configuration file is as well there. But it is not
> displayed or found with virt-manger/virsh.
>
> virsh list shows only 4 of 5, but there is no real error message.
> I restarted the daemon without solving the problem. Any idea what to do?
Most likely, this happened because you upgraded libvirt versions, and
the file in /var/run/libvirt/qemu corresponding to the disappearing
guest contained information placed by the older libvirt that the newer
libvirt does not understand. Could you please locate and send that xml
file for analysis, along with more precise information about your
current libvirt, and whether or not you just recently upgraded libvirt?
Also, were there any messages in libvirtd.log around the point where
you restarted libvirtd, about unrecognized XML for the disappearing guest?
>
> Here some info:
>
> Compiled against library: libvir 0.9.13
Was this self-built from upstream tarballs? And if so, did you remember
to also apply the RHEL-specific patches that were present on the older
distro version of libvirt? After all,
>
> It's a CentOS 6
CentOS 6 ships a version of libvirt based on RHEL, and RHEL 6.3 only
ships with libvirt 0.9.10 + patches. Some of those patches are
important to preserve if you want a clean upgrade path.
Is the disappearing guest one that you don't mind restarting? If so,
and my guess about upgrading to self-built libvirt is correct, then
downgrade back to the libvirt that you had previously installed (you
should then see the guest listed again), stop it, then upgrade to the
new libvirt, and now you should be able to start the guest. And if that
does work, comparing the two versions of /var/run/libvirt/qemu/$dom.xml
(old libvirt vs. new libvirt) may help us identify what specific patch
from the old libvirt is causing grief in the self-built new libvirt.
_______________________________________________
libvirt-users mailing list
libvirt-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
Thank you very much for you reply. I upgraded the CentOS 6.3 some days
ago, but this is a default version of CentOS.
I restarted the libvirtd without success of finding my VM. But very
interesting is the fact there is a $dom.xml for my VM. Also is a
$DOM.pid file.
But i found another problem: our system has 12 cores i allowed to use 8
cores which raise this error message:
error : virDomainDefParseXML:8871 : Maximum CPUs greater than topology limit
This error message has for some reason suppress in the syslog (lor i
just didn't read right...) i reduced the amount of CPU to 4. Now it's
working again.
so far
Thank you for the help.
4:44 p.m.
On 08/21/2012 09:38 AM, Akendo wrote:
> Most likely, this happened because you upgraded libvirt versions,
and
> the file in /var/run/libvirt/qemu corresponding to the disappearing
> guest contained information placed by the older libvirt that the newer
> libvirt does not understand.
>
> CentOS 6 ships a version of libvirt based on RHEL, and RHEL 6.3 only
> ships with libvirt 0.9.10 + patches. Some of those patches are
> important to preserve if you want a clean upgrade path.
>
Thank you very much for you reply. I upgraded the CentOS 6.3 some days
ago, but this is a default version of CentOS.
It may be default CentOS, but the fact still remains that CentOS doesn't
ship libvirt 0.9.13; it trails RHEL 6.3 which ships libvirt 0.9.10+patches.
I restarted the libvirtd without success of finding my VM. But very
interesting is the fact there is a $dom.xml for my VM. Also is a
$DOM.pid file.
Yes, the domain is still running, it's just that libvirtd couldn't
figure out how to manage it because of the invalid XML.
But i found another problem: our system has 12 cores i allowed to use 8
cores which raise this error message:
error : virDomainDefParseXML:8871 : Maximum CPUs greater than topology limit
Yep, that would explain it. Older libvirt silently ignored bugs like
this in the XML, while newer libvirt rejects it; once the XML is
rejected, the VM is no longer listed by libvirt.
This error message has for some reason suppress in the syslog (lor i
just didn't read right...) i reduced the amount of CPU to 4. Now it's
working again.
Yep, that's the correct fix. Glad we found it for you.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4476
days inactive
4481
days old
3 comments
2 participants
participants (2)
-
Akendo -
Eric Blake