The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,343 other followers

Archive for the ‘ESXi6.5’ Category

« Previous Entries

Alternatives to VMware ESXi: working around “[Errno 28] No space left on device” when updating (especially when booting from USB-stick)

Posted by jpluimers on 2021/05/07

Yesterday I talked about VMware ESXi: working around “[Errno 28] No space left on device” when updating (especially when booting from USB-stick).

There are some alternative workarounds mentioned on the interwebz. Below are a the ones I found. I discuss which ones won’t work, and why I dislike others.

Alternative workarounds that failed

Configuring host-swap

This was suggested by:

Host swap was already configured, and it still failed.

Just in case you ever want to configure host swap, it is under an URL like https://esxi67.example.org/ui/#/host/manage/system/swap and looks like this:

ESXi 6.7: configuring host swap

ESXi 6.7: configuring host swap

You get there by:

  1. logging on to the web UI
  2. clicking Host
  3. clicking Manage under Host
  4. clicking Swap under the System tab
  5. clicking Edit settings when you want to change them
    ESXi 6.7: edit host swap settings

    ESXi 6.7: edit host swap settings

More information about host swap:

Alternative workarounds I like less

Below are a few alternative workarounds. I will include them as they gained me more knowledge, but I will also describe why I like them less.

  • [Wayback] ESXI 6.7 update: No space left on device | eknori.de after explaining that directing the swap space to a datastore fails, also mentions alternative this:

    Unfortunately, in this situation, host swap already was enabled.

    There is though, a workaround. You can use an image that doesn’t have the tools vib included with this command:

    esxcli software profile update -p ESXi-6.7.0-20190802001-no-tools -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

    You can then manually install the troublesome vib (if you have a need for tools) with this command:

    esxcli software vib install -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/tools-light/VMware_locker_tools-light_10.3.10.12406962-14141615.vib

    I had to edit it as the post itself shows the filename as

    vmw-depot
 -index.xml

    Yup: bitching again, as markup issues make code unreliable. It also allows me to explain why I do not like the solution, which is because of two reasons:

    1. It doesn’t explain why this solution works and if it is future proof. Does a future upgrade that includes changed VMware_locker_tools-light also fail? If it does not fail, does it update the VMware_locker_tools-light?
    2. It does not explain how to get the path of https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/tools-light/VMware_locker_tools-light_10.3.10.12406962-14141615.vib.  I did some mor research on this, and it is actually pretty straightforward: the [Wayback] VMware ESXi 6.7 Patch History has it in the table
      ESXi-6.7.0-20210304001-standard patch table

      ESXi-6.7.0-20210304001-standard patch table

      The “Version” link for “tools-light” [Wayback] 11.2.5.17337674-17700514 actually links to the VMware_locker_tools-light_11.1.1.16303738-16701467.vib file.

  • [Wayback] ESXi 6.7.0 – [Errno 28] No space left on devicevibs = VMware_locker_tools-light_11.1.1.16303738-16701467 does not explain where to get the VMware_locker_tools-light_11.1.1.16303738-16701467.vib link from, does not have the code formatted as such (so I did that below), but does actually answers part of the above questions, but not if a future upgrade will also fail. In short: re-running the upgrade after manually installing the VMware_locker_tools-light_11.1.1.16303738-16701467.vib will succeed:

    Unfortunately swap was already enabled to I had to manually install the tools-light with this command:

    esxcli software vib install -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/tools-light/VMware_locker_tools-light_11.1.1.16303738-16701467.vib

    Then re-ran the upgrade and it was successful.

  • [Wayback] ESXi 6 Update error – No Space left on device /locker which suggests to delete “find all big files in /locker and remove it”. I think that is a bad idea, as the /locker directory is maintained by your ESXi system and you should not remove any big file without knowing if it is relied upon by ESXi.
  • While updating VMware ESXi servers, VMware vSphere users may encounter the “No space left on device” error that pops up while executing “esxcli software vib update” command. Interestingly, the problem occurs even though disks are doing well and have enough free space and df -h command proves that.[Wayback] No Space Left on Device? Updating VMware ESXi | StarWind Blog has bad code markup, but explains
    • how to get disk usage with df -h where the vfat volumes usually indicate the ones on USB or SD-card media.
    • that hardly the number of inodes is a problem, and that stat -f / can help you figure out if that is the case on the volume where the upgrade files are stored
    • how to find large files not in data stores; I have changed added -h to the ls command so it becomes human readable:
      find / -path "/vmfs" -prune -o -type f -size +50000k -exec ls -lh '{}' \;
    • suggests how to put the swap space on a data store (which doesn’t work on ESXi 6.7 systems any more)
  •  

    [Wayback] Intel NUC Kit NUC5i3RYH met ESXi 6.0 updaten naar 6.7 – Gahan Zwart’s Blog

    • I like the upgrade copying the ISO to an USB stick with Rufus
    • I do not like the VMware_locker_tools-light... intermediate step, as the last step (download the full depot to a datastore, then update from there)
    • ESXi 7.0 has the same ErrNo 28 update problem as ESXi 6.7 and 6.5, so I will default to the depot download.

–jeroen

Posted in ESXi6, ESXi6.5, ESXi6.7, ESXi7, Power User, Virtualization, VMware, VMware ESXi | Leave a Comment »

VMware ESXi: working around “[Errno 28] No space left on device” when updating (especially when booting from USB-stick)

Posted by jpluimers on 2021/05/06

A while ago, I had this error while upgrading an ESXi 6.7 system:

