> [root@xensvr2 ~]# xenstore-ls /local/domain/0/backend/vbd/28/5696
> frontend = "/local/domain/28/device/vbd/5696"
> online = "1"
> params =
> state = "5"
> dev = "hdd"
> removable = "1"
> mode = "r"
> frontend-id = "28"
> type = "file"
> [root@xensvr2 ~]#
> (i think the last one it the cd-drive... it gives less data..)
Certainly looks that way. Notice the 'state = "5"'? 5 means it's in a
'closing' state, which is unusual as we should actually detect that in
the frontend. When you retrieved the above info, you hadn't tried any
hotplug events or anything had you? If not, it means that the drivers
are going through the motions of setting things up but then something is
going wrong and the backend is setting the state to 5, and waiting for
the frontend set it's state to 1 to restart things again.
Download http://www.meadowcourt.org/downloads/windbg.tgz, build it, and
follow the instructions in there to get a log of the boot messages. Let
me know if you need assistance.
> And the answer on your other question:
> "Can you tell me, during the time the DomU is 'hung' because the SAN
> disconnected, does the SAN come back online before the reboot?"
> NO, the SAN was very down... and we first shut down all the
> (and VM's) before starting up the SAN.
> BTW, another thought: The VM (with the GPLPV drivers and the BSOD i
> about) was a Mailserver, mailservers have a lot of small files (1 or2
> I've head/saw somewhere that all files under 1,5Kb are not written to
> disk but to the MFT directly because making a pointer in the MFT to
> address on the disk where the (small) file is, is too much overhead.
> maybe the fact that this server is a mailserver with small files,
> in getting the MFT down.
Interesting... I wonder if an 'xm destroy' during some sort of disk
activity would be sufficient for me to reproduce the same effect as the
SAN disconnecting. I'm not sure exactly what I'd be looking for though.
Xen-users mailing list