We have a VM Ware ESXi virtual machine, where the guest is reporting high fragmentation. The host virtual machine file is not fragmented. The datastore is on a RAID 5 array.
Does the fragmentation of reported by the guest OS matter?
-
I suppose it could. I don't know for sure, since I'm not an expert in this, but...
The VM is running within a single large file. If you have a big file on the host allocated to the guest, from the host the file may not be fragmented. All and good.
But inside the guest, the parts within that file are being accessed all over the place, because it's fragmented within that search space. It would be like having a section of the hard disk that is getting a lot of read/write requests.
It's like having a filing cabinet where one drawer is a mess but contains all the folders S-T. Sure, it has all the right S-T folders, but you have to keep rifling through it to find what you need. Same with the host computer. The container file is one big contiguous file, but it's constantly seeking within it to find the right spot being requested by the guest.
On the other hand, I've rarely seen where fragmentation causes a big problem with access. If it's heavily fragmented, yes, it can benefit from a defrag (I liked mydefrag, personally, but there are others, plus it can run as a screen saver...) Personally, if the guest were heavily fragmented, I'd run a defragger, or run mydefrag (it was the successor to jkdefrag) periodically and it'll maintain it so it's not a chore at all.
From Bart Silverstrim -
Yes. It also matters at the host.
Like physical disk drives, virtual disks can become fragmented. Performance is weakened by fragmentation on the physical disk holding the virtual machine's working directory or virtual disk files.
First defragment inside the virtual machine. Then power off the machine, and run a defragmentation utility on the host computer.
Note that defragmenting does not reclaim unused space on a virtual disk; to reclaim unused space, shrink the disk.
It is strongly recommended that you defragment using a guest operating system mechanism before taking the first snapshot (or linked clone).
Workstation makes all its changes to the redo log, not to the original disk, when you run a defragmenting program on the guest after a snapshot. You lose the ability to defragment inside the original disk forever.
Every sector that moves is copied to the redo log, making the virtual machine redo log extremely large when the disk is heavily fragmented and you run defragmentation after a snapshot.
Chopper3 : I'm sorry but you're wrong with this, he's talking about ESX/i, not Workstation or Server that relies on Windows or Linux to manage the underlying file system. Fragmentation matters to the Guest, not the Host, host-based .vmdk fragmentation can very occasionally occur if thin provisioning is used but if it's not then all Guest disk allocation occurs at time of .vmdk creation - once the Guest OS gets hold of it, partitions it, formats it and starts writing then of course the Guest can fragment it as much as it likes but that will only significantly affect that Guest - NOT the host.Chopper3 : You're also wrong about the snapshotting mechanisms - you should drop all snapshots before defragmenting the Guest so as not to place unnecessary load on the snapshotting process. I also don't have the first clue what you're on about saying you lose the ability to defragment forever for some reason. In fact there's almost nothing in your answer that makes any sense whatsoever. -
It will slow down your Guest, and only significantly your Guest, in the same manner as it would if your server was physical. If the datastore is particularly overused by VMs (say >10-15) and they were very IO intensive then it could make a tiny difference but it's unlikely.
From Chopper3 -
If your VM is on local raid 5 storage, go ahead and defragment. But if it is on shared storage of any sophistication (SAN or NAS), talk to your storage guys first. There may be thin provisioning or deduplication going on at a layer VMware doesn't know about, and defragmenting can make the VM use a lot more space or even perform worse.
Also, if this is ESXi version 4, and the virtual disk is thin provisioned at the VMware layer (even on local storage), defragmenting will make the VMDK use more space as new blocks are written. This could also permanently slow things down by fragmenting the VMDK file on the VMFS layer as newly written blocks are allocated by VMFS out-of-order from the guest's perspective. A clone or convert operation would be needed to put things right again.
Precipitous : Great point on the thin provisioning. We are using thin provision to overcommit our local storage. This particular machine is on a local RAID 5, but also have both SAN and NAS hosts -- these are not sophisticated enough to do deduplication.From rmalayter
0 comments:
Post a Comment