[Xen-users] Working with Fedora 15 & systemd

[jim burns <jim_burn@xxxxxxxxxxxxx>]

If you are interested in replying, pls CC: me, as I am not subscribed to the 
list.

Since upgrading to F15, I have been unable to start my hvm winxp guest.

The default kernel after a yum update is 2.6.38.6-27.fc15.x86_64. 2.6.38 would 
not be expected to start a guest, since it has no net and block backends. 
However, I found that the boot process hung around the time that the desktop 
was about to be started. Adding either '3' or 'nomodeset' to the end of the 
'module' line for the kernel in grub.conf allows booting to complete. However, 
I find that '3' is preferable to 'nomodeset', as the console blanks, and 
becomes unusable with 'nomodeset'. '3' of course doesn't even try to start the 
desktop, but doesn't affect the fedora 'vncserver' service.

Once started up, as expected, starting my winxp guest resulted in a complaint 
about not being able to start a block device. (Yeah, I saw Fajar's tip about 
using http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git in the '[Xen-
users] kernel-2.6.39' thread this month. Thanx.)

I have been using xen on fedora since f7; first with their xenified kernels 
even into f9, then with jeremy's git, then settling on myoung's prebuilt dom0, 
which has been stuck on 2.6.32 for some time now. That isn't a problem for 
device drivers for me, but presents major headaches with using fedora's new 
replacement for init/upstart, called systemd, which relies heavily on cgroups. 
Apparently, myoung's 2.6.32 doesn't setup cgroups the way 2.6.38 does, if at 
all.

Systemd starts all service required sockets first, then automatically starts a 
service when the socket receives input. It also starts all 'chkconfig' 
configured services for your runlevel in parallel, with appropriate 
dependencies so that a service doesn't start till the services it depends on 
have started. This means that services may not start up in exactly the same 
order that you are used to on previous fedoras based on their rc.d priority 
numbers. That makes debugging what went wrong when your boot hangs difficult. 
I tried disabling the last few services that printed on the console, and it 
always seemed to hang at something beyond the last service that printed on the 
console. After a long time, you would get messages about avahi failing, then 
the network service itself, which wouldn't make for a very usable system even 
if it had finished booting. Apparently systemd's dependency based service 
starting was hanging somewhere, and no amount of placing debug msgs in various 
services was helping.

I also noticed under 2.6.38 that /var/log/messages was not being logged to. 
Only the console was getting the syslog, which at least in runlevel 3 was not 
being obscured by a desktop. Finally, in annoyance, I reverted to using the 
previous logger on my system, rsyslog, with 'chkconfig rsyslog on'. This, 
interestingly enough, passed the request to systemd, and converted the request 
to 'rm'-ing the existing logging service in /etc/systemd, and copying the ones 
for rsyslog from /lib/systemd to /etc/systemd. (I believe the way to revert to 
the default behavior is 'systemctl enable systemd-kmsg-syslogd.service',  but 
I haven't had an opportunity to try it yet.)

Lo and behold, the next boot into 2.6.32 completed successfully, and without 
having to disable runlevel 5. You get a bunch of errors in dmesg(1) about 
systemd-{kmsg-syslogd,logger}.service not starting, and a bunch of errors on 
the boot console corresponding to the time those services don't start 
referring to cgroups. (Things go by much more quickly on the boot console with 
systemd than you may be used to!) Apparently, those services are more 
sensitive to cgroups not being setup by 2.6.32. Systemd itself is still 
running, starting and stopping services dynamically as needed.

Now, tho', I still can't start my winxp vm. Qemu-dm-winxp.log complains, 
sometimes repeatedly, about:

xen be: console-0: xen be: console-0: initialise() failed
initialise() failed

and xend.log simply informs me that the domain rebooted, and restarting has 
been disabled to prevent loops.

F15 updates xen to 4.1.0.

Some other minor irritants: For some reason, the tun kernel module is not 
being loaded automatically. Nothing in /etc/{udev,modprobe.d} would suggest 
why. I just load it in /etc/rc.modules. And don't even get me started on 
selinux - it's gong crazy. It's like they ripped all the rules for xen out of 
selinux. This is the first fedora release that is actively hostile to xen, as 
opposed to indifferent to it, since F9. (Get to know audit2allow / checkmodule 
/ semodule_package / semodule - they are your friends!)

I hate major upgrades! When I upgraded my suse system to openSuSE 11.4, my 
iscsi target stopped working, and I had to learn the new way of setting it up. 
Of course, that target is where my winxp disk lives!

Oh well, hope this helps people to know what to expect on F15, and maybe 
someone will come up with a workaround, or myoung will update his 
configuration to run on F15.

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