ESXi - Shrink Physical VM Files

Discussion in 'Virtualized Computing' started by mda, Mar 15, 2019.

  1. mda

    mda [H]ard|Gawd

    Messages:
    1,490
    Joined:
    Mar 23, 2011
    Hello all,

    I'd like to seek your help in shrinking the data files consumed by one VM.

    Back story:

    Implementer partitions "large" 500GB VM for a system. Realistically, 150GB is enough space for the application copied twice over + the OS.

    Implementer no longer wants to re-do this VM. They don't seem so proficient at ESXi, or RHEL anyway.

    I want to reclaim the 350GB extra space so I can use this for smaller VMs and for future use for the larger ones. I only have 2TB (realistically, it's 1.6TB when you account for swap and formatting) of space so 350GB is big for me.

    ESXi details
    Version 6.5 U2, Lenovo Customized Image

    Bloated Guest OS in Question
    Red Hat 5.8 32 bit
    Partitioned 'standard' (not LVM)
    ext3

    I can gparted the Guest OS to the point wherein the partitioned space only shows 150GB, with the 350GB as unallocated.

    However, I no longer know what to do to have ESXi shrink the actual files/disks.

    I have tried editing the VMDK file and editing the extent figures, unregistering the VM, moving the VM to another datastore.

    When I do this, the VM 'thinks' it is now the smaller file, but the physical size of the vmdk-flat file still shows the larger value. The same large value shows up when monitoring the VMs, and doing an ls -lh on the ESXi CLI.

    All the googles I've done don't really have a clear cut answer on this since the official answer is that this kind of move is is unsupported (?)

    Is there any other way I can shrink this VM?

    My experience level with ESXi - noob - I have setup a few and am using the cheapo 600$ version of ESXi (It's called the VSphere Essentials) without vmotion since I'm sitting on just one host so far.

    Also, for future questions, is there any where like w3 schools where I can search this? The VMWare forums, while helpful, show a lot of very old topics and the commands of which are no longer relevant at this time.

    I'm reading up about cloning the hard disk. I suppose this is actually possible... Clonezilla perhaps?

    Thanks!
     
    Last edited: Mar 15, 2019
  2. danswartz

    danswartz 2[H]4U

    Messages:
    3,611
    Joined:
    Feb 25, 2011
    Clonezilla might work. Whatever you use has to understand the guest OS.
     
  3. acquacow

    acquacow Limp Gawd

    Messages:
    399
    Joined:
    Mar 7, 2016
    Easiest thing to do is to just make a smaller disk and migrate data.

    Most filesystems/etc don't support shrinking anyway.
     
    fowlrock and MrGuvernment like this.
  4. tedych

    tedych Limp Gawd

    Messages:
    372
    Joined:
    Jan 18, 2013
    What have you tried so far?
    Now I don't have access to a ESXi but in vmware workstation there is a Compact option and Defrag option (button). After you shrink the partition and make sure you wipe the unpartitioned space (or nullify it) you may try that if esxi has it, or try to migrate to workstation and then back to esxi. And always backup before any manipulation.
     
  5. Spartacus09

    Spartacus09 Gawd

    Messages:
    922
    Joined:
    Apr 21, 2018
    MrGuvernment likes this.
  6. ND40oz

    ND40oz [H]ardForum Junkie

    Messages:
    11,292
    Joined:
    Jul 31, 2005
    Storage vMotion it to a new datastore as thin provisioned. It won't matter how much you have provisioned, if you only have 150 GB allocated within the OS, it won't grow any larger than that.
     
    MrGuvernment likes this.
  7. Spartacus09

    Spartacus09 Gawd

    Messages:
    922
    Joined:
    Apr 21, 2018
    He already mentioned he's on the essentials version which lacks vmotion.
     
  8. ND40oz

    ND40oz [H]ardForum Junkie

    Messages:
    11,292
    Joined:
    Jul 31, 2005
    If you power it down, you should be able to move the storage with Essentials Plus. Or just unlicense it if you're within 60 days of install.

    Or just clone it with a hardware change of making the disk 150 GB.
     
    Spartacus09 likes this.
  9. Spartacus09

    Spartacus09 Gawd

    Messages:
    922
    Joined:
    Apr 21, 2018
    All technically true and legally grey :p
     
  10. Solhokuten

    Solhokuten [H]ard|Gawd

    Messages:
    1,203
    Joined:
    Dec 9, 2009
  11. mda

    mda [H]ard|Gawd

    Messages:
    1,490
    Joined:
    Mar 23, 2011
    Thanks for the replies guys...

    I've tried so far -
    1. Shrinking the disk, using V2V - Results in an unusable VM - I could be doing this wrong, but I've also read online from the same non official sources that YMMV on this one and that it's a hit or miss.
    2. De Partitioning the Drives, Moving them to a different datastore and re registering them again.
    3. Doing "Punching holes" in the vmdk after doing what I did in #2, with the vmkfstools -K

    Thanks for this... I think I'll try this first, as I have some experience with Clonezilla, mostly with our client Ubuntu workstations

    Unfortunately, I'm not super sure on how to migrate the data reliably, since there are some apps installed in it. It's *Probably* not as simple as a copy / paste. I'm not too well versed in linux to know for sure what goes on under the hood after an install.


    I'll try this when I run out of options, especially since this will only be a one time thing. Thanks!

    I've tried this already and the clone failed. Not sure what I'm doing wrong. I shall try redoing it. What's your success rate on this? Is there any technique or pointer aside from what's written?
     
    Last edited: Mar 15, 2019
  12. MrGuvernment

    MrGuvernment [H]ard as it Gets

    Messages:
    19,151
    Joined:
    Aug 3, 2004
    What was the error when the clone failed? Use vmware converter?
     
  13. mda

    mda [H]ard|Gawd

    Messages:
    1,490
    Joined:
    Mar 23, 2011
    I'll re-try this one soon, didn't get it the first time.

    Re: Clonezilla, It's failing on me when cloning from a larger to a smaller disk.

    I've done this before with ubuntu, also using ext3, but for some reason, it's not working this time even using the -icds and -k1 parameters.

    I'm guessing it's probably because I'm trying to clone more than one partition as opposed to cloning just one partition before with ubuntu, and I'm missing a step. Just not so sure if it's in the saving partition (I just saved the partitions in one go), or in restoring it - just used advanced mode and icds/k1.

    Willing to try other options in a bit, and sorry for the delayed response. Just takes time to do each clone/restore.

    Thanks!

    Edit: It seems I've been doing V2V conversion wrong.

    I was originally:
    1. copying the files via scp
    2. converting the vm files
    3. uploading it back

    I tried now:
    1. using the esxi server as both target and destination
    2. picking the vm
    3. deciding what the renamed vm is now.

    The conversion / cloning is now a success, but still can't get the disk shrink to work.

    On initial convert, the new VM shows the smaller size (in the options it shows the smaller size as well, say 40GB -> 30GB), but after booting and shutting down, the clone now shows the original, larger size. Gparted confirms this as I see a the remaining 10GB of unpartitioned space. What else should I be doing?

    Should I be doing thinly provisioned instead of the standard default thick?

    Edit3:

    Tried modifying the extents - BEFORE powering up the VM after V2V.

    doing a ls -lh still shows the old size of 40GB.

    Looks like I need to modify extents AND thinly provision? Am I doing this right?

    Either way, thanks for the help everyone!
     
    Last edited: Mar 18, 2019
  14. mda

    mda [H]ard|Gawd

    Messages:
    1,490
    Joined:
    Mar 23, 2011
    Quick update.

    It seems like this will work IF:

    1. V2V from thick provisioned to thinly provisioned.
    2. Modify extents before powering up the cloned VM
    3. V2V from thinly provisioned to thick provisioned again.

    I think I could actually stop after #2, but #3 confirms what I've done. Is there any shortcut to this? Bigger VMs take quite a bit of time to convert.

    Sorry for the delays in replies. I'm from the other side of the world and don't have access to work on weekends. A new dev server coming soon (Ryzen Gen 3 where are you???) will change that.

    I tried running ESXi 6.5 U2 on an old Quad Core 2.3 Kentsfield Xeon and it ran very slowly...
     
  15. ND40oz

    ND40oz [H]ardForum Junkie

    Messages:
    11,292
    Joined:
    Jul 31, 2005
    Why are you bothering with thick provisioning?
     
  16. Spartacus09

    Spartacus09 Gawd

    Messages:
    922
    Joined:
    Apr 21, 2018
    Thisk is best practice if you have VAAI, and sometimes you have ahole engineers that will overprovision the storage too much unless you do thick.
     
  17. kdh

    kdh Gawd

    Messages:
    708
    Joined:
    Mar 16, 2005
    too many complicated responses in this thread.

    Do it right. Rebuild the VM from scratch migrate over to it.
     
  18. ND40oz

    ND40oz [H]ardForum Junkie

    Messages:
    11,292
    Joined:
    Jul 31, 2005
    Is that actually still a thing with VAAI? I understand the part about having people that don't look at the underlying storage before provisioning disk and having to go back behind them and move stuff around.
     
  19. Spartacus09

    Spartacus09 Gawd

    Messages:
    922
    Joined:
    Apr 21, 2018
    Thats ones of the biggest benefits with VAAI, while not substantial it does provide a little better performance/latency for the VM being thick provisioned (its usually best practice depending on the storage vendor).
    Its the best of both worlds, the client thinks they get all the space, but its not actually using it from a storage admin perspective (I find this extremely useful for greedy qa/engineers).
    When on local storage we'd have to argue all day with them and have to transfer it to convert it for them.
     
  20. ND40oz

    ND40oz [H]ardForum Junkie

    Messages:
    11,292
    Joined:
    Jul 31, 2005
    I've been using NAAI with NetApp AFF using NFS and thin provisioning since my vSphere 5.5/Horizon 5.3 VDI environment. Works great. I've yet to find a reason to use thick provisioning, currently on 6.5 and 7.6, need to upgrade to 7.8, probably do that next month.
     
  21. PcTechyMe

    PcTechyMe n00b

    Messages:
    2
    Joined:
    Mar 29, 2019
    Careful there while trying to shrink physical VM files. Something I can tell you for sure as this did happen to me before. It's quite easy for you to damage your VDMK files, it will be some trouble to restore them if that happens right? Well, lucky here. As I have tested before this method does work, see for yourself at https://www.diskinternals.com/vmfs-recovery/restore-a-vmdk-file/ You can restore both the .vmdk file and the -flat.vmdk file with this tool. Super handy and simple to pick up.
     
  22. mda

    mda [H]ard|Gawd

    Messages:
    1,490
    Joined:
    Mar 23, 2011
    Thanks. What's the best way to back up?

    Export the file via the browser? Veeam (not sure if the cheapest ESXi with the free Veeam would work)? Make a copy with the datastore browser (although AFAIK the vmdk-flat files aren't copied like this).
     
  23. Grimlaking

    Grimlaking 2[H]4U

    Messages:
    2,767
    Joined:
    May 9, 2006
    A good rule going forward that we use. OS gets a drive and application gets a drive. If there is excessive data store that gets a drive. That way if I need to modify drives I can modify the drive with the appopriate role. Then when I need to move or anything else I do so as needed. Another good rule depending in your storage array is to lazy zero thick provision. What that means is the user sees they get all the space. The Middleware reflects they get all the space but the storage grows the space up to the max you set so it isn't all consumed at one shot. This method is BAD for systems where you need the data in one place like a defragmented storage array. The only way to fix that is to storage migrate the VM.