On 2012-11-09 18:01, Gabriele Bulfon wrote:
The Windows PDC for CIFS resides inside a VMWare5 machine.
This PDC, has also a disk mounted via a VMWare-iScsi resource on the
storage itself.
...
There is a kind of loop in this situation, but I suspect that all the
problem started with the iScsi not responding from the storage:
- the PDC did not let me in because it was angry with the missing disk
from VMWare-iScsci. If this is the case, is it normal that a Windows
server give me no way to enter when a disk is not responding?? Or should
I just think that the PDC was freezing by itself (but in this case, I
shouldn't see iscsi time out on vmware).
Do I understand correctly that the PDC VM itself is not hosted
on this storage (i.e. the OS disk is not iSCSIed from illumos)?
Just to clarify...
If the OS disk hung (due to iSCSI), it might cause the Windows
VM to hang, like any other OS. Inaccessibility due to a non-OS
drive does seem strange... it should have been kicked off after
a timeout, I think.
- the CIFS was not responding because the PDC was timing out
That's why there should be several DCs ;)
I don't understand why the storage was not giving me the bash, though!
And, I could not find any trace of errors, logs or whatsoever about
iscsi problems.
Sometimes I had hit conditions where ZFS/ZPOOL commands began
hanging and never exiting, and holding a shell. Ultimately this
was solved by either a reboot, or (rarely) by ZFS completing its
internal housekeeping (like those deferred deletions).
If your .bashrc does something like "zfs list" or "df -k", as
I like doing on my systems to get a quick overview upon login,
this can cause the never-appearance of a shell.
Also the hanging processes can pile up and exhaust address space
or even the process table, and the OS is inaccessible due to
either no memory ("can't fork", if it is able to write that)
or to constant context swapping in-kernel to switch between
myriads of processes. For me, Solaris has survived about 10x
as many sleeping processes as Linux in similar setups, but
nothing is infinitely sturdy.
Finally, the address space could also be exhausted by something
big in /tmp or /var/run or other "swap"-based filesystems (if
your tmpfs is virtual-memory-backed, and no limit is artificially
imposed by the mount options on /tmp). This by itself might be
the cause - precluding programs from working and maybe hanging
the iSCSI server (at least, the userspace program parts).
Whatever the reason, it is likely that the storage server could
not write into its log files during the problem (i.e. syslog died)
hence no reports to be found.
HTH,
//Jim Klimov
-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com
