This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Ewan Mellor" <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] domU still not rebooting in 3.0.2
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <e4ca66ec0604111821m3b82582byf21131c5a4d03a9b@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <e4ca66ec0604111802s6d402407q486e9d523a184850@xxxxxxxxxxxxxx> <20060412011134.GA8048@xxxxxxxxxxxxxxxxxxxxxx> <e4ca66ec0604111821m3b82582byf21131c5a4d03a9b@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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,

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,

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

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.


Xen-devel mailing list