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

  • Pages

  • All categories

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

    Join 1,860 other subscribers

Archive for the ‘ESXi7’ Category

Patching ESXi so you can boot a MacOS virtual machine from it

Posted by jpluimers on 2022/01/13

This is totally opposite to yesterday’s Secure Boot post: [Wayback/Archive.is] shanyungyang/esxi-unlocker: VMware ESXi macOS

macOS Unlocker V3.0.2 for VMware ESXi
=====================================

1. Introduction
---------------

Unlocker 3 for ESXi is designed for VMware ESXi 6.5, 6.7 and 7.0

The patch code carries out the following modifications dependent on the product
being patched:

* Fix vmware-vmx to allow macOS to boot
* Fix libvmkctl to allow vSphere to control the guest

The code is written in Python as it makes the Unlocker easier to run and
maintain on ESXi.

+-----------------------------------------------------------------------------+
| IMPORTANT:                                                                  |
| ==========                                                                  |
|                                                                             |
| Always uninstall the previous version of the Unlocker before using a new    |
| version. Failure to do this could render VMware unusable.                   |
|                                                                             |
+-----------------------------------------------------------------------------+

2. Installation
---------------
Copy the distribution file to the ESXi host datastore using scp or some other
data transfer system. If you want to use the source version (i.e. from GIT) see
"5. Building" fist.

Decompress the file from the ESXi console or via SSH:

    tar xzvf esxi-unlocker-xxx.tgz

(xxx - will be the version number, for example, 300)

Run the command from the terminal:

    ./esxi-install.sh

Finally reboot the server.

3. Uninstallation
-----------------
Open the ESXi console or login via SSH and change to the folder where the files were extracted.

Run the command from the terminal:

    ./esxi-uninstall.sh

Finally reboot the server.

4. Notes
--------
A. There is a command added called esxi-smctest.sh which can show if the patch is successful. It must be run from a
terminal or SSH session. The output should be:

/bin/vmx
smcPresent = true
custom.vgz     false   32486592 B

Note: The uncompressed size reported for custom.vgz will vary depending on the ESXi version.

B. The unlocker can be temporarily disabled during boot by editing the boot options and adding "nounlocker".

5. Building
-----------
If you want to use a version which is not availbale as a distribution (e.g. the code from "master" branch)
you need to first build the package.

Checkout the repository:

    git clone https://github.com/shanyungyang/esxi-unlocker.git

(if you don't have git installed you can download ZIP archive from GitHub instead)

Enter the directory and build:
    
    cd esxi-unlocker
    ./esxi-build.py

If everything went correctly the ouput should be:

    ESXi-Build for macOS

    Timestamping files...

    Creating unlocker.tgz...
    etc/
    etc/rc.local.d/
    etc/rc.local.d/unlocker.py

    Creating esxi-unlocker-301.tgz...
    unlocker.tgz
    esxi-install.sh
    esxi-uninstall.sh
    esxi-smctest.sh
    readme.txt

The package you need to copy in the example above is esxi-unlocker-301.tgz (NOT unlocker.tgz!).

6. Thanks
---------

Thanks to Zenith432 for originally building the C++ unlocker and Mac Son of Knife
(MSoK) for all the testing and support.

Thanks also to Sam B for finding the solution for ESXi 6 and helping me with
debugging expertise. Sam also wrote the code for patching ESXi ELF files and
modified the unlocker code to run on Python 3 in the ESXi 6.5 environment.

History
-------
26/09/18 3.0.0 - First release
01/05/20 3.0.1 - Fix for ESXi 7.0
10/18/20 3.0.1 - Fix for ESXi 7.0 U1 (7.0.1)

(c) 2011-2018 Dave Parsons

–jeroen

Posted in Apple, ESXi6, ESXi6.5, ESXi6.7, ESXi7, Mac OS X / OS X / MacOS, Power User, Virtualization, VMware, VMware ESXi | Leave a Comment »

On my research list: “ESXi” “Secure Boot” – Google Search

Posted by jpluimers on 2022/01/12

On my research list: [Wayback] “ESXi” “Secure Boot” – Google Search.

Some links about it:

–jeroen

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

VMware ESXi and vSphere: vmNIC speeds are limited by your CPU and RAM speeds, only in part by the vNIC drivers

Posted by jpluimers on 2022/01/11

Still a lot of people think that network speed depends on the vNIC driver and vNIC speed settings.

This is not true: it mainly depends on CPU and RAM speeds as that is where the bottleneck of virtual network processing is.

What does matter is the VM/host overhead is far less when drivers use paravirtualisation (i.e. shortcutting calls from the guest OS to the hypervisor) like PVSCSI for disk or VMXNET3 for networking. This means that VMXNET3 has even more performance than E1000.

Read the rest of this entry »

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

Some links and graphs on ESXi capping/throtteling disk speeds

Posted by jpluimers on 2022/01/06

As promised in “Solution” on ESXi 6.7 smartinfo throwing error Cannot open device, here are a few links in capping throttling disk speeds by ESXi followed by a few graphs of my own:

My own observations on ESXi 6.7 update 3:

  1. One rsync operation:
    1 rsync from 860 EVO SSD to 960 PRO NVMe

    1 rsync from 860 EVO SSD to 960 PRO NVMe

  2. Two rsync operations:
    2 rsync from 860 EVO SSD to 960 PRO NVMe

    2 rsync from 860 EVO SSD to 960 PRO NVM

  3. Resume actions were about 10 times faster than the single rsync read speeds:
    Resume action

    Resume action

  4. Suspend actions were between 4 and 6 times faster than rsync write speeds:
    Start of suspend action

    Start of suspend action

     

    Finish of suspend action

    Finish of suspend action

For each rsync operation, I had a separate SSH session going, and the speed doubled.

The resume action of all Virtual Machines was almost a flat speed curve.

The suspend action of all Virtual Machines started fast (when all machines were suspending) and finished slower (when only the largest virtual machines were still suspending)

–jeroen

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

“Solution” on ESXi 6.7 `smartinfo` throwing `error Cannot open device`

Posted by jpluimers on 2022/01/05

After writing Some notes on ESXi smartinfo throwing error Cannot open device, I bit the bullet and experimented with disabling the vmw_ahci driver (shown as ahci in the storage adapters view), which forces the sata_ahci driver to be used (shown as ahci in the storage adapters view).

Poof! All problems were gone.

All? Not all: on the console and terminal, there seems to be some throttling going on, as I observed the read or write speed limit to be capped somewhere close to 60 MB/s. More on that in a future post.

Basically, the smartinfo trouble tripped me into thinking the device was bad, where I should have understood that the latency warnings in the vmkernel.log file indicated the vmw_ahci driver was the culprit. Oh well: never too old to learn.

References

I’m not alone on this; these posts also discuss latency issued:

This is different from the transfer speed issues that were part of ESXi 4, though I have a gut feeling there is some correlation:

On AHCI: Advanced Host Controller Interface – Wikipedia

On native drivers versus legacy drivers:

  • [Wayback] Troubleshooting native drivers in ESXi 5.5 or later

    A new native driver model feature is introduced in VMware ESXi 5.5 that replaces an older model that employs a Linux compatibility layer.

    In this article:

    • Drivers using the new model are referred to as native drivers
    • Drivers using the old model are referred to as legacy VMKLinux drivers

    This article provides troubleshooting information for the native driver model.

    The following inbox Native Drivers are included in default installation of ESXi 5.5: – See more at: http://www.virtuallyghetto.com/2013/11/esxi-55-introduces-new-native-device.html
  • [Wayback] ESXi 5.5 introduces a new Native Device Driver Architecture Part 2

    A new concept of driver priority loading is introduced with the Native Device Driver model and the diagram below provides the current ordering of how device drivers are loaded.

    As you can see OEM drivers will have the highest priority and by default Native Drivers will be loaded before “legacy” vmklinux drivers. On a clean installation of ESXi 5.5 you should see at least two of these directories: /etc/vmware/default.map.d/ and /etc/vmware/driver.map.d/ which contains driver map files pertaining to Native Device and “legacy” vmklinux drivers.

Steps

This is how you disable the native vmware_ahci driver:

  1. Suspend all virtual machines
  2. Bring the ESXi box into maintenance mode, for instance by running esxcli system maintenanceMode set --enable true
  3. On the console or terminal, run this:
    # esxcli system module set --enabled=false --module=vmw_ahci
    # reboot
  4. After booting, get the ESXi box out of maintenance mode, for instance by running esxcli system maintenanceMode set --enable false
  5. Power on all suspended virtual machines

To re-enable the native vmware_ahci driver (in case not all your SATA devices are recognised):

  1. Suspend all virtual machines
  2. Bring the ESXi box into maintenance mode, for instance by running esxcli system maintenanceMode set --enable true
  3. On the console or terminal, run this:
    # esxcli system module set --enabled=true --module=vmw_ahci
    # reboot
  4. After booting, get the ESXi box out of maintenance mode, for instance by running esxcli system maintenanceMode set --enable false
  5. Power on all suspended virtual machines

Suspending and unsuspending all virtual machines can be done on the console/terminal, see Source: VMware ESXi console: viewing all VMs, suspending and waking them up: part 5 how.

Results: storage adapters

With native vmware_ahci, the storage adapters are these:

Storage adapters with vmw_ahci enabled

Storage adapters with vmw_ahci enabled

With legacy ahci, the storage adapters are these:

Storage adapters with vmw_ahci disabled

Storage adapters with vmw_ahci disabled

What you see is that the Patsburg 6 Port SATA AHCI Controller has been split from a single vmw_ahci adapter in six separate ahci adapters.

Results: read/write speeds and latency when suspending/unsuspending all virtual machines

With vmware_ahci, the storage adapters are these:

Latency issues after resume/suspend cycle of all virtual machines: the latency stays up in the 15 millisecond region

Latency issues after resume/suspend cycle of all virtual machines: the latency stays up in the 15 millisecond region

With ahci, the storage adapters are these:

Latency after resume/suspend cycle of all virtual machines: the latency goes down to the 2 millisecond region

Latency after resume/suspend cycle of all virtual machines: the latency goes down to the 2 millisecond region

For both cases, the read and write rates are roughly the same (and OK for an EVO 860 SATA device). The latency drops a lot (and with prolonged vmw_ahci use goes up to like 15+ seconds, that is 15000+ milliseconds):

[Wayback] SSD 860 EVO 2.5″ SATA III 500GB Memory & Storage – MZ-76E500B/AM | Samsung US

Speeds are consistent, even under heavy workloads and multi-tasking allowing for faster file transfer. The 860 EVO performs at sequential read speeds up to 550 MB/s* with Intelligent TurboWrite technology, and sequential write speeds up to 520 MB/s. The TurboWrite buffer size* is upgraded from 12 GB to 78 GB.

–jeroen

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

On my research list: “ESXi 7” “kickstart” – Google Search

Posted by jpluimers on 2022/01/04

On my research list [Wayback] “ESXi 7” “kickstart” – Google Search.

Some links from it:

–jeroen

Posted in ESXi7, Power User, Virtualization, VMware, VMware ESXi | Leave a Comment »

Some notes on ESXi `smartinfo` throwing `error Cannot open device`

Posted by jpluimers on 2021/12/29

I wrote about the built-in smartinfo command before at NVMe and SATA health data on ESXi: some links to investigate.

It is at /usr/lib/vmware/vm-support/bin/smartinfo, which is not in the path. I used it recently after having trouble with some 2.5-inch SSD devices, of one which is listed below.

Some note on this error what smartinfo from ESXi throwed on some devices over time on various ESXi machines:

Failed to get SMART stats for t10.ATA_____Samsung_SSD_860_EVO_500GB_______________S3Z2NB0M529545P_____ error Cannot open device 
----------------------------------------------------- 

The same SSD sometimes had very big latency times:

2021-05-01T16:23:20.306Z cpu7:2097783)WARNING: ScsiDeviceIO: 1564: Device t10.ATA_____Samsung_SSD_860_EVO_500GB_______________S3Z2NB0M529545P_____ performance has deteriorated. I/O latency increased from average value of 59147
2021-05-01T16:23:20.306Z cpu7:2097783)WARNING: microseconds to 1274466 microseconds.
2021-05-01T16:23:20.306Z cpu7:2097783)WARNING: ScsiDeviceIO: 1564: Device t10.ATA_____Samsung_SSD_860_EVO_500GB_______________S3Z2NB0M529545P_____ performance has deteriorated. I/O latency increased from average value of 59150
2021-05-01T16:23:20.306Z cpu7:2097783)WARNING: microseconds to 2664445 microseconds.
2021-05-01T16:23:20.847Z cpu7:2097190)ScsiDeviceIO: 1530: Device t10.ATA_____Samsung_SSD_860_EVO_500GB_______________S3Z2NB0M529545P_____ performance has improved. I/O latency reduced from 2664445 microseconds to 526814 microseconds.
2021-05-01T16:23:38.477Z cpu5:2097783)ScsiDeviceIO: 1530: Device t10.ATA_____Samsung_SSD_860_EVO_500GB_______________S3Z2NB0M529545P_____ performance has improved. I/O latency reduced from 526814 microseconds to 116553 microseconds.
2021-05-01T16:24:01.380Z cpu9:2097674)NMP: nmp_ResetDeviceLogThrottling:3586: last error status from device t10.ATA_____Samsung_SSD_860_EVO_500GB_______________S3Z2NB0M529545P_____ repeated 1 times

[Wayback] “smartinfo” “error Cannot open device” – Google Search delivered mainly results around the old smartinfo.sh tool that is now replaced by the smartinfo binary:

[Wayback] “ESXi” “smart” “error Cannot open device” – Google Search returned no relevant results.

I think an 860 EVO 2.5-inch SSD is not on par running half a dozen Windows VM’s that have regular write actions, but I will later give this a try, though I doubt it will help as this is on a VMware 6.7 update 3 based system which should not have the vmw_ahci driver slowness:

[Wayback] NVMe SSD Fast, but SATA SSD slow ! – VMware Technology Network VMTN (hyphen fixes mine):

I have done the esxcli system module set --enabled=false --module=vmw_ahci and rebooted, and I got a small performance increase.  But still not what I thought.

It refers these other posts:

The system with this behaviour is on these versions:

# esxcli software vib list | grep ahci
sata-ahci                      3.0-26vmw.670.0.0.8169922             VMW     VMwareCertified   2021-04-03
vmw-ahci                       2.0.7-2vmw.670.3.143.17700523         VMW     VMwareCertified   2021-04-04

–jeroen

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

ESXi: editing /etc/vmware/hostd/vmInventory.xml to fix the datastore UUID for unavailable VMs

Posted by jpluimers on 2021/12/23

In case I ever need this on ESXi:

  1. Put first ESX host into maintenance mode, or disable automatic DRS.
  2. Migrate functioning VMs onto other hosts.
  3. SSH into ESX service console.
  4. cd /vmfs/volumes
  5. ls -l:
    [root@esx1 volumes]# ls -l
    drwxrwxrwt    1 root        1260 Nov 27 11:58 474c4a74-b4cc8c53-6e29-000423c3e840
    drwxrwxrwt    1 root         980 Nov 27 08:49 474c4aa2-772bdc66-e441-000423c3e840
    drwxrwxrwt    1 root        1260 Nov 27 11:58 474c955b-527b5a13-1417-000423c3e840
    lrwxr-xr-x    1 root          35 Nov 29 13:36 snap-00000002-VMFS11 -> 474c955b-527b5a13-1417-000423c3e840
    lrwxr-xr-x    1 root          35 Nov 29 13:36 VMFS11 -> 474c4a74-b4cc8c53-6e29-000423c3e840
    lrwxr-xr-x    1 root          35 Nov 29 13:36 VMFS13 -> 474c4aa2-772bdc66-e441-000423c3e840
  6. Note (or copy) the new UUID(s) of the datastore(s) on which the inaccessible VMs live.  You may need to look in the VMFS themselves to be sure which VMs live where.
  7. cd /etc/vmware/hostd
  8. cp vmInventory.xml vmInventory.xml-save
  9. Edit vmInventory.xml and change the UUID for the inaccessible VMs to the correct UUID for their datastores.  (If unsure which VMs are in which datastore, look in each datastore to ensure you have the right UUID for each VM).
  10. Save vmInventory.xml and exit the editor.
  11. To make ESX re-read vmInventory.xml:
    [root@esx1 hostd]# service mgmt-vmware restart
    Stopping VMware ESX Server Management services:
    VMware ESX Server Host Agent Watchdog [ OK ]
    VMware ESX Server Host Agent [ OK ]
    Starting VMware ESX Server Management services:
    VMware ESX Server Host Agent (background) [ OK ]
    Availability report startup (background) [ OK ]
  12. Verify all VMs are properly accessible.
  13. Bring the ESX host out of maintenance mode and/or return DRS to original settings.

Sample vmInventory.xml file with UUID paths for VMs in an NFS and a VMFS datastore:

[root@esx1 hostd]# more vmInventory.xml
<ConfigRoot>
  <ConfigEntry id="0006">
    <objID>112</objID>
    <vmxCfgPath>/vmfs/volumes/9f801592-14465f39/WinNFS8/WinNFS8.vmx</vmxCfgPath>
  </ConfigEntry>
  <ConfigEntry id="0027">
    <objID>608</objID>
    <vmxCfgPath>/vmfs/volumes/46e5a3bf-2d233fa0-1546-0014220f1381/houwin2003sp2-8/houwin2003sp2-8.vmx</vmxCfgPath>
  </ConfigEntry>
</ConfigRoot>

Note about restarting the VMware Management stack through service mgmt-vmware restart:

little addition: You can also use the dcui via ssh.

Just enter dcui in your ssh session. Then you can restart the management agents like on the local console.

To quit hit Ctrl+C

Running VMs won’t be affected

  • For troubleshooting ESXi connectivity issue, restart the management agents on your ESXi host. Warning: If LACP is configured on the vSAN network, do not restart[Wayback] Restarting the Management agents in ESXi (1003490)

    Restart Management agents in ESXi Using Direct Console User Interface (DCUI):

    1. Connect to the console of your ESXi host.
    2. Press F2 to customize the system.
    3. Log in as root.
    4. Use the Up/Down arrows to navigate to Troubleshooting Options > Restart Management Agents.
    5. Press Enter.
    6. Press F11 to restart the services.
    7. When the service restarts, press Enter.
    8. Press Esc to log out.

    Note: You can also restart services using the Host Client. In Host Client, select Host >> Manage >> Services and select the service to restart.

    Restart Management agents in ESXi Using ESXi Shell or Secure Shell (SSH):
    1. Log in to ESXi Shell or SSH as root.For Enabling ESXi Shell or SSH, see Using ESXi Shell in ESXi 5.x and 6.x (2004746).
    2. Restart the ESXi host daemon and vCenter Agent services using these commands:/etc/init.d/hostd restart/etc/init.d/vpxa restart
    Alternatively:
    • To reset the management network on a specific VMkernel interface, by default vmk0, run the command:esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0Note: Using a semicolon (;) between the two commands ensures the VMkernel interface is disabled and then re-enabled in succession. If the management interface is not running on vmk0, change the above command according to the VMkernel interface used.
    • To restart all management agents on the host, run the command:services.sh restart
    Caution:
    • If LACP is enabled and configured, do not restart management services using services.sh command. Instead restart independent services using the /etc/init.d/module restart command.
    • If the issue is not resolved, and you are restarting all the services that are a part of the services.sh script, take a downtime before proceeding to the script.
    • If NSX is configured in the environment, do not run the /sbin/services.sh restart command because this will restart all services on the ESXi host. If you need to restart the management agents on the ESXi host, restart vpxa, host.d, and fdm individually. If you also need to run the /sbin/services.sh restart command because restarting each management agent does not work, then migrate all the VMs off the ESXi host and put the host in maintenance mode if possible.
    • If you are unsure that NSX for vSphere is installed on an ESXi host, run this command to verify:
    esxcli software vib list –rebooting-image | grep esx-*
    Look for the following VIBs to determine if NSX is installed on the ESX host:
    vsip-esx
    esx-vxlan
    • If using shared graphics in a View environment (VGPU, vDGA, vSGA), do not use services.sh. This will shut down the xorg service which is responsible for graphics at the guest OS level. By ripping the graphics out of the guest OS you will in term cause the crash of your VDI workload using the shared graphics. Ensure you are using shared graphics to only restart hostd, and vpxa if you are not in maintenance mode.

When editing the inventory fails

If all else fails and all VMs need to be re-registered: [Wayback] Virtual machines appear as unknown in Inventory on host and invalid in vCenter Server (1031605)

 Symptoms
  • vSphere Client direct to host show virtual machine(s) as unknown.
  • The vSphere Client connected to vCenter Server shows virtual machine(s) as invalid.
  • No errors on storage or on vmkwarning.
  • All the virtual machines on the host are functional and responding.
 Resolution
To resolve this issue:
For ESXi 3.5, 4.x, 5.x, 6.x
  1. Log in to the VMware ESX/ESXi host as the root user. For more information on VMware ESXi 4.1 and ESXi 5.x Technical Support Mode, see Using Tech Support Mode in ESXi 4.1 and ESXi 5.x (1017910)
  2. To list all running virtual machines and their corresponding VMIDs, run these commands:vim-cmd vmsvc/getallvms
    cd /etc/vmware/hostd/
  3. Make a copy of vmInventory.xml file by running this command:cp vmInventory.xml vmInventory.xml.bak
  4. Stop the vpxa and hostd services by running these commands:/etc/init.d/vpxa stop
    /etc/init.d/hostd stop
  5. Rename the vmInventory.xml file by running this command:Note: This action unregisters all virtual machines from the host.mv vmInventory.xml vmInventory_xml.bak
  6. Start the vpxa and hostd services by running these commands:/etc/init.d/vpxa start
    /etc/init.d/hostd start
  7. Log in to vSphere Client and verify that the virtual machine Inventory is now displayed as blank.
  8. Use this command to register every virtual machine back to Inventory on the host:vim-cmd solo/registervm full_path_of_VMXFor Example: vim-cmd solo/registervm /vmfs/volumes/datastore_name/VM_directory/VM_name.vmx

–jeroen

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

VFrontDe/ESXi-Customizer-PS: PowerCLI script that greatly simplifies and automates the process of creating fully patched and customized VMware ESXi installation images

Posted by jpluimers on 2021/11/30

On my list of things to try, as it allows me to have an ISO at hand in case I ever need to quickly re-install a machine to the current patch level (for instance when the USB boot stick breaks down: these things happen in reality): [Wayback] VFrontDe/ESXi-Customizer-PS: PowerCLI script that greatly simplifies and automates the process of creating fully patched and customized VMware ESXi installation images

ESXi-Customizer-PS is a Powershell script that greatly simplifies and automates the process of creating fully patched and customized ESXi 5.x and 6.x installation ISOs using the VMware PowerCLI ImageBuilder module/snapin.

Requirements

  • A Windows computer (XP or newer) with Powershell 2.0 or newer
  • VMware PowerCLI version 5.1 or newer

You can get the code from [Wayback] ESXi-Customizer-PS/ESXi-Customizer-PS.ps1 at master · VFrontDe/ESXi-Customizer-PS.

The old site (which still has most of the documentation) can be reached at two places:

A video showing how to use it is below the signature.

The above links via [Wayback] Custom ESXi ISO with ne1000 driver for install on Intel NUC Frost Canyon – seanwalsh.dev.

 

Oh: you can check if you have a PXE, USB or HDD installation of ESXi via the steps here: Determining the ESXi installation type (2014558) | VMware KB.

More on a failing USB stick later…

 

–jeroen


Read the rest of this entry »

Posted in CommandLine, Development, ESXi6, ESXi6.5, ESXi6.7, ESXi7, Power User, PowerCLI, PowerShell, PowerShell, Software Development, Virtualization, VMware, VMware ESXi | Leave a Comment »

Some bash parameter propagation links that hopefully will work with ash/dash too

Posted by jpluimers on 2021/10/27

For my link archive; I started with [Wayback] dash get all parameters quoted – Google Search:

–jeroen

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