This can be used to enable ‘MSCS’ in a box, in a lab scenario, or any other sort of setup, where more than one VM will require access to the same disk. Careful here though, your file system will need to support this as well. Read on for more.
First we need to make the disk:
Log into the service console and execute the following:
[root]# vmkfstools -c 249G -d thick /vmfs/volumes/250/shared.vmdk -a lsilogic
Reading that, it tells vmkfstools to create a 249 GB disk file, in a thick file with an adaptor type of Lsi Logic. The Thick formatting is critical, as it is what enables parts of this process. *Note, under normal circumstances Thick disk files are a security risk.
Next we add it to the VM’s
Use a new, unused SCSI Adaptor:
There are our devices, make sure the adaptor is in Physical mode:
Hope this was helpful. Please leave any questions or thoughts in the comments.
21 thoughts on “Share and Share Alike – Sharing VMDK’s Between Virtual Machines”
Really helpful… I was searching all over town for this info.
Tis why we're here!
really helpful dude.. no doubt about it.. thanks for sharing this info!!!
Was very helpful. A good insight. Tnx!
I would just say one thing to you and that is, “FANTASTIC”!! Keep it up and wish to get more details from your blog.
Cool. Thanks for reading.
Cool. Thanks for reading.
I noticed this does not seem to work for vSphere, when I add the disk I get an error on the second machine saying “Failed to power on scsi0:1. Failed to add disk scsi0:1. Any ideas?
I'll give this a revisit shortly then. Thanks for hanging in there.
Thanks for your inputs. I have tried this and could add the VMDK to both the VMs. But only one VM is powering up. Other one halts throughing error that the file is locked. Any work around to come out of this.
I am not configuring any MSCS in these VMs. Is there any way can achieve the disk sharing without MSCS. I tried with the RDM, it works but the data is not getting synchronised. Means if the VM1 is creating any files to the shared drive it is not visiable to the VM2 unless the VM is rebooted.
For 'file sharing' or so, you will need to ensure you are using a cluster
aware filesystem. NTFS is not generally, and requires MSCS to make this
happen. As far as the file being locked or so, go back and double check the
settings on both VMs are identical (scsi controller, port mode, etc).
Here are my notes on doing this in 4.1 (from vague memory):
1. You can do it all in vSphere with no CLI. Make sure to tick the options for thick provisioning and supporting fault tolerance when creating the disk.
2. For Windows 2008 Failover Clustering, the disk needs to be on a LSI Logic SAS controller. You won’t see this controller type unless the VM’s hardware version is 7 (or at least, hardware version 5 doesn’t have it).
3. The procedure for adding a SCSI controller to a VM in vSphere can be somewhat unintuitive and AFAIK can’t be done directly. If you need to add a controller, when you add the disk, simply give it a SCSI ID on a different bus, and ESX will add a controller for you. For example, if the VM’s one existing disk is on an LSI Logic Parallel controller and has an ID of 0:1, and you want to add another disk that supports Failover Clustering, give it an ID of x:y, where x is 1, 2, or 3.
4. You might need to manually change the controller type of the controller that ESX added for you. I think it defaulted to something other than SAS when I did this.
5. Some of this seems to be order-dependent. For example, I created a disk with a different controller type and was getting errors about persistent reservations failing during cluster validation. I upgraded the VM’s hardware version and converted the controller to SAS and rebooted the VMs, but the errors persisted. Then I destroyed the disk and recreated it with the controller type set to SAS, and cluster validation passed.
The blog info is very helpful.Thanks.
In the command “vmkfstools -c 249G -d thick /vmfs/volumes/250/shared.vmdk -a lsilogic” the “thick” option is not available on the ESX.It is either zeroedthick or eagerzeroedthick
The adapter setting can also be virtual mode
Hi im also having difficulties for configuring synchronization of a shared drive between VMs. I have to reboot the VM only able to see the latest available files in the shared drive.
Is there any short guide you can give on how to setup from MSCS, cluster aware filesystem etc to make the shared drive synchronize changes immediately and visible to the VMs?
It’s been ages since I’ve looked. I will however post around to see if we can get you some help.
NTFS is not cluster-aware. Only one host can access a filesystem at a specific time. You can’t use NTFS as a cluster filesystem accessed by a number of nodes at the same time. A MSCS is suitable for a HA cluster, but even in this case only one node has access to the disks. If a failover occures, the other node will get access to the disks. This behaviour is not VMware specific. You will face this problem on bare-metal too.
I recall using this guide when setting up a cluster in a box (or on one host): http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-50-mscs-guide.pdf. Don’t recall encountering any issues. In my experience with MSCS (whether virtual or physical), only one node at a time (ie what you see when you’re in the OS) will be able see or have access to the files on the shared drives.
Comments are closed.