opps just noticed my typo, Obviously I meant 2003
I'd be very reticent about putting those into production as they will be doubly unsupported
I do not know why VMware changed the requirements for clustered
VMs so that the OS disk must be on local storage
What do you mean? That a VM's image cannot be stored on a SAN?
I hope not. This change makes VMware useless for us.
Boot disk for VM must be on local storage. They didn't just change this for ESX 3.x, it was also changed for 2.5.x as well. Remember Works and Supported are too different things.
Caveats and Restrictions /b
This section summarizes caveats and restrictions. The software listed as supported has been tested by VMware. Other software has not been tested.
! Each virtual machine by default has five PCI slots available. A cluster uses four of these slots (two network adapters and two SCSI host bus adapters), leaving one PCI slot for a third network adapter (or other device), if needed.
! VMware virtual machines currently emulate only the SCSI‐2 disk reservation protocol and do not support applications using SCSI‐3 disk reservations.
! You must use 2GB FC HBAs with one of the drivers listed in the checklist. See Appendix A.
! You must use LSILogic virtual SCSI adapter.
! You must use VMXNet (not vlance).
! You can use only 32‐bit virtual machines (not 64‐bit virtual machines).
! You can use only 2‐node clustering.
! iSCSI clustering is not supported on iSCSI or NFS disks.
! The STORPort driver is not supported in the guest operating system. Only the SCSI miniport driver is supported.
! NIC teaming is not supported with clustering.
! The boot disk for the virtual machine must be stored on local storage. /b
! Boot from SAN for the ESX Server host is not supported.
! Mixed HBA environments (QLogic and Emulex) on the same host are not supported.
! Mixed environments using both ESX Server 2.5 and ESX Server 3.0 are not supported.
! Clustered virtual machines cannot be part of VMware clusters (DRS or HA).
! You cannot use VMotion on virtual machines that run cluster software.
To me there are too many restrictions, requirements, and issues to make doing MSCS on VMware worthwile, so for us if an application must be clustered with MSCS we are going with physical boxes, others may come to different conclusions, but for us this is the decision we have made.
IMO (this isn't from any insider info, just speculation) VMware isnt interested in making MSCS easy to do because they see HA as an eventual replacement for MSCS.
IMO (this isn't from any insider info, just
speculation) VMware isnt interested in making MSCS
easy to do because they see HA as an eventual
replacement for MSCS.
I disagree with this statement. HA does not provide the same level of uptime that MSCS clustering (or even VCS, Legato AAM, etc.) can. Especially if the VM either A) is powered off, or B) crashes (in which the host is still operational) VMware HA is completely useless. Now, if the host were to power off for whatever reason, then yes; VMware HA would be helpful. Only if the HA cluster didn't violate availability contstraints. But, in a situation where 99.999% Uptime for a service being hosted within a Virtual Machine, VMware HA simply cannot provide that level of uptime. Clustering at the VM level would be needed.
VI3 was supposed to support clustering VM's, and NOT needing the Public vs Share mode for the VMFS volume. Atleast this is what was stated in VMworld 2005 in the ESX 3 Advanced Storage III session. I would like to know what changed this statement to requiring the VM's OS drive be stored on the hosts local VMFS volume. And I'm not looking for the answer of "what was announced at VMworld 2005 was before the product was launched."
I have built a few VM clusters, with the OS and shared data VMDK's (both RDM and non-RDM) on the SANs VMFS volume without incident.
Boot disk for VM must be on local storage.
Okay, so does a fibre-attached SAN count as local storage?
Or must it be a SCSI-attached disk?
From the Setup for Microsoft Cluster Service doc:
This is Linux.
"Works" and "Supported" are two completely different things.
I didn't say HA was a replacement for MSCS, but what I feel is that VMware may market it as "an alternative that fits the needs of most of our customers" in the future as HA evolves (they don't intend on leaving it the way it is, in terms of functionality).
I completely understand what supported and works mean. I was simply stating another fact that a lot of other people have already stated.
You did speculate that VMware isn't going to support MSCS or fix the issue(s). They would rather sell VMware HA. I was simply stating my opinion (just like you did) that IF VMware did have such a stance, that it would be idiotic.
I firmly believe that VMware will eventually improve the capabilities of clustering VM's with products like MSCS, VCS, etc. It's just a matter of time. ESX is still in the early stages. I'm just tyring to show my support for this feature request.
No. SAN attached does not mean local storage. Local storage is the local storage that other ESX hosts do not have access to. This can be local SCSI disks, or a partition within the bootable LUN on the FC SAN if you were booting from SAN.