| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Memory allocation with rebooted HVM
Is there a known bug in xen-unstable with rebooting of HVMs w/stubdom,
and
having the new domU come up before the old domU has been shut down and
its
memory fully reclaimed?
Yes. Perhaps there is a race between shutting down the stubdom and
creating
the new domU? The stubdom maps a lot of the old domU's memory, and that
wouldn't get freed until the stubdom is destroyed.
Nod, that makes sense. Would this be a simple fix?
After that, Xend was unresponsive. Killing it and restarting it killed
all the
other domU's, but new ones still couldn't be created, forcing me to
reboot the
physical machine.
Odd, since it should be possible to restart just xend (but not xenstored
and
other daemons) and have the system continue to work okay. Could new ones
still not be created due to lack of memory? If you use Xen's 'q' debug
key,
how many domains does Xen itself think are still alive?
If I remember correctly, xend wasn't responding to any commands, so I
restarted it with "xend restart". The domUs stayed online, but "xm top" then
showed a blank screen (no domains listed at all), and when I tried to
recreate the crashed domain again with "xm create", that still timed out
(and "xm list" also timed out). I discovered that the old xend was still
running, frozen, so I nuked it with "killall -9 xend" and then started up a
new instance with "xend start". At that point, the domUs dropped offline and
a fresh "xm top" showed only dom0 and one other domain, that it called
"Domain-unnamed" or something similar; all the rest of the memory was listed
as free. I tried "xm create" again and it timed out, so I chose to reboot
the machine. Rebooting it hung the box (something that has not happened to
me before), so I had to remotely power cycle to bring it back to a usable
state.
-John
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home