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

[Xen-users] Kernel modules errors and weird xl behavior with Xen 4.1


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Claudiu CurcÄ <alexstrasza2@xxxxxxxxx>
  • Date: Sun, 10 Apr 2011 14:28:23 +0300
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sun, 10 Apr 2011 04:29:57 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=PQDGrd4QH4KRMAF+e3kgkwZHUwDEcotEXdUNrtP4SKHL78B0X2d9Gvv9lheG2+pZBz I/uAioFiU5msnxE2RxePYf/ffRz9l8lMljyJThyFk7z1w/o9x/yT+oLQd/ap/tMFBwbH Fl3ehrNw7DA6V4euEZme25ELV3NZLgniUJKEM=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Hello,

I'm using Gentoo Linux amd64 with the 2.6.34-xen-r4 kernel from portage.
I've been successfully using Xen 4.0 for almost a year, but now it
seems that with the dawn of Xen 4.1, the package maintainers have
forces unstable users to upgrade from 4.0 to 4.1

Looking forward to try the new xl interface, I installed it, but there
seem to be a few problems with xen-4.1

First off, xl seems to behave weird. For example, I have the following
domU config:

builder = "linux"
bootloader = "/usr/bin/pygrub"
vcpus = 1
memory = 512
name = "centos5_vm1"
root = "/dev/xvda1 ro"
disk = [ "file:/storage/xen/images/centos5-vm1.img,xvda,w" ]
vif = [ "ip = 172.18.0.225, mac = 00:16:3e:00:00:25" ]
vfb = [ "type = vnc, vncdisplay = 25, vnclisten = 172.18.0.1" ]

There are two issues if I start the domain using "xl create". The
first issue is that the machine has no network connectivity at all.
The second one is that the VNC session is not started. If I try to
connect to 172.18.0.1:5925, I get a "connection refused" error, and
netstat doesn't show anyone listening at that location. The domain
shows up in "xl list" as running. These problems do not show up if
using the old-fashion "xm create". A minor inconvenience, compared to
what's to come.

The big showstopper for this were some kernel problems. Regardless if
I start any domain, or even xencommons/xend, at some random time (at
most 5 minutes), random hardware components will fail.

For reference, here's the setup:

MB: Intel S5520HCV Motherboard
CPUs: 2x Intel Xeon E5520
RAM: 16GB DDR3
Networking: 2x Intel Gigabit (eth1+eth2 using igb kernel driver) and
1x Linksys Fast PCI Ethernet Adapter (eth0 using tulip kernel driver)
Storage: 3ware 9650SE-8ML RAID controller (using 3w-9xxx kernel driver)

eth0 is the internet adapter, eth1 is the LAN adapter (bridged to
xenbr0) and eth2 is another LAN adapter on a different network,
unbridged.

For example, this kills my network connection on eth0 (external
connection): http://pastebin.com/x8E9bxUT
Sometimes, the RAID controller would randomly stop working:

Apr 10 05:16:07 localhost kernel: [  646.720086] sd 4:0:0:0: WARNING:
(0x06:0x002C): Command (0x28) timed out, resetting card.
Apr 10 05:16:45 localhost kernel: [  684.816086] 3w-9xxx: scsi4:
WARNING: (0x06:0x0037): Character ioctl (0x108) timed out, resetting
card.

One last issue, which is also quite annoying... in Xen 4.1, if I start
a VM via xm create, then shut it down, when Xen is deleting the vif,
it somehow makes dhcpcd (I use it on eth0 to get the internet IP)
start on all interfaces (even peth1, other vif interfaces and those
who already have a static IP assigned to them), obviously causing the
machine to lose connectivity, as it gets 169.254.x.y autoassigned IPs
on those interfaces. Is this intended, or is is a bug?

None of these issues occur with xen-4.0

Has anyone else experienced such things with xen-4.1? At the moment
I've reverted to xen-4.0 using some older ebuilds in order to keep the
machine in a working state, but I am willing to do more tests in the
following days, if anyone wants to help me debug these things.

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


 


Rackspace

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