# esxcli system maintenanceMode get
Enabled
# esxcli software profile update -p ESXi-6.7.0-20210304001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-
index.xml
 [InstallationError]
 [Errno 28] No space left on device
       vibs = VMware_locker_tools-light_11.2.5.17337674-17700514
 Please refer to the log file for more details.

This seems to be kind of a known issue, especially on systems that boot from USB sticks (see [Archive.is] “ESXi” “[Errno 28] No space left on device” – Google Search). Despites these sticks having gotten larger over time, VMware uses very little storage on them, so runs out of storage spice while processing installs from the depot.

This is kind of disappointing, and with the ever growing updates, the only workaround is to download an offline bundle, then install it.

Below I will explain how to get the offline bundle, as it involves a few more steps all aimed at this simple installation of the offline bundle file:

# esxcli system maintenanceMode get
Enabled
# esxcli software profile update -p ESXi-6.7.0-20210304001-standard -d /vmfs/volumes/EVO860_500GB/OfflineBundles/ESXi670-202103001.zip 
Update Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMW_bootbank_ixgben_1.7.1.16-2vmw.670.3.104.16075168, VMW_bootbank_lpfc_11.4.33.26-14vmw.670.3.104.16075168, VMW_bootbank_net-e1000_8.0.3.1-5vmw.670.3.112.16701467, VMW_bootbank_net-vmxnet3_1.1.3.0-3vmw.670.3.104.16075168, VMW_bootbank_nfnic_4.0.0.44-0vmw.670.3.104.16075168, VMW_bootbank_ntg3_4.1.5.0-0vmw.670.3.116.16713306, VMW_bootbank_nvme_1.2.2.28-4vmw.670.3.132.17167734, VMW_bootbank_qfle3f_1.0.25.0.2-15vmw.670.3.104.16075168, VMW_bootbank_sfvmk_1.0.0.1003-7vmw.670.3.104.16075168, VMW_bootbank_vmkusb_0.1-1vmw.670.3.143.17700523, VMW_bootbank_vmw-ahci_2.0.7-2vmw.670.3.143.17700523, VMware_bootbank_cpu-microcode_6.7.0-3.139.17700514, VMware_bootbank_elx-esx-libelxima.so_11.4.1184.2-3.89.15160138, VMware_bootbank_esx-base_6.7.0-3.143.17700523, VMware_bootbank_esx-ui_1.33.7-15803439, VMware_bootbank_esx-update_6.7.0-3.143.17700523, VMware_bootbank_native-misc-drivers_6.7.0-3.89.15160138, VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.36-2vmw.670.3.116.16713306, VMware_bootbank_vsan_6.7.0-3.143.17661912, VMware_bootbank_vsanhealth_6.7.0-3.143.17665851, VMware_locker_tools-light_11.2.5.17337674-17700514
   VIBs Removed: VMW_bootbank_ixgben_1.7.1.16-1vmw.670.3.73.14320388, VMW_bootbank_lpfc_11.4.33.25-14vmw.670.3.73.14320388, VMW_bootbank_net-e1000_8.0.3.1-5vmw.670.0.0.8169922, VMW_bootbank_net-vmxnet3_1.1.3.0-3vmw.670.2.48.13006603, VMW_bootbank_nfnic_4.0.0.29-0vmw.670.3.73.14320388, VMW_bootbank_ntg3_4.1.3.2-1vmw.670.1.28.10302608, VMW_bootbank_nvme_1.2.2.28-1vmw.670.3.73.14320388, VMW_bootbank_qfle3f_1.0.25.0.2-14vmw.670.0.0.8169922, VMW_bootbank_sfvmk_1.0.0.1003-6vmw.670.3.73.14320388, VMW_bootbank_vmkusb_0.1-1vmw.670.2.48.13006603, VMW_bootbank_vmw-ahci_1.2.8-1vmw.670.3.73.14320388, VMware_bootbank_cpu-microcode_6.7.0-2.69.14141615, VMware_bootbank_elx-esx-libelxima.so_11.4.1184.1-2.48.13006603, VMware_bootbank_esx-base_6.7.0-3.73.14320388, VMware_bootbank_esx-ui_1.33.4-14093553, VMware_bootbank_esx-update_6.7.0-3.73.14320388, VMware_bootbank_native-misc-drivers_6.7.0-2.48.13006603, VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.36-2.48.13006603, VMware_bootbank_vsan_6.7.0-3.73.14263135, VMware_bootbank_vsanhealth_6.7.0-3.73.14263064, VMware_locker_tools-light_10.3.10.12406962-14141615
   VIBs Skipped: VMW_bootbank_ata-libata-92_3.00.9.2-16vmw.670.0.0.8169922, VMW_bootbank_ata-pata-amd_0.3.10-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-atiixp_0.4.6-4vmw.670.0.0.8169922, VMW_bootbank_ata-pata-cmd64x_0.2.5-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-hpt3x2n_0.3.4-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-pdc2027x_1.0-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-serverworks_0.4.3-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-sil680_0.4.8-3vmw.670.0.0.8169922, VMW_bootbank_ata-pata-via_0.3.3-2vmw.670.0.0.8169922, VMW_bootbank_block-cciss_3.6.14-10vmw.670.0.0.8169922, VMW_bootbank_bnxtnet_20.6.101.7-24vmw.670.3.73.14320388, VMW_bootbank_bnxtroce_20.6.101.0-20vmw.670.1.28.10302608, VMW_bootbank_brcmfcoe_11.4.1078.25-14vmw.670.3.73.14320388, VMW_bootbank_char-random_1.0-3vmw.670.0.0.8169922, VMW_bootbank_ehci-ehci-hcd_1.0-4vmw.670.0.0.8169922, VMW_bootbank_elxiscsi_11.4.1174.0-2vmw.670.0.0.8169922, VMW_bootbank_elxnet_11.4.1097.0-5vmw.670.3.73.14320388, VMW_bootbank_hid-hid_1.0-3vmw.670.0.0.8169922, VMW_bootbank_i40en_1.8.1.9-2vmw.670.3.73.14320388, VMW_bootbank_iavmd_1.2.0.1011-2vmw.670.0.0.8169922, VMW_bootbank_igbn_0.1.1.0-5vmw.670.3.73.14320388, VMW_bootbank_ima-qla4xxx_2.02.18-1vmw.670.0.0.8169922, VMW_bootbank_ipmi-ipmi-devintf_39.1-5vmw.670.1.28.10302608, VMW_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.670.1.28.10302608, VMW_bootbank_ipmi-ipmi-si-drv_39.1-5vmw.670.1.28.10302608, VMW_bootbank_iser_1.0.0.0-1vmw.670.1.28.10302608, VMW_bootbank_lpnic_11.4.59.0-1vmw.670.0.0.8169922, VMW_bootbank_lsi-mr3_7.708.07.00-3vmw.670.3.73.14320388, VMW_bootbank_lsi-msgpt2_20.00.06.00-2vmw.670.3.73.14320388, VMW_bootbank_lsi-msgpt35_09.00.00.00-5vmw.670.3.73.14320388, VMW_bootbank_lsi-msgpt3_17.00.02.00-1vmw.670.3.73.14320388, VMW_bootbank_misc-cnic-register_1.78.75.v60.7-1vmw.670.0.0.8169922, VMW_bootbank_misc-drivers_6.7.0-2.48.13006603, VMW_bootbank_mtip32xx-native_3.9.8-1vmw.670.1.28.10302608, VMW_bootbank_ne1000_0.8.4-2vmw.670.2.48.13006603, VMW_bootbank_nenic_1.0.29.0-1vmw.670.3.73.14320388, VMW_bootbank_net-bnx2_2.2.4f.v60.10-2vmw.670.0.0.8169922, VMW_bootbank_net-bnx2x_1.78.80.v60.12-2vmw.670.0.0.8169922, VMW_bootbank_net-cdc-ether_1.0-3vmw.670.0.0.8169922, VMW_bootbank_net-cnic_1.78.76.v60.13-2vmw.670.0.0.8169922, VMW_bootbank_net-e1000e_3.2.2.1-2vmw.670.0.0.8169922, VMW_bootbank_net-enic_2.1.2.38-2vmw.670.0.0.8169922, VMW_bootbank_net-fcoe_1.0.29.9.3-7vmw.670.0.0.8169922, VMW_bootbank_net-forcedeth_0.61-2vmw.670.0.0.8169922, VMW_bootbank_net-igb_5.0.5.1.1-5vmw.670.0.0.8169922, VMW_bootbank_net-ixgbe_3.7.13.7.14iov-20vmw.670.0.0.8169922, VMW_bootbank_net-libfcoe-92_1.0.24.9.4-8vmw.670.0.0.8169922, VMW_bootbank_net-mlx4-core_1.9.7.0-1vmw.670.0.0.8169922, VMW_bootbank_net-mlx4-en_1.9.7.0-1vmw.670.0.0.8169922, VMW_bootbank_net-nx-nic_5.0.621-5vmw.670.0.0.8169922, VMW_bootbank_net-tg3_3.131d.v60.4-2vmw.670.0.0.8169922, VMW_bootbank_net-usbnet_1.0-3vmw.670.0.0.8169922, VMW_bootbank_nhpsa_2.0.22-3vmw.670.1.28.10302608, VMW_bootbank_nmlx4-core_3.17.13.1-1vmw.670.2.48.13006603, VMW_bootbank_nmlx4-en_3.17.13.1-1vmw.670.2.48.13006603, VMW_bootbank_nmlx4-rdma_3.17.13.1-1vmw.670.2.48.13006603, VMW_bootbank_nmlx5-core_4.17.13.1-1vmw.670.3.73.14320388, VMW_bootbank_nmlx5-rdma_4.17.13.1-1vmw.670.2.48.13006603, VMW_bootbank_nvmxnet3-ens_2.0.0.21-1vmw.670.0.0.8169922, VMW_bootbank_nvmxnet3_2.0.0.29-1vmw.670.1.28.10302608, VMW_bootbank_ohci-usb-ohci_1.0-3vmw.670.0.0.8169922, VMW_bootbank_pvscsi_0.1-2vmw.670.0.0.8169922, VMW_bootbank_qcnic_1.0.2.0.4-1vmw.670.0.0.8169922, VMW_bootbank_qedentv_2.0.6.4-10vmw.670.1.28.10302608, VMW_bootbank_qfle3_1.0.50.11-9vmw.670.0.0.8169922, VMW_bootbank_qfle3i_1.0.2.3.9-3vmw.670.0.0.8169922, VMW_bootbank_qflge_1.1.0.11-1vmw.670.0.0.8169922, VMW_bootbank_sata-ahci_3.0-26vmw.670.0.0.8169922, VMW_bootbank_sata-ata-piix_2.12-10vmw.670.0.0.8169922, VMW_bootbank_sata-sata-nv_3.5-4vmw.670.0.0.8169922, VMW_bootbank_sata-sata-promise_2.12-3vmw.670.0.0.8169922, VMW_bootbank_sata-sata-sil24_1.1-1vmw.670.0.0.8169922, VMW_bootbank_sata-sata-sil_2.3-4vmw.670.0.0.8169922, VMW_bootbank_sata-sata-svw_2.3-3vmw.670.0.0.8169922, VMW_bootbank_scsi-aacraid_1.1.5.1-9vmw.670.0.0.8169922, VMW_bootbank_scsi-adp94xx_1.0.8.12-6vmw.670.0.0.8169922, VMW_bootbank_scsi-aic79xx_3.1-6vmw.670.0.0.8169922, VMW_bootbank_scsi-bnx2fc_1.78.78.v60.8-1vmw.670.0.0.8169922, VMW_bootbank_scsi-bnx2i_2.78.76.v60.8-1vmw.670.0.0.8169922, VMW_bootbank_scsi-fnic_1.5.0.45-3vmw.670.0.0.8169922, VMW_bootbank_scsi-hpsa_6.0.0.84-3vmw.670.0.0.8169922, VMW_bootbank_scsi-ips_7.12.05-4vmw.670.0.0.8169922, VMW_bootbank_scsi-iscsi-linux-92_1.0.0.2-3vmw.670.0.0.8169922, VMW_bootbank_scsi-libfc-92_1.0.40.9.3-5vmw.670.0.0.8169922, VMW_bootbank_scsi-megaraid-mbox_2.20.5.1-6vmw.670.0.0.8169922, VMW_bootbank_scsi-megaraid-sas_6.603.55.00-2vmw.670.0.0.8169922, VMW_bootbank_scsi-megaraid2_2.00.4-9vmw.670.0.0.8169922, VMW_bootbank_scsi-mpt2sas_19.00.00.00-2vmw.670.0.0.8169922, VMW_bootbank_scsi-mptsas_4.23.01.00-10vmw.670.0.0.8169922, VMW_bootbank_scsi-mptspi_4.23.01.00-10vmw.670.0.0.8169922, VMW_bootbank_scsi-qla4xxx_5.01.03.2-7vmw.670.0.0.8169922, VMW_bootbank_shim-iscsi-linux-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-iscsi-linux-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libata-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libata-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libfc-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libfc-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libfcoe-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-libfcoe-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-vmklinux-9-2-1-0_6.7.0-0.0.8169922, VMW_bootbank_shim-vmklinux-9-2-2-0_6.7.0-0.0.8169922, VMW_bootbank_shim-vmklinux-9-2-3-0_6.7.0-0.0.8169922, VMW_bootbank_smartpqi_1.0.1.553-28vmw.670.3.73.14320388, VMW_bootbank_uhci-usb-uhci_1.0-3vmw.670.0.0.8169922, VMW_bootbank_usb-storage-usb-storage_1.0-3vmw.670.0.0.8169922, VMW_bootbank_usbcore-usb_1.0-3vmw.670.0.0.8169922, VMW_bootbank_vmkata_0.1-1vmw.670.0.0.8169922, VMW_bootbank_vmkfcoe_1.0.0.1-1vmw.670.1.28.10302608, VMW_bootbank_vmkplexer-vmkplexer_6.7.0-0.0.8169922, VMW_bootbank_xhci-xhci_1.0-3vmw.670.0.0.8169922, VMware_bootbank_esx-dvfilter-generic-fastpath_6.7.0-0.0.8169922, VMware_bootbank_esx-xserver_6.7.0-3.73.14320388, VMware_bootbank_lsu-hp-hpsa-plugin_2.0.0-16vmw.670.1.28.10302608, VMware_bootbank_lsu-intel-vmd-plugin_1.0.0-2vmw.670.1.28.10302608, VMware_bootbank_lsu-lsi-drivers-plugin_1.0.0-1vmw.670.2.48.13006603, VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-13vmw.670.1.28.10302608, VMware_bootbank_lsu-lsi-lsi-msgpt3-plugin_1.0.0-9vmw.670.2.48.13006603, VMware_bootbank_lsu-lsi-megaraid-sas-plugin_1.0.0-9vmw.670.0.0.8169922, VMware_bootbank_lsu-lsi-mpt2sas-plugin_2.0.0-7vmw.670.0.0.8169922, VMware_bootbank_lsu-smartpqi-plugin_1.0.0-3vmw.670.1.28.10302608, VMware_bootbank_qlnativefc_3.1.8.0-5vmw.670.3.73.14320388, VMware_bootbank_rste_2.0.2.0088-7vmw.670.0.0.8169922
