VMware: Error on boot of VM: ESX server cannot open the virtual disk for clustering. Reason: Thin/TBZ disks cannot to opened in multiwrite mode
Last Update: 30 Jan 2009
Today it has been the first time for a long time, that I ran into a VMware problem which caused me to sweat a bit, where I did not really know what to do. This is a workaround for anyone who might get into the same problem as I was today.
First of all: The environment:
- ESX 3.5.0, build 123630
- All VM's on local disk (it is a test environment)
- Two VM's (VM1, VM2) using three shared virtual disks (LSI Logic SCSI Bus Sharing set to Virtual)
- Both VM's are running Windows Server 2003
How I got into problems
One of the disks shared between VM1 and VM2 had a size of 5GB but I needed a bigger size. So I turned both VMs down and increased the size of the affected disk to 9GB. VI Client commited my changes once I left the 'Edit Settings' of the VM by pressing OK. I wanted to start the VMs but here I got the shock. I received the following error message:
Vmware ESX server cannot open the virtual disk
"vmfs/volumes/.../vm1/vm1_2.vmdk" for clustering, please verify thatthe virtual disk was created using the 'thick' option.
cannot open the disk '/vmfs/volumes/.../vm1/vm1_2.vmdk' or one of the snapshot disks it depends on.
Reason: Thin/TBZ disks cannot to opened in multiwrite mode.
I did not change any settings but obviously, by changing the size of the vmdk diskfile, VMware touched the disktype and now it is not a 'thick' vmdk disk anymore. Ouch! Seems to be a bug to me. But we have to find a solution anyway.
The workaround solution
- Open 'Edit Settings' for VM1 (the one in which folder the vmdk file is stored)
- Select the affected disk which size you changed
- On the right side change the value of 'Virtual Device Node' so that you connect this disk with the same SCSI Controller as the main (system) disk -> SCSI 0:x usually
- Press OK so the changes are commited
- Boot (Start) VM1 and verify in Windows that you are able to see the files of the disk
- Shutdown VM1
- Now you have to create a new virtual disk in thick format. ATTENTION! You cannot do that in the VI Client, do not ask me why, you must do it in the commandline on the ESX server. Connect to your ESX server by SSH now and change to the affected VM's folder, in this case: /vmfs/volumes/.../vm1/
- Create a new virtual disk in thick format with the following command:
vmkfstools -c 9g -a lsilogic -d thick vm1_newthick.vmdk
- This will create a new vmdk file with a size of 9GB
- Go back to VI Client and open once more the 'Edit Settings' of VM1
- Click 'Add...' -> 'Hard Disk' -> Use an existing virtual disk -> Select the before created new disk -> Set the SCSI Bus Path that you use the SCSI Controller for virtual disks (sharing)
- Commit the changes by pressing 'OK'
- Boot VM1
- In Windows open Disk Management -> Initialize the new disk -> Make a NTFS partition
- Copy all files from the original to the new disk
- Change the drive letter for the original disk to another letter (i.e. s:->t:)
- Change the drive letter for the new disk to the one the original disk used before (s:)
- Restart VM1 (in Windows)
- Verify if everything is ok, the new disk has now the original drive letter, files copied, and so on
- Shutdown VM1
- In VI Client click 'Edit Settings' of VM1 and remove the old disk (vm1_2.vmdk) -> select remove from virtual machine, NOT delete from disk. Commit with OK
- Click 'Edit Settings' of VM2 and remove the affected shared disk (vm1_2.vmdk) -> also remove from virtual machine and then click OK
- Once more 'Edit Settings' of VM2 and click 'Add...' -> 'Hard Disk' -> Use an existing virtual disk -> Select the before created new disk -> Set the SCSI Bus Path that you use the SCSI Controller for virtual disks (sharing)
- Boot VM2
- In Windows verify if the new disk is well available, check the driver letter (change it to the correct one if not), check if files are available
- In VI Client boot VM1
- Verify in Windows of both VMs if everything is ok
- After that you can erase the old disk (vm1_2.vmdk) from the ESX server via commandline
AWS Android Ansible Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Consul Container Containers CouchDB DB DNS Database Databases Docker ELK ElasticSearch Elasticsearch Filebeat FreeBSD GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Icingaweb2 InfluxDB Internet Java Kibana Kubernetes LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Rancher SSL Security Shell SmartOS Solaris Surveillance SystemD TLS Tomcat Ubuntu Unix VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder