Machines incorrectly identified as Xen PV DomU

[halfgaar]

Some of my machines are incorrectly labelled as Xen PV DomU. A dmesg on 'xen' is too unstable. My servers match on:

[    2.184425] serial8250: skipping TxEn test for device [8086:108f] subsystem [8086:0000]

Patch:

--- core.py.org 2013-10-15 10:29:17.000000000 +0200
+++ core.py     2013-10-15 10:30:19.000000000 +0200
@@ -525,7 +525,7 @@
                 # Tested on Fedora 10 / 2.6.27.30-170.2.82 with xen
                 # Tested on Fedora 15 / 2.6.41.4-1 without running xen
                 elif isdir('/sys/bus/xen'):
-                    if 'xen' in __salt__['cmd.run']('dmesg').lower():
+                    if 'xen:' in __salt__['cmd.run']('dmesg').lower():
                         grains['virtual_subtype'] = 'Xen PV DomU'
                     elif os.listdir('/sys/bus/xen/drivers'):
                         # An actual DomU will have several drivers

However, this is not 100% safe. One of my xen Dom0's has its dmesg queue filled up, and dmesg |grep -i xen doesn't yield anything. This is a 'plague' in my Dom0's, because the xen-create-image scripts add some deprecated iptables rule, and dmesg is filled with:

[7894628.107651] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.

This is not an issue on a DomU, but the dmesg queue can still fill up, of course.

[basepi]

Hrm, I'm not familiar enough with xen to really be useful on this one. Is there a way to make it 100% safe?

In any case, it sounds like you should submit that patch as a pull req!

[halfgaar]

Made pull request: #8161