Have you ever wondered what the “state” numbers in the output of “xl block-list” (or “xm block-list”, if you’re still using the “xm” command set) mean?
root@somehost:~ # xl block-list 3 Vdev BE handle state evt-ch ring-ref BE-path 51712 0 3 4 9 8 /local/domain/0/backend/vbd/3/51712 51728 0 3 6 11 797 /local/domain/0/backend/vbd/3/51728
(sorry for the formatting – we’re talking about column 4 here, where above example has the values “4” and “6”)
Since we had a few cases where we went hunting for block device problems, when the status was “6” like for the second device above, I wanted to know where those numbers are from.
Hunting through the Xen sources, it looks like those values are Xen bus states, which are defined in their according header file “xenbus.h” (with many examples to be found online):
/* The state of either end of the Xenbus, i.e. the current communication status of initialisation across the bus. States here imply nothing about the state of the connection between the driver and the kernel's device layers. */ enum xenbus_state { XenbusStateUnknown = 0, XenbusStateInitialising = 1, XenbusStateInitWait = 2, /* Finished early initialisation, but waiting for information from the peer or hotplug scripts. */ XenbusStateInitialised = 3, /* Initialised and waiting for a connection from the peer. */ XenbusStateConnected = 4, XenbusStateClosing = 5, /* The device is being closed due to an error or an unplug event. */ XenbusStateClosed = 6, /* * Reconfiguring: The device is being reconfigured. */ XenbusStateReconfiguring = 7, XenbusStateReconfigured = 8 };
So what’s obvious (and backed by our observations) is that state “4” is the typical operation state you’d like your attached devices to be in, while “6” means the device is closed (but still present). While this does not add that much new info, it’s at least a good confirmation and gives a reference for what other states you might see will map to.