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 [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
|
