>>> Lars Marowsky-Bree <l...@suse.com> schrieb am 17.07.2015 um 09:50 in >>> Nachricht <20150717075045.gu6...@suse.de>: > On 2015-07-09T17:13:01, Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> > wrote: > >> I was watching our Xen-cluster when there were problems, and I found this: >> Name ID Mem VCPUs State > Time(s) >> Domain-0 0 13401 24 r----- >> 560.6 >> [...other domains running...] >> v08 8 16384 1 --p--- >> 0.0 >> v09 9 16384 0 --p--- >> 0.0 >> >> Jul 9 17:06:04 h01 Xen(prm_xen_v08)[12923]: INFO: Xen domain v08 will be > stopped (timeout: 400s) >> Jul 9 17:06:09 h01 Xen(prm_xen_v09)[12922]: INFO: Xen domain v09 already > stopped. >> >> Obviously this is not true: When the cluster tried to start the domain, it > never left that p-state. But the re-create the domain, I guess the cluster > has > to destroy the existing domain. >> >> Any insights on this? > > The usual answer: please file a bug report.
So you are saying it's a bug? Anyway, what had happened was this: Someone changed the VM configuration of another VM to get more memory. Then the cluster tried to start all VMs on a single node, but that node (Domain-0) did not have enough memory... Thus the VMs were staying in that "p-state". What I guess is this: Such a domain is not actually running (and needs to be destroyed (stopped) before any attempt to start the VM elsewhere is done) Can you confirm? Another question is why Xen doesn't fail the start of such a VM more or less immediately; it seems Xen is waiting for more memory to arrive indefinitely. Regards, Ulrich _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
