Troy Dawson wrote:
Jan Kundrát wrote:
Hi,
today I've upgraded my SL5 x86 box. This update looks like this in the logs:
Dec 04 14:49:41 Installed: kernel-devel.i686 2.6.18-53.1.4.el5
Dec 04 14:49:41 Updated: ipw3945-firmware.noarch 1.14.2-1.sl5
Dec 04 14:49:42 Updated: kernel-headers.i386 2.6.18-53.1.4.el5
Dec 04 14:49:51 Installed: kernel.i686 2.6.18-53.1.4.el5
Dec 04 14:49:59 Installed: kernel-xen.i686 2.6.18-53.1.4.el5
Then I removed package kernel (not kernel-xen) as this box is really
supposed to act as Xen dom0 and I don't want to check grub.conf after
each upgrade of (to us unimportant) kernel package. I've also changed
grub.conf to boot new Xen and new kernel.
After a reboot, xend didn't come up. In the xend debug log, I see this
Python backtrace:
[2007-12-04 16:20:25 xend 3351] ERROR (SrvDaemon:297) Exception starting
xend ((13, 'Permission denied'))
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line 291, in run
servers = SrvServer.create()
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvServer.py",
line 108, in create
root.putChild('xend', SrvRoot())
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvRoot.py",
line 40, in __init__
self.get(name)
File "/usr/lib/python2.4/site-packages/xen/web/SrvDir.py", line 82, in get
val = val.getobj()
File "/usr/lib/python2.4/site-packages/xen/web/SrvDir.py", line 52, in
getobj
self.obj = klassobj()
File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py", line
39, in __init__
self.xd = XendDomain.instance()
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
655, in instance
inst.init()
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
76, in init
self._add_domain(
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomain.py", line
139, in xen_domains
domlist = xc.domain_getinfo()
Error: (13, 'Permission denied')
In addition, there's a recommendation to rebuild Xen user-space tools in
the xend log.
Reverting to older records (2.6.18-8.1.15.el5xen) in grub.conf makes
everything work again, that's why I assume that package "xen" should be
rebuilt to match kernel-xen's patchlevel.
I'd use Bugzilla for this kind of issues but I wasn't able to find out
how to register there :).
Cheers,
-jkt
Hi,
Thanks for reporting this.
I guess with all the automount/samba issues we forgot to look at how this
kernel interfaces with xen.
The options I see are to either fix the old xen to work with the new kernel, or
to update the xen in SL 5.0 to match the xen in SL 5.1.
Personally, after using the xen on SL 5.1, my vote it to move 5.0 up to that
version of xen. It fixes *alot* of the bugs and troubles I was having on xen.
But I don't know how that is going to affect SL 5.0 machines that are
currently running xen. But, by pushing out that kernel, we've aready affected
them.
I'm going to be testing a bunch of things, but while I am, any ideas or
preferences?
Troy
OK, so it looks like the *minimal* we need to push out with this kernel update
is
xen
xen-libs
xen-devel
But what about just pushing out the libvirt as well and just be done with it.
libvirt
libvirt-python
python-virtinst
virt-manager
dnsmasq
dnsmasq is because with the new xen and libvirt, you can now have your virtual
machines on your own local-to-the-machine private subnet.
Is anyone going to be upset by this if libvirt makes it's way into security
errata?
Troy
--
__________________________________________________
Troy Dawson [EMAIL PROTECTED] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