# reboot

Note that I always perform a  esxcli system maintenanceMode get in order to verify the system is indeed in maintenance mode.

Steps to get the offline bundle

0. determining the profile

Actually there is a pre-step: checking which update profile is needed. I use the VMware Patch Tracker from VFrontDe, as you can subscribe through RSS (by ESXi version) Twitter (all versions) for that.

For ESXi 7, I use moved from the [Wayback] regular ESXi 6.7 patch RSS feed to the Feedly ESXi 6.7 patch RSS feed (which integrates in my daily news reading) of [Wayback] VMware ESXi 6.7 Patch History:

Keep track of VMware ESXi patches, subscribe by [Archive.is] RSS and [Archive.is] Twitter! – Brought to you by @VFrontDe

For the current (as of writing) update, it shows two out of four profiles:

  1. Imageprofile ESXi-6.7.0-20210304001-standard (Build 17700523) … (For more information see [Wayback] Release Notes.)
  2. Imageprofile ESXi-6.7.0-20210301001s-standard (Build 17700514) … (For more information see [Wayback] Release Notes.)

There can be two more “...-no-tools” profiles as described by [Wayback] VMware ESXi Image Profiles | virten.net

Example – ESXi 5.5 Patch 2 contains 4 Image Profiles:
  1. ESXi-5.5.0-20140704001-standard – Contains all patches
  2. ESXi-5.5.0-20140704001-no-tools – Contains all patches but no VMware Tools
  3. ESXi-5.5.0-20140701001s-standard – Contains security patches only
  4. ESXi-5.5.0-20140701001s-no-tools – Contains security patches only and no VMware Tools

…

vSphere ESXi 6.7 Image Profiles
Image Profile ESX Build Release Date
ESXi-6.7.0-20210304001-standard 17700523 2021-03-18
ESXi-6.7.0-20210304001-no-tools 17700523 2021-03-18
ESXi-6.7.0-20210301001s-standard 17700514 2021-03-18
ESXi-6.7.0-20210301001s-no-tools 17700514 2021-03-18

Given that I my environment as complete as possible (the original ESXi install contains everything, so I do want to include the “VMware Tools“, and update the full software, nut just security issues), I opt for “###...-standard” and not for “###s...-standard“.

1. determine the download

The page [Wayback] VMware ESXi 6.7 Patch History (and similar pages for other ESXi versions) contains a tiny link in the upper left hand side named “[MyVMware Patch Download]” (I saved it in the Wayback machine) which brings you a patch search page on the VMware patch site.

The big drawback is that you need to be signed on into yout VMware account to actually see this page. The VMware account validation is implemented in a “corporate” way, so often does not work (especially when you need it, which for me often is on weekends, a period in the week that corporates seem to ar less monitor their systems than during USA work-day hours). I might sound cynical, but this set me back quite some time even trying to get an ESXi 7 license.

Here are some screenshots:

VMware HomeP/roduct Patches

VMware Home/Product Patches

