[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] GPLPV (9.11pre20) in Win2003 x64onXenServerEnterprise 5.0 (CD drive missing)


  • To: "Roel Broersma" <roel@xxxxxxxxxx>, <xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Sun, 16 Nov 2008 09:26:12 +1100
  • Cc:
  • Delivery-date: Sat, 15 Nov 2008 14:27:30 -0800
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AclHJs3qpmr4U4jHQoGYI0W1PsxzAAASWjuQ
  • Thread-topic: [Xen-users] GPLPV (9.11pre20) in Win2003 x64onXenServerEnterprise 5.0 (CD drive missing)

> [root@xensvr2 ~]# xenstore-ls /local/domain/0/backend/vbd/28/5696
> frontend = "/local/domain/28/device/vbd/5696"
> online = "1"
> params =
> "/var/run/sr-mount/7d66b2a3-3e7f-7718-db04-76ba3a57d0c5/en_win_sr\..."
> 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
has
> disconnected, does the SAN come back online before the reboot?"
> NO, the SAN was very down...   and we first shut down all the
Xenservers
> (and VM's) before starting up the SAN.
> BTW, another thought:  The VM (with the GPLPV drivers and the BSOD i
told
> about) was a Mailserver, mailservers have a lot of small files (1 or2
Kb).
> I've head/saw somewhere that all files under 1,5Kb are not written to
the
> disk but to the MFT directly because making a pointer in the MFT to
the
> address on the disk where the (small) file is, is too much overhead.
So,
> maybe the fact that this server is a mailserver with small files,
'helped'
> 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.

James

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.