Submitted by jasongayson on Thu, 02/07/2013 - 21:07
Not all "start at host boot time" systems will actually start at boot, due to "xc_dom_boot_mem_init: can't allocate low memory for domain."
It's related to the issue where Cloudmin "orphans" physcal memory; basically sometimes not updating min-memory/max-memory for dom0 after deleting systems that no longer use it any memory. This leaves a gaping hole in the memory allocation which has to be fixed with "xm" manually.
Status:
Active
Comments
Submitted by JamieCameron on Thu, 02/07/2013 - 23:54 Comment #1
I wasn't aware that holes in memory allocation needed to be fixed after deleting systems. What
xmcommand did you use to do this exactly?I'd expect that Xen would handle this kind of thing automatically when a VM is shut down or deleted.
Submitted by jasongayson on Fri, 02/08/2013 - 00:11 Comment #2
When you create a Xen system, you take a slice of dom0 memory and steal it away from dom0.
Basically: * Downsize dom0's memory pool * Tell Xen to give it to a different domain ID (for a domU VM)
You can view your active systems and their memory max values with:
Then view free (owned by Xen) memory:
The "free_memory" value is memory not owned by any running domain.
To resize a domain, use:
So, once or twice, I've seen Cloudmin (possibly Xen's fault) improperly delete systems and keep a "free" memory hole. It becomes impossible to create a new VM (due to no more memory that dom0 can afford to give out). So first I have to give the memory back to dom0, THEN I can create a new machine.
Damn. I have submitted 40 bug reports in 1 day... this is insane.
Submitted by JamieCameron on Sat, 02/09/2013 - 01:38 Comment #3
I'm not sure what else Cloudmin can do here? If there is a Xen bug that prevents memory from being freed, that seems out of our control :-(