Skip to content

ESXi Update Error "[Errno 28] No space left on device"

When you try to install a VMware ESXi Update using esxcli, the upgrade fails with the following error message:

"[Errno 28] No space left on device"

The problem is caused by ESXi not having enough free space available to extract the installation packages. This article explains how to solve the issue by enabling swapping to a Datastore.

GUI Method

You do not need a vCenter to enable host swapping. It can be done from the ESXi Host Client.

  1. Open ESXi UI (https://[ESXi-IP-Address]/ui/)
  2. Navigate to Host > Manage > System > Swap
  3. Click Edit settings
  4. Enable Swapping and select a datastore (ds1 in that example)
  5. Click Save
  6. Changes are active immediately, there is no need to reboot the host.


CLI Method

You can also activate Datastore Swapping with the esxcli sched swap system command:

# esxcli sched swap system set -n ds1 -d y
# esxcli sched swap system get
   Datastore Active: true
   Datastore Enabled: true
   Datastore Name: ds1
   Datastore Order: 1
   Hostcache Active: false
   Hostcache Enabled: true
   Hostcache Order: 0
   Hostlocalswap Active: false
   Hostlocalswap Enabled: true
   Hostlocalswap Order: 2

7 thoughts on “ESXi Update Error "[Errno 28] No space left on device"”

  1. Christopher Thorjussen

    Another workaround that worked for me on vmware 67u3 iso to latest patch (I got the same error) was to first manually upgrade vmware tools light to latest version. Then the "esxcli software profile update" command workde.

  2. In my case this didn't work. I ended up manually downloading the VIBs on a datastore in a directory and doing a loop install of the VIBs:
    for i in $(cat *.vib); do esxcli software vib install -f -v /vmfs/volumes/datastore1/scratch/$i; done

  3. same here none of the described work arounds worked for me.
    manually downloading the depot ( in my case) and installing it from the local datastore finally did the job ...

  4. The workaround from this article did not work for me but i used a couple of the comments to find a solution. Will elaborate more than they did. I downloaded the from the VMware site

    I extracted this and uploaded it to a datastore, example: /vmfs/volumes/datastore/Update/ESXi670-202103001/vib20/

    made an input file containing only the paths to the .vib files:
    find /vmfs/volumes/datastore/Update/ESXi670-202103001/vib20/ -type f >

    Created a script ( with a for loop:
    for i in `cat`
    esxcli software vib install -f -v $package

    Made script executable: chmod 755

    Ran script: ./

    ESXi host now showing: ESXi670-202103001 2021/03/18 17700523

  5. None of the above worked for me. In fact, the prior solution above crashed my particular instance of ESXi 6.7 (requiring a recovery [SHIFT+R] in order to regain access). It is said "YMMV" and my mileage did indeed vary.

    What did work in my case was to do an "offline update" (as described here)

    USING THE example paths from the prior example above, my steps were:
    1) Download to my local harddrive.
    2) Upload from local HD to ESXi datastore directory
    (for example to /vmfs/volumes/datastore/Update/)

    3) Enable SSH on the ESXi host and SSH to the host
    4) Check what profiles are available in the offline bundle
    esxcli software sources profile list -d /vmfs/volumes/datastore/Update/

    5) Dry-run the upgrade (replacing {#######} with an actual profile Number
    esxcli software profile update -p ESXi-6.7.0-{#######}-standard /vmfs/volumes/datastore/Update/ --dry-run

    6) Place the host into maintenance mode
    vim-cmd /hostsvc/maintenance_mode_enter
    7) Run the upgrade (replacing {#######} with an actual profile Number
    esxcli software profile update -p ESXi-6.7.0-{#######}-standard /vmfs/volumes/datastore/Update/
    8) Reboot using "reboot" from the command line

    9) Reconnect to esxi via SSH and exit Maintenance Mode
    vim-cmd /hostsvc/maintenance_mode_exit
    10 Reboot (in order to auto-restart all the the VMs that normally auto-start)
    -OR- manually restart the VMs.

Leave a Reply

Your email address will not be published. Required fields are marked *