[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Ewan Mellor" <ewan@xxxxxxxxxxxxx>
  • From: "Brian Hays" <brian.hays@xxxxxxxxx>
  • Date: Tue, 11 Apr 2006 21:39:19 -0400
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 11 Apr 2006 18:39:40 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=I2jCCS6tgvvMFtDLm58fmHcdqM+sbCwoRmiy7OSDl73SUa7GnlMre2rAUaHh0vxxv5ZhFsKlGNqnU33WnPj1Kr9i3eKNSW64B6CyNt5kre5ggq6AzY7RNh9FETWHlKxYuTbJ2CY7y5bbkIWqM2N+DPCfBQGPlk09vljqgl7A2fc=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Changing the MINIMUM_RESTART_TIME to 0 seems to have fixed it but this does seem to leave me open to potential loops if there really is a problem where a domU just won't come back. Is there a maximum number of restart attempts within a time period that can be set?

Thank you,
Brian

On 4/11/06, Brian Hays <brian.hays@xxxxxxxxx> wrote:
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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.