VMware Cloud Community
frostyk
Enthusiast
Enthusiast
Jump to solution

chkdsk within a VM

Good Morning Storage VM people,

I have a SQL DB who insists on occasionally doing a scheduled reboot to do a chkdsk on the NTFS filesystem within a VM.  This takes a while and causes downtime of that VM, so I as a good infrastructure engineer am trying to think if this is really neccisary.  A lot of times I find people do things simply because that's how they did them in the physical world and never stopped to think / had the in depth knowledge to think if it is beneficial in a virtual world.

My thinking is, the NTFS file system is written to a VMDK file sitting on a VMFS file system, that in turn sits on a storage array with its own file system.  The array will take care of any bad sectors on the physical disks.  VMFS will do its thing for the datastores and vmkfstools can fix any issues there.  The NTFS filesystem is so far removed with so many layers of abstraction between it and physical disks, I question if the full check disk is required.  Sure there can be issues with the NTFS file system that do not involve issues with the physical disks that chkdisk can look for and correct, but that is a subset of what the utility scans for.

Does anyone have an intelligent commentary on if a full chkdsk is beneficial for a VM using NTFS on a VMFS datastore that is stored on a sorage array?  Or if there is an option that is a more efficient check for just NTFS issues that we might see in this situation?

Thanks.

0 Kudos
1 Solution

Accepted Solutions
daphnissov
Immortal
Immortal
Jump to solution

It's totally unnecessary to run a chkdsk on a periodic basis when the system has not experienced any abrupt power-downs. ESXi is the platform driving the writes to the backend storage, so unless ESXi crashes, your fabric has a major interruption, or the storage crashes there is no need to check the integrity of the disks. There are times when running a disk check could reveal problems, but only in those above cases. With the various levels of abstraction going on, there are multiple levels of caching that also go on in a virtualized environment, so it's actually quite hard to run into a file system corruption issue when there are no abnormal occurrences in the environment.

View solution in original post

2 Replies
daphnissov
Immortal
Immortal
Jump to solution

It's totally unnecessary to run a chkdsk on a periodic basis when the system has not experienced any abrupt power-downs. ESXi is the platform driving the writes to the backend storage, so unless ESXi crashes, your fabric has a major interruption, or the storage crashes there is no need to check the integrity of the disks. There are times when running a disk check could reveal problems, but only in those above cases. With the various levels of abstraction going on, there are multiple levels of caching that also go on in a virtualized environment, so it's actually quite hard to run into a file system corruption issue when there are no abnormal occurrences in the environment.

continuum
Immortal
Immortal
Jump to solution

> VMFS will do its thing for the datastores and vmkfstools can fix any issues there.
Wrong - there are no self-repairing features implemented in vmkfstools that are worth mentioning.
Actually it happens quite often that VMDKs can not be fixed by vmkfstools and the only option left is to clone those VMDKs either by raw tools like dd or by cloneing them with tools like ddrescue on the guest level.
So back to your original question:
If your guest OS launches chkdsk during startup you should be alarmed.
Clone that disk to a new datastore as soon as possible !!!


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

0 Kudos