Description of problem: There is no state for a device in the Xen world: /sys/block/sd*/device/state [root@taft-03 device]# cat /sys/block/sdd/device/state running We (storage QA) use this for device failure testing.
I'm going to go ahead and assume you mean paravirtualized guests here, since the dom0 should be using regular SCSI drivers (and hence, should have the state devices). With paravirtualized guests, scsi devices are sort of emulated using a ring device; as such, they aren't real SCSI devices, and don't really respond to SCSI commands as normal. That being said, having a "state" doesn't really make a lot of sense for paravirtualized guests, since for all practical purposes, they can't fail. The underlying block device in the dom0 might fail, but that is a test in the dom0, not in the domU; the domU is just at the mercy of the dom0. What exactly are you trying to test? Chris Lalancette
Corey, given the comment #1, is this still an issue?
We are trying to test lvm mirror device failures and our tests do that by toggling on and off the state of the device. We can not do that on domUs. I thought that the virtual machines were supposed to be "the same as" real machines in just about every way?
No, that's clearly not true. In terms of userland applications, for the most part, yes, there is no difference with paravirtualized guests. But for things that interact with certain parts of the kernel directly, that is not true today, and will likely never be true. Chris Lalancette
This is a kernel space issue, not userspace
Clearing TB flag...
Would it be possible to hotplug/hotunplug the disk on the host (e.g. via ssh), instead of changing the state on the guest?
Corey, what do you think about the workaround in comment #17? I did similar work for Windows drivers and it is certainly possible to do it for Linux as well, but if a workaround in the host is feasible, that would be much simpler.
Ok, closing then.