The site is so corporate, that when your screen is not wide enough, the selection box is drawn outside your screen area:

VMware being very corporate: drawing selection box outside the screen area.

VMware being very corporate: drawing selection box outside the screen area.

Anyway the one ending in “and Installable” is the one we want, cutting off the other part (you are a corporate or you aren’t, right?):

"ESXi (Embedded and ..." is cut off as the layout has been designed to cut off either way.

“ESXi (Embedded and …” is cut off as the layout has been designed to cut off either way.

So for ESXi 6.7.0, when writing this, the offline bundles were these:

ESXi 6.7.0 offline bundles

ESXi 6.7.0 offline bundles (unlike the YYYYMM### release name and YYYYMM### bulletin numbers, the dates are in MM/DD/YYYY format)

Release Name Release Date Build Number Bulletin Number

ESXi670-202103001

Product:ESXi (Embedded and Installable) 6.7.0

Download Size:476.7 MB

03/18/2021

17700523

 ESXi670-202103102-SG

ESXi670-202103103-SG

ESXi670-202103001

ESXi670-202103101-SG

ESXi670-202103401-BG

ESXi670-202103403-BG

ESXi670-202103402-BG

Download

So, for imageprofile ESXi-6.7.0-20210304001-standard (Build 17700523), the release name is ESXi670-202103001 (as it matches Build Number [Wayback] 17700523).

From the above, we now have these links and numbers:

The two common parts above are:

  1. ESXi670-202103001 (both as identifier and as filename ESXi670-202103001.zip)
  2. https://docs.vmware.com/en/VMware-vSphere/6.7/rn/esxi670-202103001.html which contains a table like this that has both a (deprecated!) md5sum and sha1sum value:
    Download Filename: ESXi670-202103001.zip
    Build: 17700523
    Download Size: 476.7 MB
    md5sum: 26f177706bce4a0432d9e8af016a5bad
    sha1checksum: 0263a25351d003d34321a062b391d9fe5c312bd2
    Host Reboot Required: Yes
    Virtual Machine Migration or Shutdown Required: Yes

 

Back to the download button, where you can validate the filename of the off-line bundle:

The Download button points to a complex URL with these parts:

  • scheme:[//authority]path = https://download2.vmware.com/patch/software/VUM/OFFLINE/release-767-20210316-739878/ESXi670-202103001.zip
  • [?query] is of the form ?HashKey=<32-hexadecimal-digits>&params=<URI-escaped-JSON-string>&AuthKey=<10-decimal-digits>_<32-hexadecimal-digits>
  • Sample values included in params:
    • "custnumber":"ABCDEFGHIJKLMNOP==" 16-digit == padded base64 encoded customer identification
    • "sourcefilesize":"476.7+MB"
    • "dlgcode":"ESXi670-202103001"
    • "languagecode":"en"
    • "source":"PATCH"
    • "downloadtype":"manual"
    • "downloaduuid":"12345678-490a-abcd-efgh12345678" (version 4 variant 1 uuid)
    • "productname":"ESXi+(Embedded+and+Installable)"
    • "productversion":"6.7.0"

2. downloading the offline bundle file and verifying it

The steps taken until now:

  1. Find the most recent imageprofile name at [Wayback] VMware ESXi 6.7 Patch History (in my case ESXi-6.7.0-20210304001-standard)
  2. Find the “Release notes” link right under the table below it (in my case https://docs.vmware.com/en/VMware-vSphere/6.7/rn/esxi670-202103001.html#esxi-6-7-0-20210301001s-standard-resolved)
  3. Browse to the top of that page for the table with the offline bundle identifier and filename

Now

  1. search for the filename (like [Wayback/Archive.is] “ESXi670-202103001.zip” – Google Search) to download, or get the download URL from the VMware patch site (note this URL expires usually within 20 minutes).
  2. download the file using that URL:
    # wget "download-URL" -O /vmfs/volumes/EVO860_500GB/OfflineBundles/ESXi670-202103001.zip
Connecting to download.example.org (192.0.2.0:443)
ESXi670-202103001.zi 100% |****************************************************************************************************************|  454M  0:00:00 ETA

    Yes, that strange IP address is for documentation purposes as you can see in [Wayback] RFC 5737 – IPv4 Address Blocks Reserved for Documentation and Reserved IP addresses – Wikipedia.

  3. verify the download with the above sha1sum (which is included in the ESXi BusyBox shell)
    # sha1sum /vmfs/volumes/EVO860_500GB/OfflineBundles/ESXi670-202103001.zip 
0263a25351d003d34321a062b391d9fe5c312bd2  /vmfs/volumes/EVO860_500GB/OfflineBundles/ESXi670-202103001.zip
  4. shutdown all the VM’s, put the machine in maintenance mode, upgrade, verify result, reboot, put the machine out of maintenance mode, start any VM’s that should be up

[Archive.is] [OSError] [Errno 28] No space left on device even … – VMware Technology Network VMTN very importantly mentions to do a dry-run before actually upgrading:

esxcli software profile update --dry-run -p ESXi-6.7.0-20201103001-standard -d /vmfs/volumes/datastore1/update/ESXi670-202011001.zip

If the dry run is successful, do the update with

esxcli software profile update -p ESXi-6.7.0-20201103001-standard -d /vmfs/volumes/datastore1/update/ESXi670-202011001.zip

—jeroen

Posted in ESXi6, ESXi6.5, ESXi6.7, ESXi7, Power User, Virtualization, VMware, VMware ESXi | Leave a Comment »

ESXi: where are my log files actually stored? Actually, most of them are in `/scratch/log` which points to a hidden `.locker` directory in a datastore.

Posted by jpluimers on 2021/05/05

A summary of the full gist at [Wayback/Archive.is] ESXi-where-are-my-log-files-stored.txt:

# ls -al / /var/ /var/log/ /var/run/ /scratch/ /scratch/log/ | grep "/\|log\|-\>"
/:
...
lrwxrwxrwx    1 root     root            57 Apr  4 18:16 scratch -> /vmfs/volumes/5ce2d440-72311161-75c5-0025907d9d5c/.locker
...
/scratch/:
drwxr-xr-x    1 root     root        106496 Apr 10 08:40 log
/scratch/log/:
-rw-------    1 root     root           411 Apr  4 18:20 Xorg.log
...
-rw-------    1 root     root         78835 Apr  4 10:30 syslog.0.gz
-rw-------    1 root     root         61136 Mar 18 15:05 syslog.1.gz
-rw-------    1 root     root         60589 Feb 24 00:30 syslog.2.gz
-rw-------    1 root     root         60373 Feb  1 08:01 syslog.3.gz
-rw-------    1 root     root         60203 Jan  9 15:50 syslog.4.gz
-rw-------    1 root     root         59889 Dec 17 23:20 syslog.5.gz
-rw-------    1 root     root         60398 Nov 25 06:50 syslog.6.gz
-rw-------    1 root     root         60563 Nov  2 14:25 syslog.7.gz
-rw-------    1 root     root        531794 Apr 10 09:35 syslog.log
...
-rw-------    1 root     root        157255 Apr  4 18:17 vvold.log
/var/:
...
drwxr-xr-x    1 root     root           512 Apr  5 19:19 log
...
/var/log/:
-rw-r--r--    1 root     root           416 Apr  4 18:16 .vmsyslogd.err
...
-rw-r--r--    1 root     root         38069 Apr  4 18:20 configRP.log
-rw-r--r--    1 root     root             0 Apr  4 18:16 cryptoloader.log
...
-rw-r--r--    1 root     root            87 Apr  5 21:57 esxcli.log
...
-rw-------    1 root     root          3350 Apr  4 18:16 init.log
-rw-r--r--    1 root     root           966 Apr  4 18:16 iofilter-init.log
...
-rw-r--r--    1 root     root         21769 Apr  4 18:16 jumpstart-esxcli-stdout.log
-rw-r--r--    1 root     root         18857 Apr  4 18:16 jumpstart-native-stdout.log
-rw-r--r--    1 root     root         10837 Apr  4 18:16 jumpstart-stdout.log
-rw-r--r--    1 root     root             0 Apr  4 18:16 kickstart.log
...
-rw-------    1 root     root         10916 Apr  4 18:16 sysboot.log
...
-rw-------    1 root     root            64 Apr 10 09:13 tallylog
...
/var/run/:
lrwxrwxrwx    1 root     root            12 Apr  4 18:16 log -> /scratch/log
  • Almost all log files (most from /var/log and all from /var/run/log) are actually persistently stored in /scratch/log and survive reboots. Just a few are non-persistent.
  • /var/log/syslog is being archived as .gz files (compressed by gzip).
  • syslog is special: the location can be configured, and even be external: [Wayback] Configuring syslog on ESXi (2003322)

    VMware vSphere ESXi 5.0 and higher hosts run a Syslog service (vmsyslogd) that provides a standard mechanism for logging messages from the VMkernel and other system components. By default in ESXi, these logs are placed on a local scratch volume or a ramdisk. To preserve the logs further, ESXi can be configured to place these logs to an alternate storage location on disk and to send the logs across the network to a Syslog server.

  • A summary of some of the above log files is at [Wayback] ESXi Log File Locations

–jeroen

Posted in *nix, *nix-tools, ash/dash, ash/dash development, BusyBox, Development, ESXi6, ESXi6.5, ESXi6.7, ESXi7, gzip, Power User, Scripting, Software Development, Virtualization, VMware, VMware ESXi | Leave a Comment »

Running ArchiveTeam Warrior version 3.2 on ESXi

Posted by jpluimers on 2021/05/05

A while ago I wrote about Helping the WayBack ArchiveTeam team: running their Warrior virtual appliance on ESXi.

Since it was scheduled before my cancer treatment started and got posted when still recovering from it, I missed that version 3.2 of the [Wayback] ArchiveTeam Warrior appliance appeared in the [Wayback] Releases · ArchiveTeam/Ubuntu-Warrior at [Wayback] Release v3.2 · ArchiveTeam/Ubuntu-Warrior. You can download it form these places:

These two sites have not yet been updated, so they contain the older versions:

The source code now has been moved three times:

  1. [Wayback] ArchiveTeam/warrior-code
  2. [Wayback] ArchiveTeam/warrior-code2 · GitHub
  3. [Wayback] ArchiveTeam/Ubuntu-Warrior at master (this is version 3 and up)

The docker container

The new version of Archive Team Warrior now is basically a shell around [Wayback] Watchtower and the [Wayback] ArchiveTeam/warrior-dockerfile: A Dockerfile for the ArchiveTeam Warrior docker container. This makes updating the core way easier.

More on the docker container (in case you want to run it yourself) is at [Wayback] ArchiveTeam Warrior – Archiveteam – Installing and running with Docker:

You’ll need Docker (open source) and the Warrior Docker image.

  1. Download Docker from the link above and install it.
  2. Open your terminal. On Windows, you can use either Command Prompt (CMD) or PowerShell. On macOS and Linux you can use Terminal (Bash).
  3. Use the following command to start the Warrior as well as Watchtower, which will automatically keep your Warrior updated: 
    docker run --detach --name watchtower --restart=on-failure --volume /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower --label-enable --cleanup --interval 3600 && docker run --detach --name archiveteam-warrior --label=com.centurylinklabs.watchtower.enable=true --restart=on-failure --publish 8001:8001 atdr.meo.ws/archiveteam/warrior-dockerfile

    (For a full explanation of this command, see items 3 and 4 here.)

  4. Using your regular web browser, visit http://localhost:8001/.

The virtual appliance

The virtual appliance is released as virtual appliance aimed by default at VirtualBox and steps to run with VMware: [Wayback] ArchiveTeam Warrior – Archiveteam.

Totally agreeing with Kristian Kohntopp, I do not understand why people use Virtualbox at all: I just run in too much issues like [Archive.is] Kristian Köhntopp on Twitter: “Hint: Wenn die Installation einer Linux-Distro in Virtualbox mit wechselnden, unbekannten Fehlern scheitert, hilft es, stattdessen einmal VMware Workstation oder kvm zu probieren. In meinem Fall hat es dann jedes einzelne Mal mit demselben Iso geklappt.”.

Inspecting the .ova file, which is basically a tar compressed file consisting of an OVF directory as per Open Virtualization Format:Design – Wikipedia

The entire directory can be distributed as an Open Virtual Appliance (OVA) package, which is a tar archive file with the OVF directory inside.

Inspecting the disk image inside the directory learned me that pure one-file binary VMDK disk images start with a KMDV signature in big-endian and KDMV in little-endian (first four bytes are 4b 44 4d 56). More on the VMDK file format can be found in these links (all via [Wayback] vmdk file format specification – Google Search):

So here are some steps to get the .ova image to run on ESXi. I think it should work for ESXI 5.1 and up, but I have tested only on ESXi 6.7:

Read the rest of this entry »

Posted in *nix, *nix-tools, Cloud, Containers, diff, Docker, ESXi5, ESXi5.1, ESXi5.5, ESXi6, ESXi6.5, ESXi6.7, ESXi7, Infrastructure, Internet, InternetArchive, Kubernetes (k8n), patch, Power User, VirtualBox, Virtualization, VMware, VMware ESXi, VMware Workstation, WayBack machine | Leave a Comment »

VMware ESXi console: viewing all VMs, suspending and waking them up: part 5

Posted by jpluimers on 2021/04/30

Yesterday’s post got a bit longer than anticipated as there were most steps than I hoped for to create the listing script vim-cmd-list-all-VMs.sh:

#!/bin/sh
# https://wiert.me/2021/04/29/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-4/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
done

This means that today there is a new try to cover the rest of these lists I started yesterday with:

Available commands

  • vim-cmd vmsvc/power.getstate vmid
  • vim-cmd vmsvc/power.hibernate vmid
  • vim-cmd vmsvc/power.off vmid
  • vim-cmd vmsvc/power.on vmid
  • vim-cmd vmsvc/power.reboot vmid
  • vim-cmd vmsvc/power.reset vmid
  • vim-cmd vmsvc/power.shutdown vmid
  • vim-cmd vmsvc/power.suspend vmid
  • vim-cmd vmsvc/power.suspendResume vmid

Unavailable commands

  • vim-cmd vmsvc/power.startup vmid
  • vim-cmd vmsvc/power.resume vmid
  • vim-cmd vmsvc/power.wakeup vmid

So here we go:

vim-cmd-hibernate-running-VMs.sh and vim-cmd-suspend-running-VMs.sh

These files are almost the same: the echo and command are different (Hibernating versus Suspending and power.hibernate versus suspend)

#!/bin/sh
# https://wiert.me/2021/04/30/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-5/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    # echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
    if [ "${powerState}" == "Powered on" ] ; then
        echo "Powered on  VM with id ${vmid} and name: $name"
        echo "Hibernating VM with id ${vmid} and name: $name"
        vim-cmd vmsvc/power.hibernate ${vmid}
    fi
done

This hibernates all VMs with power state Powered on and waits for each VM to complete hibernation.

#!/bin/sh
# https://wiert.me/2021/04/30/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-5/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    # echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
    if [ "${powerState}" == "Powered on" ] ; then
        echo "Powered on VM with id ${vmid} and name: $name"
        echo "Suspending VM with id ${vmid} and name: $name"
        vim-cmd vmsvc/power.suspend ${vmid}
    fi
done

This suspends all VMs with power state Powered on and waits for each VM to complete suspending.

vim-cmd-resume-suspended-VMs.sh and vim-cmd-wakeup-suspended-VMs.sh

#!/bin/sh
# https://wiert.me/2021/04/30/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-5/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    # echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
    if [ "${powerState}" == "Suspended" ] ; then
        echo "Suspended VM with id ${vmid} and name: $name"
        echo "Resuming  VM with id ${vmid} and name: $name"
        vim-cmd vmsvc/power.on ${vmid}
    fi
done

This resumes (as there is no vim-cmd vmsvc/power.resume vmid) all VMs with power state Suspended and waits for each VM to complete resume.

vim-cmd-power-off-powered-on-VMs.sh 

#!/bin/sh
# https://wiert.me/2021/04/30/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-5/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    # echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
    if [ "${powerState}" == "Powered on" ] ; then
        echo "Powered on   VM with id ${vmid} and name: $name"
        echo "Powering off VM with id ${vmid} and name: $name"
        vim-cmd vmsvc/power.off ${vmid}
    fi
done

This powers off all VMs with power state Power on and waits for each VM to start powering off (but does not wait for them to complete powering off, so parts run in parallel).

vim-cmd-power-on-powered-off-VMs.sh, vim-cmd-power-on-shutdown-VMs.sh and vim-cmd-startup-shutdown-VMs.sh

#!/bin/sh
# https://wiert.me/2021/04/30/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-5/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    # echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
    if [ "${powerState}" == "Powered off" ] ; then
        echo "Powered off VM with id ${vmid} and name: $name"
        echo "Powering on VM with id ${vmid} and name: $name"
        vim-cmd vmsvc/power.on ${vmid}
    fi
done

These powers on all VMs with power state Powered off and waits for each VM to complete power on (but does not wait for them to complete boot, so part runs in parallel!).

These are exactly the same, as you cannot distinguish a VM that has been shutdown by vim-cmd vmsvc/power.off vmid from vim-cmd vmsvc/shutdown vmid.

vim-cmd-reboot-powered-on-VMs.sh 

#!/bin/sh
# https://wiert.me/2021/04/30/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-5/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    # echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
    if [ "${powerState}" == "Powered on" ] ; then
        echo "Powered on VM with id ${vmid} and name: $name"
        echo "Rebooting  VM with id ${vmid} and name: $name"
        vim-cmd vmsvc/power.reboot ${vmid}
    fi
done

This reboots all VMs with power state Power on and waits for each VM to start rebooting (but does not wait for them to complete reboot, so parts run in parallel).

vim-cmd-reset-powered-on-VMs.sh 

#!/bin/sh
# https://wiert.me/2021/04/30/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-5/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    # echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
    if [ "${powerState}" == "Powered on" ] ; then
        echo "Powered on VM with id ${vmid} and name: $name"
        echo "Resetting  VM with id ${vmid} and name: $name"
        vim-cmd vmsvc/power.reset ${vmid}
    fi
done

This resets all VMs with power state Power on and waits for each VM to start rebooting (but does not wait for them to complete reboot, so parts run in parallel).

vim-cmd-suspendResume-powered-on-VMs.sh 

#!/bin/sh
# https://wiert.me/2021/04/30/vmware-esxi-console-viewing-all-vms-suspending-and-waking-them-up-part-5/
vmids=`vim-cmd vmsvc/getallvms | sed -n -E -e "s/^([[:digit:]]+)\s+((\S.+\S)?)\s+(\[\S+\])\s+(.+\.vmx)\s+(\S+)\s+(vmx-[[:digit:]]+)\s*?((\S.+)?)$/\1/p"`
for vmid in ${vmids} ; do
    powerState=`vim-cmd vmsvc/power.getstate ${vmid} | sed '1d'`
    name=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/\(vim.vm.ConfigInfo\) \{/,/files = \(vim.vm.FileInfo\) \{/ s/^ +name = "(.*)",.*?/\1/p'`
    vmPathName=`vim-cmd vmsvc/get.config ${vmid} | sed -n -E -e '/files = \(vim.vm.FileInfo\) \{/,/tools = \(vim.vm.ToolsConfigInfo\) \{/ s/^ +vmPathName = "(.*)",.*?/\1/p'`
    # echo "VM with id ${vmid} has power state ${powerState} (name = ${name}; vmPathName = ${vmPathName})."
    if [ "${powerState}" == "Powered on" ] ; then
        echo "Powered on      VM with id ${vmid} and name: $name"
        echo "SuspendResuming VM with id ${vmid} and name: $name"
        vim-cmd vmsvc/power.suspendResume ${vmid}
    fi
done

This suspends and resumes on all VMs with power state Power on and waits for each VM to start this shirt cycle (but does not wait for them to complete the suspend and resume cycle, so parts run in parallel).

Future episodes

For now, this is OK enough for me, but I might write a new installment trying to run more of these in parallel (as parts already are done on the ESXi side).

–jeroen

Posted in *nix, *nix-tools, ash/dash, ash/dash development, Development, ESXi6, ESXi6.5, ESXi6.7, ESXi7, Power User, Scripting, sed, sed script, Software Development, Virtualization, VMware, VMware ESXi | Leave a Comment »

« Previous Entries
 
%d bloggers like this: