VMware Cloud Community
KDubb
Contributor
Contributor
Jump to solution

Thin/TBZ disks cannot be opened in multiwriter mode

Hi,

I have 2 VMs that I am going to setup in an MS cluster. I have created the shared quorum disk (tried both RDM, and creating a new thick disk), but I keep getting this error when I try to power on the machine. THe problem is, it is referencing the main disk in the error which is not the one I am wanting to share across servers. This disk IS in Thin, but I don't understand why that would matter since I am not asking it to be shared. I have created a new controller for each of the new disks. Does my main disk have to be Thick too even though it is not going to be shared?

Thanks.

1 Solution

Accepted Solutions
jamesbowling
VMware Employee
VMware Employee
Jump to solution

I would assume that it is a requirement from Microsoft to be considered a support configuration. Same on the VMware side. Also, is it that big of a trade-off to ZeroThick your nodes in the cluster?

If you found this at all helpful please award points by using the correct or helpful buttons! Thanks!

James B. | Blog: http://www.vSential.com | Twitter: @vSential --- If you found this helpful then please awards helpful or correct points accordingly. Thanks!

View solution in original post

Reply
0 Kudos
14 Replies
jamesbowling
VMware Employee
VMware Employee
Jump to solution

I would have a look at http://kb.vmware.com/kb/1004617

If you found this at all helpful please award points by using the correct or helpful buttons! Thanks!

James B. | Blog: http://www.vSential.com | Twitter: @vSential --- If you found this helpful then please awards helpful or correct points accordingly. Thanks!
KDubb
Contributor
Contributor
Jump to solution

Thanks. However, I don't understand why I should be forced to use Thick provisioning on my disks that are not even being clustered? These are just the disks that are holding the OS.

Reply
0 Kudos
jamesbowling
VMware Employee
VMware Employee
Jump to solution

I would assume that it is a requirement from Microsoft to be considered a support configuration. Same on the VMware side. Also, is it that big of a trade-off to ZeroThick your nodes in the cluster?

If you found this at all helpful please award points by using the correct or helpful buttons! Thanks!

James B. | Blog: http://www.vSential.com | Twitter: @vSential --- If you found this helpful then please awards helpful or correct points accordingly. Thanks!
Reply
0 Kudos
KDubb
Contributor
Contributor
Jump to solution

No, not a big trade off. I would just think it would not care what the "local" disks were confured as. I should be able to storage vmotion them back to thick. Thanks.

Reply
0 Kudos
KDubb
Contributor
Contributor
Jump to solution

I did get this to work with Thin disks on the system drive. THe SCSI controller for the system disks were set to Virtual, instead of None. Fixed that, and everything works as I need it. Thanks!

Reply
0 Kudos
jamesbowling
VMware Employee
VMware Employee
Jump to solution

Good to hear!

If you found this at all helpful please award points by using the correct or helpful buttons! Thanks!

James B. | Blog: http://www.vSential.com | Twitter: @vSential --- If you found this helpful then please awards helpful or correct points accordingly. Thanks!
Reply
0 Kudos
AlbertWT
Virtuoso
Virtuoso
Jump to solution

I have similar problem too, so the solution is to destroy the existing disk from the VCEnter and then manually create the VMDK using vmkfstool ?

my goal is to have MSCS on different ESXi hosts on my SAN using the Non Physical RDM (plain VMDK on top of the current VMFS only).

/* Please feel free to provide any comments or input you may have. */
Reply
0 Kudos
prasadsv
Enthusiast
Enthusiast
Jump to solution

Can you exactly tell how you are trying to configuring MSCS cluster.How did you share the Luns across VM's on different hosts.What is the SCSI controller Compatibility mode you selected.

Please refer to http://kb.vmware.com/kb/1004617 .

Reply
0 Kudos
AlbertWT
Virtuoso
Virtuoso
Jump to solution

Hi,

I have set theVMDK in my SAN and have also configured the Paravirtual SCSI controller with Physical compatibility mode on both nodes. With that configuration it always failed, but when I change the compatibility mode into none the VM can work as normal but the MSCS setup cannot be continued as I cannot add the VMDK on the other node.

Eventhough I have deselect Thin provisioning on the VM when I built it, somehow it is not eager zeroed thick.

Accessing the SSH console on the COS is not supported and I don’t want to do it as I could not afford to lose the support from VMware (due to me using UNSUPPORTED mode)..

/* Please feel free to provide any comments or input you may have. */
Reply
0 Kudos
prasadsv
Enthusiast
Enthusiast
Jump to solution

VMware doesnt support MSCS with Paravirtual SCSI controller.But you can still try out as mentioned in other thread :

http://communities.vmware.com/thread/314055

As you mentioned,

>> I have set theVMDK in my SAN and have also configured the Paravirtual  SCSI controller with Physical compatibility mode on both nodes. With  that configuration it always failed << ,what failure you observed.Did both the VM's failed to power on or only one VM failed to power ON.Did you observe any other errors.

Also,please check if you followed all the steps properly to configure MSCS on different ESXi hosts on SAN using the Non Physical RDM.Did you select the the compatibility mode of the Virtual disk as "Virtual".Please have a look at http://kb.vmware.com/kb/1004617  for detailed steps to configure MSCS.

Reply
0 Kudos
AlbertWT
Virtuoso
Virtuoso
Jump to solution

Prasad,

Thanks for the reply, however I just found out this article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100349...

I wonder if this configuration is supported by both Microsoft and VMware to have MSCS VM on VMDK disk ?

because in this article: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1011170 I need to have access to the COS SSH command shell, in ESXi is not supported.

/* Please feel free to provide any comments or input you may have. */
Reply
0 Kudos
prasadsv
Enthusiast
Enthusiast
Jump to solution

Albert,

This is supported but only supported if both the MSCS VM's resides on same Physical host.You can refer pages 15 to 18 in the pdf uploaded.

If you dont have access to COS SSH, you can install vCLI or vMA and get access.Follow the steps mentioned in http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100349....

Reply
0 Kudos
prasadsv
Enthusiast
Enthusiast
Jump to solution

Missed out the PDF.uploaded now Smiley Happy

Reply
0 Kudos
Julian_Milano
Contributor
Contributor
Jump to solution

I had this issue when I was migrating an already existing clustered pair of Linux nodes from one datastore to a new one on a new SAN. I had created a separate folder on my old SAN/datastore where I kept the shared disks. Interestingly, when I migrated the clustered-shared datastores using the VC client, the result was each virtual machine node on the new data store had exact copies of the shared disks, but now located with the virtual machine's vmx file- same folder. So, migrating shared clustered disks creates two copies of those disks, and places each copy in the same folder as the virtual server files. The cluster was now no longer a cluster!

I deleted one set of disks, moved the other set back into a new shared folder and re-added the new copies to the clustered virtual nodes, but I got the "Reason: Thin/TBZ disks cannot be opened in multiwriter mode" error. After much searching, I found that not only did VC create multiple copies of my clustered disks, but the copies were now zeroedthick, and thus would not work as clustered disks.


My solution was this:


VMware KB: Determining if a VMDK is zeroedthick or eagerzeroedthick


By running this command in an SSH shell, on every vmdk disk in the cluster:


vmkfstools -k "My VM.vmdk"


I managed to get it working again!

Reply
0 Kudos