There is not a whole lot of changes for kickstart configurations between ESXi 5.1 and ESXi 5.0, majority of the tips and tricks noted in the ESXi 5.0 kickstart guide are still relevant for ESXi 5.1. Below are a few new tips and tricks (some old) as well as a complete working ESXi 5.1 kickstart example that can be used as a reference.
Disabling IPv6 via Command-Line For ESXi 5.1 (Without Automatic Host Reboot)
IPv6 for the VMkernel interface is now automatically enabled by default for the latest release of ESXi 5.1 and you may have also noticed the additional IP Address in DCUI after the host boots up.
IPv6 support has been around for awhile now and you can enable IPv6 by using the old vSphere C# Client or the new vSphere Web Client. If you enable or disable IPv6, you will need to perform a system reboot for the changes to go into effect. You also have the ability to enable/disable it via the DCUI, which also has been around for awhile as well.
UPDATE: 07/20/15 - For ESXi 6.0, the VMkernel module is name is now tcpip4 instead of tcpip3.
There is one very important thing to note if you do enable/disable IPv6 on the DCUI, after you made your changes and you wish to apply, there is a very important confirmation box that is displayed.
Carefully read the last sentence which is underline in red "In case IPv6 has been enabled or disabled this will restart your host". If you are not careful in reading the confirmation screen, you may hit yes and your host will issue a reboot. If you are going to use the DCUI to enable or disable IPv6, make sure you do not have any running VMs on your host and you should already have your host maintenance mode when making configuration changes to your host.
In addition to the two methods listed above (vSphere Web Client/C# CLient and DCUI) you can easily enable/disable IPv6 using ESXCLI (my preferred method) and restart the ESXi host when you get a chance.
To view whether IPv6 is currently enabled, run the following ESXCLI command (ESXi 5.5 Update 1 the VMkernel module is now called tcpip4):
esxcli system module parameters list -m tcpip3
As you can see from the screenshot above, ipv6 property is set to 1 which means it is enabled.
To disable IPv6, you just need to set the property to 0, run the following ESXCLI command:
esxcli system module parameters set -m tcpip3 -p ipv6=0
We can now reconfirm by re-running our list operation to ensure the changes were made successfully. All that is left is to perform a system reboot, you can either type in "reboot" or use the new ESXCLI 5.1 command:
esxcli system shutdown reboot -d 60 -r "making IPv6 config changes"
Note: You can run the ESXCLI command locally on the ESXi Shell or you can run the same command remotely by specifying additional connection options & proxy through vCenter Server if you wish. Take a look here for additional connection options for ESXCLI.
How to Automate the disabling of the VAAI UNMAP primitve in ESXi 5
I just saw an interesting article on Jason Boche's blog about VMware's recall of the new VAAI UNMAP primitive for vSphere 5. VMware released a new KB article KB2007427 documenting the details along with a recommendation to disable the VAAI UNMAP primitive for now (a patch will be released in the future to automatically disable this until the issue is resolved).
One thing that caught my in the VMware KB article is to disable the VAAI UNMAP primitive, you need to manually login to ESXi 5 Tech Support Mode (SSH) to run the local version of esxcli command. This is trivial if you have several hosts, but it can be time consuming if you have several hundred hosts to manage. Even though the "VMFS3.EnableBlockDelete" is a hidden parameter that can not be seen using any of the supported utilities, you can enable and disable the property using the remote version of esxcli which is part of vMA 5 or vCLI 5.
Here is an example of the command when connecting directly to an ESXi 5 host:
esxcli --server himalaya.primp-industries.com --username root system settings advanced set --int-value 1 --option /VMFS3/EnableBlockDelete
Here is an example of command when connecting to vCenter Server:
esxcli --server reflex.primp-industries.com --vihost himalaya.primp-industries.com --username administrator system settings advanced set --int-value 1 --option /VMFS3/EnableBlockDelete
As you can see, you can easily wrap this in a simple for-loop to disable the VAAI UNMAP primitive. So here is a script to help with exactly that called vaaiUNMAP.sh
The script accepts 4 parameters:
- A list of ESXi 5 hosts to enable or disable VAAI UNMAP primitive
- Name of the vCenter Server managing the ESXi 5 hosts
- vCenter auth file which contains the username/password
- 0 to disable or 1 to enable VAAI UNMAP primitive
The auth file is just a file that contains the following:
VI_USERNAME=administrator
VI_PASSWORD=y0mysuperdupersecurepassword
Here is an example of disabling VAAI UNMAP primitive on 3 ESXi hosts being managed by a vCenter Server:
To help extract all ESXi 5 hosts from your vCenter Server, you can use the following vSphere SDK for Perl getESXi5Hosts.pl
Here is an example of running the script and just save the output to a file:
One of the unfortunate thing about the VMFS3.EnableBlockDelete is that it is a hidden parameter along with others, so it will not automatically display when using local or remote ESXCLI, but thanks to Craig Risinger, you can still get the information using the remote ESXCLI by specifying the --option parameter which is great because you do not need to login to the ESXi Shell to retrieve the information.
esxcli --server himalaya.primp-industries.com --username root system settings advanced list --option /VMFS3/EnableBlockDelete
I would also recommend adding an entry into your ESXi 5 kickstart to automatically disable VAAI UNMAP by default until a fix is released.
%firstboot --interpreter=busybox #disable VAAI UNMAP primitive esxcli system settings advanced set --int-value 0 --option /VMFS3/EnableBlockDelete
- « Previous Page
- 1
- …
- 8
- 9
- 10
- 11
- 12
- 13
- Next Page »