From: Florian Kirstein <xenlist@custom.ray.net>
To: xen-devel@lists.xensource.com
Subject: Two problems with DomU reboot (cmdline, duplicate domains)
Date: Wed, 17 Jan 2007 23:36:59 +0100 [thread overview]
Message-ID: <20070117233659.A22236@web.ray.net> (raw)
Hi,
just upgraded my testsystem to 3.0.4 (using the provided source rpm,
xen-3.0.4.1-1.src.rpm, rebuilt it to run on non-PXE but no changes besides
that, and it doesn't look like the 3.0.4-testing HG has major differences
so far?) and I have two problems with rebooting domains (xm reboot, or
reboot from inside the domain).
1) the kernel-commandline keeps growing. On the first boot it's OK, on
the second it's there 3-times as one long cmdline:
ip=172.16.37.9:1.2.3.4:172.16.37.19:255.255.255.0::eth0:off root=/dev/sda1 ro ip=172.16.37.9:1.2.3.4:172.16.37.19:255.255.255.0::eth0:off root=/dev/sda1 ro ip=172.16.37.9:1.2.3.4:172.16.37.19:255.255.255.0::eth0:off root=/dev/sda1 ro
and on the next reboot it's longer than the kernel supports, which usually
breaks networking as the kernel seems to use the last "ip=" parameter which
most probably is incomplete then. It also happens when I don't specify
networking there, using a config almost identical to xmexample1, after
the first reboot:
# cat /proc/cmdline
root=/dev/sda1 ro root=/dev/sda1 ro root=/dev/sda1 ro 3
interesting that the "3" from the "extra" parameter is not doubled...
2) it happend twice so far (non-reproducable for me yet) that after
a reboot I had the same DomU twice, using the same name and the same
blockdevices (LVM based phy: devices). This of course resulted in
major data corruption and really doesn't make me feel well. I read
there were changes in the code which should prevent this, but
for me it seems like it got worse, had this never before...
Thanks for any ideas for this, will try the current 3.0.4-testing
hg later, but as I currently can't reproduce "2)" I hope someone
here knows if this is fixed and by what this could have been
triggered?
(:ul8er, r@y
P.S: Oh, I could reproduce it a third time, think I just issued another
reboot on the domain. Probably while having a libvirt-based tool list
domains in the background, doing some tests there now... However, this
is how it looks:
DomU9 72 50 1 -b---- 8.8
DomU9 73 50 1 -b---- 8.1
and both are actually running, I can attach to both consoles using
/usr/lib/xen/bin/xenconsole 72
/usr/lib/xen/bin/xenconsole 73
and they are indeed different instances running on the same blockdevices.
Ouch :)
P.P.S: Here's an excerpt from the xend.log (from the first time it
happend) which I suppose shows the part where the duplicate Domain
was created, unfortunately the log-level was set to INFO:
[2007-01-17 16:28:04 xend.XendDomainInfo 12761] INFO (XendDomainInfo:969) Domain
has shutdown: name=DomU9 id=18 reason=reboot.
[2007-01-17 16:28:04 xend.XendDomainInfo 12761] INFO (XendDomainInfo:969) Domain
has shutdown: name=DomU9 id=18 reason=reboot.
[2007-01-17 16:28:04 xend.XendDomainInfo 12761] INFO (XendDomainInfo:969) Domain
has shutdown: name=DomU9 id=18 reason=reboot.
[2007-01-17 16:28:05 xend.XendDomainInfo 12761] ERROR (XendDomainInfo:1063) Xend
failed during restart of domain None. Refusing to restart to avoid loops.
[2007-01-17 16:28:05 xend.XendConfig 12761] WARNING (XendConfig:606) Unconverted
key: cpus
[2007-01-17 16:28:05 xend 12761] INFO (image:125) buildDomain os=linux dom=19 vc
pus=1
[2007-01-17 16:28:05 xend.XendDomainInfo 12761] INFO (XendDomainInfo:1194) creat
eDevice: vbd : {'uuid': '5f42ac79-37a5-3511-5586-d215a356aa2d', 'driver': 'parav
irtualised', 'dev': 'sda1:disk', 'uname': 'phy:/dev/vgrc/h_root_110', 'mode': 'w
', 'backend': 0}
[2007-01-17 16:28:05 xend.XendDomainInfo 12761] INFO (XendDomainInfo:1194) creat
eDevice: vbd : {'uuid': 'a6f7ccdb-f331-211f-1721-22a8d7aa2097', 'driver': 'parav
irtualised', 'dev': 'sda2:disk', 'uname': 'phy:/dev/vgrc/swap110', 'mode': 'w',
'backend': 0}
[2007-01-17 16:28:05 xend.XendDomainInfo 12761] INFO (XendDomainInfo:1194) creat
eDevice: vif : {'ip': '172.16.37.9', 'mac': '00:16:3e:00:32:f1', 'script': 'vi
f-route', 'uuid': '28a916b8-0e7c-cd43-81b6-fd35bf48ecae', 'backend': 0}
[2007-01-17 16:28:06 xend.XendConfig 12761] WARNING (XendConfig:606) Unconverted
key: cpus
[2007-01-17 16:28:06 xend 12761] INFO (image:125) buildDomain os=linux dom=20 vc
pus=1
[2007-01-17 16:28:06 xend.XendDomainInfo 12761] INFO (XendDomainInfo:1194) creat
eDevice: vbd : {'uname': 'phy:/dev/vgrc/h_root_110', 'driver': 'paravirtualised'
, 'mode': 'w', 'dev': 'sda1', 'uuid': '5f42ac79-37a5-3511-5586-d215a356aa2d'}
[2007-01-17 16:28:06 xend.XendDomainInfo 12761] INFO (XendDomainInfo:1194) creat
eDevice: vbd : {'uname': 'phy:/dev/vgrc/swap110', 'driver': 'paravirtualised', '
mode': 'w', 'dev': 'sda2', 'uuid': 'a6f7ccdb-f331-211f-1721-22a8d7aa2097'}
[2007-01-17 16:28:06 xend.XendDomainInfo 12761] INFO (XendDomainInfo:1194) creat
eDevice: vif : {'ip': '172.16.37.9', 'mac': '00:16:3e:00:32:f1', 'script': 'vi
f-route', 'uuid': '28a916b8-0e7c-cd43-81b6-fd35bf48ecae', 'backend': 0}
next reply other threads:[~2007-01-17 22:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-17 22:36 Florian Kirstein [this message]
2007-01-19 9:41 ` [PATCH] fix: growing kernel commandline Florian Kirstein
2007-01-19 10:29 ` Ian Campbell
2007-01-19 11:59 ` Florian Kirstein
2007-01-21 8:59 ` Bug: Problematic DomU Duplication on reboot Florian Kirstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070117233659.A22236@web.ray.net \
--to=xenlist@custom.ray.net \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.