[Bug 825501] New: Xen guests fail to launch on boot & shutdown fails to restart - systemd dependencies again?
https://bugzilla.novell.com/show_bug.cgi?id=825501 https://bugzilla.novell.com/show_bug.cgi?id=825501#c0 Summary: Xen guests fail to launch on boot & shutdown fails to restart - systemd dependencies again? Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: ar16@imapmail.org QAContact: qa-bugs@suse.de Found By: --- Blocker: --- Created an attachment (id=544545) --> (http://bugzilla.novell.com/attachment.cgi?id=544545) xen systemd status & dmesg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 I'm running Xen 4.3.0 on Opensuse 12.3, rpm -qa | grep -i ^xen xen-devel-4.3.0_03-251.1.x86_64 xen-4.3.0_03-251.1.x86_64 xen-tools-4.3.0_03-251.1.x86_64 xen-libs-4.3.0_03-251.1.x86_64 lsb_release -a LSB Version: n/a Distributor ID: openSUSE project Description: openSUSE 12.3 (x86_64) Release: 12.3 Codename: Dartmouth uname -rm 3.7.10-1.11-xen x86_64 I'm seeing two, new issues. I suspect, but am not yet sure, they're related to systemd dependencies, possibly as described @: Bug 809646 - systemd fails to handle the dependencies for LSB scripts https://bugzilla.novell.com/show_bug.cgi?id=809646 My specific symptoms are: (1) Xen DomUs that manually launch & function after boot are no longer launching on boot when added to /etc/xen/auto (2) System restart with `shutdown -r now` works correctly if booted to a non-Xen kernel, without Xen, but fails (the system halts, but does not restart) if booted to Xen I'd tested this system and it working without such problems ~ 2 weeks ago. I supsect, but have not yet tracked down, and update within that timeframe. General status is, ls -1 /etc/xen/auto test.cfg xl list Name ID Mem VCPUs State Time(s) Domain-0 0 1242 4 r----- 79.9 systemctl --all | grep xen xencommons.service loaded active running LSB: Start/stop xenstored and xenconsoled systemctl status xencommons.service xencommons.service - LSB: Start/stop xenstored and xenconsoled Loaded: loaded (/etc/init.d/xencommons) Active: active (running) since Mon, 2013-06-17 16:10:12 PDT; 5h 43min ago Process: 1064 ExecStart=/etc/init.d/xencommons start (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/xencommons.service ├ 1094 /usr/sbin/xenstored --pid-file /var/run/xenstored.pid ├ 1103 /usr/sbin/xenconsoled --pid-file=/var/run/xenconsoled.pid └ 1108 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/qemu-dom0.pid Jun 17 16:10:09 testsvr.loc xenstored[1094]: Checking store ... Jun 17 16:10:09 testsvr.loc xenstored[1094]: Checking store complete. Jun 17 16:10:11 testsvr.loc xencommons[1064]: Starting C xenstored... Jun 17 16:10:11 testsvr.loc xencommons[1064]: Setting domain 0 name... Jun 17 16:10:11 testsvr.loc xencommons[1064]: Starting xenconsoled... Jun 17 16:10:11 testsvr.loc xencommons[1064]: Starting QEMU as disk backend for dom0 Jun 17 16:10:12 testsvr.loc systemd[1]: Started LSB: Start/stop xenstored and xenconsoled. ps ax | grep xen 31 ? S 0:00 [xenwatch] 32 ? S 0:00 [xenbus] 1081 ? S< 0:00 [xen_pciback_wor] 1094 ? S 0:00 /usr/sbin/xenstored --pid-file /var/run/xenstored.pid 1103 ? SLl 0:00 /usr/sbin/xenconsoled --pid-file=/var/run/xenconsoled.pid 1108 ? Sl 0:01 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/qemu-dom0.pid 3808 pts/1 S+ 0:00 grep --color=auto xen xl create /etc/xen/auto/test.cfg Parsing config from /etc/xen/auto/test.cfg Daemon running with PID 3963 xl list Name ID Mem VCPUs State Time(s) Domain-0 0 1241 4 r----- 82.8 template 1 1024 2 -b---- 2.3 shutdown -r now ... fails, requires a cold restart ... xl list Name ID Mem VCPUs State Time(s) Domain-0 0 1242 4 r----- 41.7 and, output of systemctl status xencommons.service systemctl show xencommons.service systemctl status xendomains.service systemctl show xendomains.service dmesg after system boot is included in the attachment. Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c
A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c1
--- Comment #1 from Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c2
--- Comment #2 from A R
for 2), it looks like a xen kernel bug, you should fill a separate bug report.
done. "Bug 825510 - "shutdown -r now" fails @ Xen 4.3.0 Dom0 -- systems halts, but does not restart" https://bugzilla.novell.com/show_bug.cgi?id=825510
for 1): ... Are you sure your xen packages are ok ?
I'm not sure what this tells me rpm -V xen-tools S.5....T. c /etc/xen/xl.conf cat /etc/xen/xl.conf autoballoon=0 where, http://wiki.xen.org/wiki/Xen_Best_Practices If you are using the XL toolstack this can be done by editing /etc/xen/xl.conf and setting autoballoon=0. This will prevent XL from ever automatically adjusting the amount of memory assigned to dom0. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c3
--- Comment #3 from Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c4
--- Comment #4 from A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c5
--- Comment #5 from Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c6
--- Comment #6 from A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c7
Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c8
--- Comment #8 from A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c
Jason Douglas
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c9
A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c
A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c10
--- Comment #10 from Charles Arnold
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c11
--- Comment #11 from Charles Arnold
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c12
--- Comment #12 from A R
use virt-manager
I've no GUI on my servers. In any case, I'd had problems with virt-manager some time in the past; removed it, and never went back. Imo, it adds more complexity than needed --another package/daemon (aka, possible point of failure) to the Dom0, etc. For production, I simply create/edit /etc/xen/auto/foo.cfg's by hand. Nice and clean that way. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c13
Charles Arnold
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c14
A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c15
--- Comment #15 from A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c16
--- Comment #16 from A R
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c17
--- Comment #17 from Charles Arnold
'enabling' the service (should xen* inits be made *native* systemd services now that sysvinit's deprecated ?)
Yes. This is something I'm working on between other bugs. (In reply to comment #16)
adding
vi /etc/securetty ... + xvc0
This is normally set by the 'yast2 xen' program at install time. I installed an os12.3 PV guest (used defaults) and the xvc0 was there. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c18
darx suse
This is normally set by the 'yast2 xen' program at install time. I installed an os12.3 PV guest (used defaults) and the xvc0 was there.
None of my guests (started as minimal installs, then added to as needed) have ever had yast2-vm installed. Again, odd. I'd always been able to -- previously -- get to my Guest consoles. The requirements for the /etc/securetty seems to be new, or is recently being enforced. I'd suggest console functionality is a basic requirement of a Xen install. Perhaps -- to make sure this works -- moving the /etc/securetty install/modify script into Guests' "xen-tools-domU" packages, or adding a dep from xen-libs to yast2-vm pkg? In any case -- resolved here. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=825501
https://bugzilla.novell.com/show_bug.cgi?id=825501#c19
Charles Arnold
This is normally set by the 'yast2 xen' program at install time. I installed an os12.3 PV guest (used defaults) and the xvc0 was there.
None of my guests (started as minimal installs, then added to as needed) have ever had yast2-vm installed.
Again, odd. I'd always been able to -- previously -- get to my Guest consoles. The requirements for the /etc/securetty seems to be new, or is recently being enforced.
Not new but maybe something else has changed. Another option would be to automate your installs with an autoyast file and include yast2-vm with it. Thanks for your help. Closing. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com