ams_group
asked on
VMware Configuration File Storage Best Practices
Hi,
For vSphere 4.0 Can anyone point me in the right direction for what is storage best practice for VMDK and VMX Configuration files. The main question I have is:
Is it wise to have VMDK and VMX files on a different datastore?
The reason I ask is yesterday a snapshot after replication didn't close properly so datastore ran out of space and VM went into a suspended state. What a nightmare that was since VM was on it's own 50GB datastore so there was no other VM I could migrate off to gain space.
To prevent this happening again, I thought of moving VMX files to a dedicated datastore. Are there any gotcha's to doing this?
Thanks
For vSphere 4.0 Can anyone point me in the right direction for what is storage best practice for VMDK and VMX Configuration files. The main question I have is:
Is it wise to have VMDK and VMX files on a different datastore?
The reason I ask is yesterday a snapshot after replication didn't close properly so datastore ran out of space and VM went into a suspended state. What a nightmare that was since VM was on it's own 50GB datastore so there was no other VM I could migrate off to gain space.
To prevent this happening again, I thought of moving VMX files to a dedicated datastore. Are there any gotcha's to doing this?
Thanks
ASKER
Thanks for your response and the articles. I read that one about changing the location of snapshots a few days ago but I involves turning off the virtual machine to edit the VMX file. I didn't want to cause any down time.
Since the VMX file were so small my plan was to have two Datastores for VMX files on fast storage. These would be labled LUNXX_VMX and would be 100GB each (to allow for snapshots). There are only 12 VMs that are replicated so 6 VMX files on each. These VMX files would also be backed up seprately. The VMDK files for OS drives are on LUNXX_OS with one VM per 50GB datastore. Data drives are on LUNXX_DATA (500GB) with multiple VMs on each Datastore.
If I am thinking of this correctly, since VMX files would be on the separate datastore to VMDK, there should be no risk of a VM outage if snapshot fills up disk space. Am I correct in suggesting the VMX file is not critical to the running of a VM and just holds config information only? Also, are snapshots always created where the VMX file is?
Thanks and look forward to hearing your thoughts.
Since the VMX file were so small my plan was to have two Datastores for VMX files on fast storage. These would be labled LUNXX_VMX and would be 100GB each (to allow for snapshots). There are only 12 VMs that are replicated so 6 VMX files on each. These VMX files would also be backed up seprately. The VMDK files for OS drives are on LUNXX_OS with one VM per 50GB datastore. Data drives are on LUNXX_DATA (500GB) with multiple VMs on each Datastore.
If I am thinking of this correctly, since VMX files would be on the separate datastore to VMDK, there should be no risk of a VM outage if snapshot fills up disk space. Am I correct in suggesting the VMX file is not critical to the running of a VM and just holds config information only? Also, are snapshots always created where the VMX file is?
Thanks and look forward to hearing your thoughts.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok thanks.. We do not leave VMs running on snapshots and it's our over-night replication software vRanger that uses snapshots to ensure a consistent replica image in our DR site. A couple of times it has failed to commit the snapshot and the datastore quickly fills up.
Thought I'd do a test and migrated a test server configuration file to my VMX datastore and created a test snapshot. The Snapshot went on the VMX datastore. The SWAP files was here too so will need to make datastore bigger to allow for this.
On another note, for the VM that had issues last week I cannot migrate to another datastore while powered on. It says the VM is in "linked clone mode". In snapshot manager it shows no snapshots also. Do you know how to get a VM out of linked clone mode?
[root@ESX3 ~]# vmware-cmd /vmfs/volumes/4f87a35c-4ab bf28d-c68e -001e4ffce 634/SV-SQL REPORT/SV- SQLREPORT. vmx hassnapshot
hassnapshot() = 0
Thanks
Thought I'd do a test and migrated a test server configuration file to my VMX datastore and created a test snapshot. The Snapshot went on the VMX datastore. The SWAP files was here too so will need to make datastore bigger to allow for this.
On another note, for the VM that had issues last week I cannot migrate to another datastore while powered on. It says the VM is in "linked clone mode". In snapshot manager it shows no snapshots also. Do you know how to get a VM out of linked clone mode?
[root@ESX3 ~]# vmware-cmd /vmfs/volumes/4f87a35c-4ab
hassnapshot() = 0
Thanks
Okay, if your snapshots are being used for this purpose, that's okay, Most Third Party Backup software uses Snapshots in this way.
It's best if we deal with the linked clone issues, under a different question.
It's best if we deal with the linked clone issues, under a different question.
ASKER
Ok thanks, VMX files are now on separate datastore to VMDK so that snapshots created by 3rd party replication software can't cause the disk with VMDK files to fill up resulting in an outage.
Working well so far. Also resolved linked clone problem by creating a snapshot then deleting all snapshots. Must've been a uncommited snapshot causing the issue.
Working well so far. Also resolved linked clone problem by creating a snapshot then deleting all snapshots. Must've been a uncommited snapshot causing the issue.
It's really best practice to keep them together, or ensure you have good documentation so you know which datastores the VMX and VMDK (virtual disks) reside on.
You can create a dedicated fast datastore for the snapshots, so the snapshots can be on a different datastore.
see here
http://kb.vmware.com/kb/1002929
Always ensure that your datastores are 20% free, to allow for snapshots.
Also see my other articles
HOW TO: VMware Snapshots :- Be Patient