The problem was using GFS and vmware.. specifically using shared storage
devices in vmware.
Vmware allows two different modes of SCSI bus sharing: virtual, which
allows disks to be shared between guests on the same host; and physical,
which allows disks to be shared between guests on different hosts.
For our purposes, it was important to retain the ability to migrate our
guests between hosts for high availability and resource balancing, so
the SCSI bus option would have been to use a physical bus.
We found that hosts running guests with physical SCSI bus sharing ran
into SCSI reservation problems, and were unable to properly migrate
those guests, or if they did migrate the guests the SCSI reserves during
migration were problematic for the other guests in the cluster. After a
while, our vmware admin would become very frustrated about not being
able to reboot or perform maintenance on these hosts, because they owned
locked up guests trying to resolve reservation conflicts.
My memory is not serving me well, so I don't have specific case details
-- but this was the gist of the problem.
Xen allowed us a separate cluster for the virtualized GFS case, and
returned our vmware cluster to its previously faultless HA/redundant/DRS
operation.
As a side note, we recently removed Blackboard from its Xen cluster,
since we no longer needed to run our development environment on the same
hardware... so we are again.. without xen.
Ben
Stanley Brinkerhoff wrote:
Can someone remind me what the problem was with Blackboard @ UVM that
Xen solved and VMWare was not able to do? I remember something about an
iscsi volume, two servers, and not being able to access the data store
on both servers? Or such?
Stan
