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

[Roel Broersma <roel@xxxxxxxxxx>]

Hi James, well.. about that test machine...      ;)  But at least i have lots
of feedback now:



James Harper wrote:
> 
> . send me the output of 'xenstore-ls /local/domain/<id>/device'
> (substitute <id> for the domain id of the domain in question)
> . In device manager, you should see one 'Xen Block Device Driver'
> adapter per device (disk or cdrom). For each one, can you tell me the
> value of 'Device Instance Id' in the Properties -> Details tab?
> . send me a copy of your DomU config
> . if you know how to use the windows debugger, connect that to the DomU
> and send me the output. If you don't know, then just the above stuff
> might be sufficient to get started - it may be that the XenSource
> version does things a little differently for CDROM's or something which
> I might be able to tell immediately.
> 

I did a "xe vm-list params=dom-id,name-label"  to see a list of VM's and
there IDs.
Then i did "xenstore-ls /local/domain/28/device"  which have me:

[root@xensvr2 ~]# xenstore-ls /local/domain/28/device
vbd = ""
 832 = ""
  backend = "/local/domain/0/backend/vbd/28/832"
  state = "4"
  backend-id = "0"
  device-type = "disk"
  virtual-device = "832"
  event-channel = "6"
  ring-ref = "16383"
 768 = ""
  backend = "/local/domain/0/backend/vbd/28/768"
  state = "4"
  backend-id = "0"
  device-type = "disk"
  virtual-device = "768"
  event-channel = "7"
  ring-ref = "16238"
 5632 = ""
  backend = "/local/domain/0/backend/vbd/28/5632"
  state = "4"
  backend-id = "0"
  device-type = "disk"
  virtual-device = "5632"
  event-channel = "8"
  ring-ref = "16093"
 5696 = ""
  backend = "/local/domain/0/backend/vbd/28/5696"
  state = "4"
  backend-id = "0"
  device-type = "cdrom"
  virtual-device = "5696"
  event-channel = "9"
  ring-ref = "15948"
vif = ""
 0 = ""
  backend = "/local/domain/0/backend/vif/28/0"
  backend-id = "0"
  state = "4"
  handle = "0"
  mac = "1a:87:80:a6:b9:a2"
  tx-ring-ref = "15947"
  rx-ring-ref = "15946"
  event-channel = "10"
  feature-no-csum-offload = "0"
  feature-sg = "1"
  feature-gso-tcpv4 = "1"
  request-rx-copy = "1"
  feature-rx-notify = "1"
[root@xensvr2 ~]#

I think that is the Xen equivalent of XenServer-api: "xe vbd-list params=all
vm-name-label=mailsvr1" which gives me this:  (see attached file  file1.txt)
http://www.nabble.com/file/p20515016/file1.txt file1.txt 

Driver instance IDs:
- XEN\VBD\4&32FE5319&1&5632
- XEN\VBD\4&32FE5319&1&5696
- XEN\VBD\4&32FE5319&1&768
- XEN\VBD\4&32FE5319&1&832

(btw: i have now 3 drives connected and should have 1 cd-drive connected,..
which i couldn't see)

Behavior
--------
When i hot-plug a device from the Xenserver, i can not see it in the Windows
2003 VM.  (even not after a rescan disk  or  hardware detect)   When i
reboot the VM, it will detect a new device when starting Windows. I click..
next..next.. and it adds another "Xen Block Device Driver".


Other BAD behavior
-------------------
Most of our VM's are on the SAN and connected with iSCSI to the Xenserver. 
When the shit-hits-the-fan and the SAN is going down (broken switch.. cable
broken.. or just something else)  all our Windows VM's give BSOD's.  Which
is a quite normal behavior.  99% of the time we can reboot thse VM's later
without any problems,.. very sometimes we need to run a chkdsk.  (luckily
NTFS is a journalling filesystem).
BUT:  With the GPLPV drivers.. we do NOT get a BSOD's,  i've waited 10
minutes for it.  First i see some popups: "Can't write to <filename>  or
<disk>"  and it will raise many..many popups.  Finally i did a
force-shutdown from the Xenserver.  Then when rebooting this VM, the Master
Filesystem Table (MFT) was corrupt and couldn't be repaired with chkdsk. The
were lots of errors on the drive and i had to recover some files with
"GetDataBack for NTFS".  ... a long night...   :(
I never had this with the XenServer PV-tools.   I think the GPLPV drivers
have a too large disk-cache (write cache?) or something ?  The best is too: 
freeze the OS (i've seen that on Linux) or to give a BSOD within a short
time  (Windows)... otherwise you're really screwing up things...
Just test it:  Put 5 VM's on.  4 with the Xenserver PV-tools and 1 with the
GPLPV drivers,  then pull-off the storage.  The 4 VM's are the first give a
BSOD.. and the GPLPV is probably... never.. ?
(the thing i don't understand is that when storage is completely broken, it
wouldn't matter if the VM is on for 10secs. or 10mins..  it can't write
through the storage so it can't corrupt things...    This thought let me
think about a too-big storage buffer maybe?  So a too-big piece is
missing... or journalling is not in sync.. ?)

I'm still using 9.11pre20.  I will try to find ou the Windows debugger
stuf..

Thanks for your response, i appreciate it!
-- 
View this message in context: 
http://www.nabble.com/GPLPV-%289.11pre20%29-in-Win2003-x64--on-XenServer-Enterprise-5.0-%28CD-drive-missing%29-tp20499705p20515016.html
Sent from the Xen - User mailing list archive at Nabble.com.


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