Results 1 to 7 of 7
  1. #1
    Lounge VIP
    Join Date
    Apr 2011
    Location
    Scotland
    Posts
    1,168
    Thanks
    44
    Thanked 134 Times in 115 Posts

    De-frag of a VM?

    Here's a question that has intrigued me for a while:

    Is it best practice to defrag a virtualised hard drive?

    In my case, the host drive running on a Windows 7 platform is regularly defragged, so the virtual hard drive container (vdi file) is contiguous, but within the guest OS, the hard drives appear quite badly fragmented: enough to severely affect performance if it were running on a native drive.

    However, I see no appreciable real-world hit in performance of the virtual OS.

    Here's a screenshot of a virtual XP: the data contained on the virtual hard drive is non-contiguous, but the virtual drive will be contiguous as seen from the host platform.

    fragmetnation on a virtual drive.JPG

    Whenever I've looked for info on this, I find blogs and fora that indicate how to defrag a virtual disk, but few express any opinion as to whether it is worthwhile.

    Any thoughts?

  2. #2
    Lounger
    Join Date
    Dec 2009
    Location
    Leiden, Netherlands
    Posts
    30
    Thanks
    2
    Thanked 4 Times in 2 Posts
    Hi,

    defragging your VM's partitions is in general a good idea, the guest OS will need to access different parts of the VDI file to read a non-contiguous file, so there is a payload for the Host OS to access different parts of the VDI file.
    However, check with the VM supplier which procedure is best.
    VMWare has some info here: http://www.vmware.com/support/ws55/d...sk_defrag.html, which outlines an extra step to be done after defragging from within the VM.
    Other manufacturers might have different procedures.

    Kind regards, Eelco
    - Eelco

    *** Puzzle me! ***

  3. #3
    Lounge VIP
    Join Date
    Apr 2011
    Location
    Scotland
    Posts
    1,168
    Thanks
    44
    Thanked 134 Times in 115 Posts
    Thanks Eelco,

    can you comment on what the second stage of the process described in the VMWare article is doing? I can understand the defrag inside the vitual OS and in the native OS, but the second stage suggests the VMware player is doing something.

    If the host VDI file is contiguous, I would have expected the overhead for the read time of physical disk will be minimal because - so any reduction in performance arises from how the VM technology reads data from within the VDI file.

    If that assumption is valid, and the virtual hard drive implementation is good, it might explain why I see little degradation in performance.

    Incidentally, I use Virtual Box and the Vbox forums don't have much info on this other than to say that, for the most part, the method for implementing the VDI files overcomes guest fragmentation. There is some discussion about guest OS fragmentation increasing the size of a dynamically allocated host file. Perhaps this is something that the second stage of the VMWare process is cleaning up?

  4. #4
    WS Lounge VIP
    Join Date
    Dec 2009
    Location
    Earth
    Posts
    8,191
    Thanks
    48
    Thanked 986 Times in 916 Posts
    I don't see much point in defragmenting physical drives, let alone virtual ones.
    The disk sub-system in a virtual system is likely to have so much performance relative to a physical drive that you are unlikely to notice any difference. Performance issues are most likely to occur because you have 50 machines accessing the disk sub-system simultaneously, not from fragmentation of a single machine vdisk.

    cheers, Paul

  5. #5
    Lounger
    Join Date
    Dec 2009
    Location
    Leiden, Netherlands
    Posts
    30
    Thanks
    2
    Thanked 4 Times in 2 Posts
    Hi Tinto,

    I do not have the knowledge on the precise inner workings of VMWare, but I see it like comparing disk device storage with NAS (Network Attached Storage) storage.

    For a disk device, these are the rules for accessing data:
    The OS can address sectors on the disk device, and multiple sectors are linked to form files (using FAT, NTFS or any other file system).
    These sectors for a single file can be located anywhere on the device, but their address is fixed on the device (Their address is like: Head 2, Cylinder 20, Sector 4)
    As a note: To be true, there *is* a function in the disk device's hardware to re-map bad sectors to reserved sectors, but for the OS that is addressing the disk device, this information is hidden.

    I have made some terms bold here to clarify the different components: The Host OS, The Host VM provider and the Guest OS.

    NAS is based on files (like a file server). You can only address files, and inside those files, you can specify byte offsets to the data that you want to address. The Host VM provider needs to use this technique to emulate a disk device inside a VDI file.

    The Host OS uses the file system's sector approach to provide files to the Host OS, which are used by the Host's VM provider.
    The Guest OS internally also uses a file system's sector approach, but the Host VM provider translated these to addresses in a file-based system on the Host OS (the vdi file).
    Due to this mapping, the "sectors" for the Guest OS's "disk" may seem to have contiguous "addresses" after a defrag inside the Guest OS (to the Guest OS), but the VM Host provider can still have these mapped to any location in the VDI file, their location is not guaranteed to be related to their "address".

    Thus, defragmenting a Guest OS's disk makes sure that the data inside the guest's files are stored in sequential "sectors", this however does not make them stored in a sequential arrangement in the VM Host provider's VDI file.
    For that reason, the VM Host provider needs to re-arrange the data inside the VDI file (with the Guest OS offline ) to write all sectors in a sequential arrangement.

    This can require as much extra free space on the VM Host as the entire VDI file (as noted in the VMWare page).

    The scheme above also explains why a heavily defragmented Guest OS's disk does not need to perform badly: The underlying mapping can still make sure that the sectors for a Guest OS's file are physically located in a sequence in the VDI file, but still with non-sequential sector addresses for the Guest OS.
    It just depends on how much effort the VM Host provider makes to guarantee sequential storage.

    I hope this makes it a bit more clear.
    - Eelco

    *** Puzzle me! ***

  6. The Following 2 Users Say Thank You to enjoy For This Useful Post:

    petesmst (2012-04-17),Tinto Tech (2012-04-13)

  7. #6
    Lounge VIP
    Join Date
    Apr 2011
    Location
    Scotland
    Posts
    1,168
    Thanks
    44
    Thanked 134 Times in 115 Posts
    Quote Originally Posted by enjoy View Post
    Thus, defragmenting a Guest OS's disk makes sure that the data inside the guest's files are stored in sequential "sectors", this however does not make them stored in a sequential arrangement in the VM Host provider's VDI file.
    For that reason, the VM Host provider needs to re-arrange the data inside the VDI file (with the Guest OS offline ) to write all sectors in a sequential arrangement.

    This can require as much extra free space on the VM Host as the entire VDI file (as noted in the VMWare page).

    The scheme above also explains why a heavily defragmented Guest OS's disk does not need to perform badly: The underlying mapping can still make sure that the sectors for a Guest OS's file are physically located in a sequence in the VDI file, but still with non-sequential sector addresses for the Guest OS.
    It just depends on how much effort the VM Host provider makes to guarantee sequential storage.
    Excellent Eleco thanks for the clarification.

    So, the guest OS defrags the virtual disk that it can see; the host OS defrags the physical disk, but the virtual platform manages the arrangement or "mapping" of the data in host vdi file.

    The data arrangement inside the vdi file needs to be efficient, regardless of host or guest fragmentation.

    I think this explains why fragmentation seen from inside the VM has little or no impact on the performance of the VM and is what I think Paul was saying.

    If I have got that correct, I need not worry about the fragmentation of the virtual drive as seen from inside the guest OS. If there is an optimisation process launched from VirtualBox on the host, it may be used to maintain performance.

  8. #7
    WS Lounge VIP
    Join Date
    Dec 2009
    Location
    Earth
    Posts
    8,191
    Thanks
    48
    Thanked 986 Times in 916 Posts
    Most disk sub-systems will have routines to defragment the drives, but there is always a performance penalty when they run. If you need the system up 24/7 you may find it's better to live with fragmentation.

    cheers, Paul

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •