Re: [Xen-devel] domU still not rebooting in 3.0.2

["Brian Hays" <brian.hays@xxxxxxxxx>]

Thanks. After appending the " I reconnected and found this ...

Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "sda1" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

The root device is valid. When restarting manually via "xm create configfile" everything comes up fine. I'm using LVM. Is there a possibility that Xen seeing that device as already in use for some reason during a reboot?

Thank you,
Brian

On 4/11/06, Ewan Mellor <ewan@xxxxxxxxxxxxx> wrote:

On Tue, Apr 11, 2006 at 09:02:42PM -0400, Brian Hays wrote:

> After upgrading to 3.0.2 I tried rebooting a domU (a problem sometimes in
> 3.0.1 related to bug 514) it failed to come back up. This was in my
> xend.log. ("Refusing to restart to avoid loops." .... )
>
> [2006-04-11 20:53:39 xend.XendDomainInfo] DEBUG (__init__:988) Storing
> domain details: {'console/ring-ref': '223144', 'console/port': '2',
> 'name': 'vmtest1', 'console/limit': '1048576', 'vm':
> '/vm/c73d7a4b-4747-fe91-dbc4-0408183a9456', 'domid': '10',
> 'cpu/0/availability': 'online', 'memory/target': '98304',
> 'store/ring-ref': '223145', 'store/port': '1'}
> [2006-04-11 20:53:39 xend.XendDomainInfo] DEBUG (__init__:988)
> XendDomainInfo.handleShutdownWatch
> [2006-04-11 20:53:39 xend.XendDomainInfo] WARNING (__init__:988) Domain
> has crashed: name=vmtest1 id=10.
> [2006-04-11 20:53:39 xend.XendDomainInfo] ERROR (__init__:988) VM vmtest1
> restarting too fast (1.396226 seconds since the last restart).  Refusing
> to restart to avoid loops.
> [2006-04-11 20:53:39 xend.XendDomainInfo] DEBUG (__init__:988)
> XendDomainInfo.destroy : domid=10
> [2006-04-11 20:53:39 xend.XendDomainInfo] DEBUG (__init__:988)
> XendDomainInfo.destroyDomain(10)
>
> Is there a way to adjust the parameter that tells Xen the domain is
> "restarting too fast"? Would adjusting that parameter fix this?

You could tweak it by changing MINIMUM_RESTART_TIME to 0 near the top of
/usr/lib(64)/python/xen/xend/XendDomainInfo.py, but that sounds like a bad
idea to me -- it really means it: your guest has crashed immediately after
reboot.

The best thing to do is to change in your xm create config
file, reboot the domain, and then attach the console to the dead, preserved
domain to find out why it crashed.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel