https://bugzilla.novell.com/show_bug.cgi?id=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c2 --- Comment #2 from Thomas Wagner 2014-04-21 15:37:00 UTC --- I am using den pvscsi module which is - as far as I know - not supported in xl in a custom build kernel. Yes - if I stop xend I can start the vm with the xl commands. -- 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=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c4 Charles Arnold changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jdouglas@suse.com |carnold@suse.com QAContact|qa-bugs@suse.de |jdouglas@suse.com --- Comment #4 from Charles Arnold 2014-04-28 14:40:18 UTC --- Maybe related to 875370 -- 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=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c6 --- Comment #6 from Dion Kant 2014-04-28 23:44:17 UTC --- I want to add a couple of remarks on the discussion about xl en xm. The problem is related to libvirtd. Since libvirtd is required to use tools like virt-manager, which is even used by Yast to setup VMs. It has to do with xl being stateless whereas xend did track state in some way. See this article: http://blog.xen.org/index.php/2014/01/17/libvirt-support-for-xens-new-libxen... As a result, when domains are started with xl, they remain invisible to tools like virt-viewer, virt-manager and virsh. Furthermore, until now, "all" SuSE documentation is/was still based on the xend tool stack. Have a look at /usr/share/doc/packages/xen/README.SuSE. Xl is not even mentioned in there. In particular I want to cite here the section on Init scripts:

Init scripts ------------ Before you can create additional VMs (or use any other xm command) xend must be running. This init script is part of the xen-tools package, and it is activated at installation time. You can (de)activate it using insserv. You can also start it manually with "rcxend start".

The deprecated xendomains script is also shipped, but disabled by default. In SLES 10 GA (xen 3.0.2) and older, this script allowed VMs to be started and stopped automatically when the machine starts and stops. In SLES 10 SP1 (xen 3.0.4) and newer, the proper way to start and stop VMs automatically is to set the "on_xend_start" and "on_xend_stop" settings in the VMs configuration. (Deprecating xendomains was necessary because xend, not the configuration file in /etc/xen/vm, is now the authoritative source for the VM's settings.) Consult the online documentation for more information.

This is really confusing since AFAIK the "on_xend_start" and the deprecation of xendomains is contradictory to using xl. -- 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=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c8 James Fehlig changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aginies@suse.com --- Comment #8 from James Fehlig 2014-04-29 02:01:00 UTC --- (In reply to comment #6)

The problem is related to libvirtd. Since libvirtd is required to use tools like virt-manager, which is even used by Yast to setup VMs.

What problem does libvirtd have? AFAIK, libvirtd is not involved in this bug.

As a result, when domains are started with xl, they remain invisible to tools like virt-viewer, virt-manager and virsh.

Right. Those are libvirt apps, not libxl apps. The libvirt libxl driver is a libxl app, as is xl. libxl is designed to allow multiple applications to manage a xen host, but one libxl app should not manipulate domains, resource pools, etc. owned by another libxl app. IMO, either use libvirt and all the apps in its ecosystem, or use xl.

Furthermore, until now, "all" SuSE documentation is/was still based on the xend tool stack. Have a look at /usr/share/doc/packages/xen/README.SuSE. Xl is not even mentioned in there.

Thanks for pointing that out. Adding Antoine so he is aware of the doc issue too. -- 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=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c10 --- Comment #10 from Dion Kant 2014-04-29 08:00:21 UTC --- To continue on fixing the issue with xend not detecting devices, some loud thinking here..... The xend based xen-tools package is renamed and continues to live under the name xen-xend-tools. The xen-tools package now brings in the xl tool stack, but also more general Xen related stuff which is required for running xend as well. There may be a conflict when installing xen-xend-tools on top of xen-tools. In /etc/xen/xl.conf I find

# default option to run hotplug scripts from xl # if disabled the old behaviour will be used, and hotplug scripts will be # launched by udev. #run_hotplug_scripts=1

which implies that hotplug scripts are currently not launched by udev. Does xend know about this? ... It would be more clear if the tool sets were packaged along the line xen-generic-tools xen-xl-tools xen-xend-tools and make xen-xl-tools more pure about xl and dito for xen-xend-tools -- 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=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c12 Thomas Wagner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|fs@suse.com | --- Comment #12 from Thomas Wagner 2014-05-03 11:12:37 UTC --- I would appreciate some hints how to solve the current issue and not starting a request about xl documentation. I know that we all have to switch to xl toolstack earlier or later. But at the moment I have really to solve this issue. I have checked udev rules. They are in place like under 12.3 release. regards Thomas -- 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=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c14 --- Comment #14 from Dion Kant 2014-05-04 14:24:24 UTC --- I have found a fix which works for me. mv /etc/udev/rules.d/40-xen.rules /etc/udev/rules.d/99-xen.rules /etc/init.d/boot.udev restart BACKGROUND INFORMATION To narrow it down to this. I raised udev_log to debug in /etc/udev/udev.conf. With running udevadm monitor --kernel --udev --property it looks like the udev events are passing by fine. However, I found that, despite /var/log/messages shows the scripts are selected for execution, they are actually *NOT* executed. Here an example for the call to /etc/xen/scripts/vif-setup 2014-05-03T21:37:36.881736+02:00 dom0-test systemd-udevd[4322]: seq 1811 queued, 'remove' 'net' 2014-05-03T21:37:36.895971+02:00 dom0-test systemd-udevd[4349]: device 0x2484fa0 filled with db file data 2014-05-03T21:37:36.896712+02:00 dom0-test systemd-udevd[4349]: RUN '/etc/xen/scripts/vif-setup offline type_if=vif' /etc/udev/rules.d/40-xen.rules:5 2014-05-03T21:37:36.897256+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11 2014-05-03T21:37:36.897796+02:00 dom0-test systemd-udevd[4349]: device 0x2473720 has devpath '/devices/xen-backend' 2014-05-03T21:37:36.898477+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' returned non-zero 2014-05-03T21:37:36.899190+02:00 dom0-test systemd-udevd[4349]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 2014-05-03T21:37:36.900052+02:00 dom0-test systemd-udevd[4349]: execute 'load' 'xen-backend:vif' 2014-05-03T21:37:36.900598+02:00 dom0-test systemd-udevd[4349]: inserted 'netbk' 2014-05-03T21:37:36.901149+02:00 dom0-test systemd-udevd[4349]: passed -1 bytes to netlink monitor 0x2482e30 2014-05-03T21:37:36.901760+02:00 dom0-test systemd-udevd[4349]: seq 1808 processed with 0 2014-05-03T21:37:36.902302+02:00 dom0-test systemd-udevd[4322]: seq 1808 done with 0 2014-05-03T21:37:36.902923+02:00 dom0-test systemd-udevd[4322]: passed 182 bytes to netlink monitor 0x24732d0 2014-05-03T21:37:36.903453+02:00 dom0-test systemd-udevd[4349]: seq 1809 running 2014-05-03T21:37:36.904162+02:00 dom0-test systemd-udevd[4349]: no db file to read /run/udev/data/+queues:rx-0: No such file or directory I did put some echo in the script (echo "Here we are" >> /tmp/xen.log) and found that the file was not created. To make a long story short, I found that the scripts *are* executed by getting the xen.rules higher in the udev rules list. So I think, in the original situation, there is some rule overriding the relevant RUN list. In the mean time I found an error thrown for /usr/lib/udev/rules.d/90-hwrng.rules: 2014-04-27T10:59:37.203487+02:00 linux systemd-udevd[324]: invalid key/value pair in file /usr/lib/udev/rules.d/90-hwrng.rules on line 1,starting at character 107 ('s') This is caused by a missing new line in the file. Please forward this issue to the right people from openSUSE. And please share with us what is the root cause of this. In the mean time I can start using xm again. Cheers, Dion -- 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=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c16 --- Comment #16 from Dion Kant 2014-05-04 16:12:00 UTC --- It looks like /usr/lib/udev/rules.d/80-drivers.rules:5 is resetting the RUN list. 2014-05-03T21:37:36.896712+02:00 dom0-test systemd-udevd[4349]: RUN '/etc/xen/scripts/vif-setup offline type_if=vif' /etc/udev/rules.d/40-xen.rules:5 2014-05-03T21:37:36.897256+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:11 2014-05-03T21:37:36.897796+02:00 dom0-test systemd-udevd[4349]: device 0x2473720 has devpath '/devices/xen-backend' 2014-05-03T21:37:36.898477+02:00 dom0-test systemd-udevd[4349]: IMPORT builtin 'hwdb' returned non-zero 2014-05-03T21:37:36.899190+02:00 dom0-test systemd-udevd[4349]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 Since in reversed order it does work: 2014-05-04T15:59:34.551076+02:00 dom0-test systemd-udevd[7856]: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5 2014-05-04T15:59:34.551635+02:00 dom0-test systemd-udevd[7856]: RUN '/usr/sbin/vif-setup online type_if=vif' /etc/udev/rules.d/99-xen.rules:4 2014-05-04T15:59:34.552207+02:00 dom0-test systemd-udevd[7856]: created db file '/run/udev/data/+xen-backend:vif-18-0' for '/devices/xen-backend/vif-18-0' 2014-05-04T15:59:34.553039+02:00 dom0-test systemd-udevd[7856]: execute 'load' 'xen-backend:vif' 2014-05-04T15:59:34.553672+02:00 dom0-test systemd-udevd[7856]: inserted 'netbk' 2014-05-04T15:59:34.554280+02:00 dom0-test systemd-udevd[7900]: starting '/usr/sbin/vif-setup online type_if=vif' 2014-05-04T15:59:34.582353+02:00 dom0-test logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0 2014-05-04T15:59:34.593038+02:00 dom0-test logger: /etc/xen/scripts/block: Writing backend/vbd/18/51712/physical-device fd:0 to xenstore. The rule /usr/lib/udev/rules.d/80-drivers.rules:5, does ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}" I would not expect that the assignment to RUN{builtin}= clears a RUN= (without a type) as well. And looking at openSUSE 12.3, indeed it follows that /usr/lib/udev/rules.d/80-drivers.rules has been changed. There IMPORT as used iso RUN: # do not edit this file, it will be overwritten on update ACTION=="remove", GOTO="drivers_end" ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", IMPORT{builtin}="kmod load tifm_sd" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", IMPORT{builtin}="kmod load tifm_ms" SUBSYSTEM=="memstick", IMPORT{builtin}="kmod load ms_block mspro_block" SUBSYSTEM=="i2o", IMPORT{builtin}="kmod load i2o_block" SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST!="[module/sg]", IMPORT{builtin}="kmod load sg" SUBSYSTEM=="module", KERNEL=="parport_pc", RUN{builtin}="kmod load ppdev" LABEL="drivers_end" Note that xl would have been broken as well in a mode where it solely relied on the hot plugging scripts. Apparently it does it a different way. Dion. -- 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=874463 https://bugzilla.novell.com/show_bug.cgi?id=874463#c18 --- Comment #18 from Dion Kant 2014-05-05 08:06:53 UTC --- In factory this has been fixed too. From there it seems the formal fix is updating /usr/lib/udev/rules.d/80-drivers.rules with: # do not edit this file, it will be overwritten on update ACTION=="remove", GOTO="drivers_end" ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", RUN{builtin}+="kmod load tifm_sd" SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", RUN{builtin}+="kmod load tifm_ms" SUBSYSTEM=="memstick", RUN{builtin}+="kmod load ms_block mspro_block" SUBSYSTEM=="i2o", RUN{builtin}+="kmod load i2o_block" SUBSYSTEM=="module", KERNEL=="parport_pc", RUN{builtin}+="kmod load ppdev" KERNEL=="mtd*ro", ENV{MTD_FTL}=="smartmedia", RUN{builtin}+="kmod load sm_ftl" LABEL="drivers_end" Every RUN{builtin}= has been replaced with RUN{builtin}+= . -- 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.