WilliamLam.com

How to restart the ESXi management network via command-line?

by // 11 Comments

A great question that was brought up on Twitter yesterday by Andreas Peetz who asked the following:

Is there a way to restart the mgmt network in ESXi via a cmd line? You can do this from the DCUI, but I want a script! 

There are a variety of reasons why you would want to restart the Management Network on your ESXi host and usually it is related to troubleshooting or configurations such as renewing the DHCP lease on a particular VMkernel interface. For Andreas, it was renewing the DHCP lease and this is actually a use case I have heard from others before. Currently, the only way to restart the Management Network for your ESXi host is using the DCUI (Direct Console User Interface) either through the console using iLO/iDRAC/etc. or remotely over SSH.

Andreas' question is not a new one and I have heard this ask in the past. I have even inquired about it when I was a customer but was told it was not possible and had to use the DCUI. I was not really satisfied with the answer I provided to Andreas, so I decided to do a bit of digging myself and ping some engineers. Apparently this functionality is actually exposed through a legacy command-line utility called esxcfg-vmknic in the ESXi Shell as well as locally/remotely via the ESXCLI network namespace which is used to manage the VMkernel interface (Thanks to Andres for mentioning ESXCLI method).

There are two flags that this command supports which is to enable and disable a VMkernel interface. This is actually what the DCUI is doing when you ask it to restart the Management Network and is very similar to restarting a service on a UNIX/Linux system, it first shutdowns the service and then starts it back up. Given this information, if you wish to restart the Management Network of your ESXi host you can specify the name of the Management Network portgroup and execute the enable operation immediately after performing the disable operation.

To do this from the command-line, you would add a ; (semi-colon) between the two commands so they are executed one after another to ensure your VMkernel interface is enabled after you have disabled it. Here is an example of the command:

esxcli network ip interface set -e false -i vmk0; esxcli network ip interface set -e true -i vmk0

Early Xmas gift from VMware - pyVmomi (vSphere SDK for Python)

by // 13 Comments

For vSphere customers and partners who use the Python programming/scripting language, Christmas may have just arrived early. I just found today, VMware has published an initial release of their vSphere SDK for Python called pyVmomi on Github this past weekend. A Python-based SDK has always been a very popular feature request among customers and partners that I have spoken with in the past. It looks like VMware Engineering has heard you loud and clear and have been working hard to get this released.

pyVmomi Github Repository:
https://github.com/vmware/pyvmomi

pyVmomi Pypi package:
https://pypi.python.org/pypi/pyvmomi

One of the nice things about releasing pyVmomi on Github versus trying to package it with a particular vSphere release is that the larger VMware community can contribute to the project as well as more frequent updates from VMware. This has also been quite successful for another popular VMware SDK called rbvmomi (vSphere SDK for Ruby) which is seeing a huge uptick with RVC (Ruby vSphere Console) which is built on top of rbvmomi and is a great tool for managing and troubleshooting VMware VSAN.

In this first release, you will notice there is a limited amount documentation and samples exercising the various capabilities of vSphere and you will see further enhancements in these areas with future updates. If there are specific things you would like to see or samples that you think would be useful to have or that you have built, feel free to file an issue or send pull requests to the pyVmomi Github.

If you wish to quickly get started, you can install pyVmomi using a variety of methods including pip, easy_install and pypi package. Below are the steps I took to install pyVmomi on my Mac OS X system using pip and git.

Step 1 - Install pyVmomi using pip by running the following command:

sudo pip install pyvmomi

Step 2 - Clone the pyVmomi Github repo to your system using Git by running the following command:

git clone https://github.com/vmware/pyvmomi.git

After the above command, you will have a folder called pyVmomi which contains the source code as well as the two sample scripts. You can contribute back if you create additional samples or enhancements to pyVmomi by simply sending a pull requests.

Try the getallvms.py sample run the following command:

python sample/getallvms.py --host mini.primp-industries.com --password [PASS]

To try the poweronvm.py sample run the following command:

python sample/poweronvm.py --host mini.primp-industries.com --password [PASS] --vmname [VM]

Hopefully we will see many more samples from VMware as well as from our customers who will be using the new SDK. If there is anything that is missing or things you would like to see, feel free to file an issue on pyVmomi Github repository.

Why is there a "No access" vSphere Role?

by // 5 Comments

vSphere's (vCenter Server & ESXi) authorization system includes several pre-canned Roles such as Read-Only, Administrator and Virtual Machine Administrator as an example. One of the roles that has intrigued me for awhile which is the "No access" role. This seems to be a really odd role to have, I mean what would you do with such a role if it does not have access to anything?

In a conversation I had last week with a fellow colleague, the "No access" role made its way into the conversation and I learned that there was a specific use case for this role, however it was unclear what that might have been. This go me interested and I decided to reach out to some folks to see if I can get to the bottom of this and the use case associated with it.

It turns out there are some customers who have some very interesting requirements in which they need to separate out users who have the Administrator role and prevent them from seeing and performing operations on specific vSphere Inventory objects. An example of this would be a vCenter Server with 4 vSphere Clusters where Admin1 can only see the first two Clusters and Admin2 can only see the last two Clusters and both users have the Administrator role.

To accomplish the above example, you can leverage the "No access" role in the following manner. As the "Uber" Administrator, you would assign both Admin1 and Admin2, lets call them Alan and Cormac the Administrator role at the vCenter Server level. This will grant them full access to the entire vSphere Inventory.

Now, to prevent Alan from seeing Cluster 3 & 4, we need to go into the Cluster object and add the "No access" role to both those objects. We do the same for Cormac but for Cluster 1 & 2. If we now login as the user Alan, we will see that only Cluster 1 & 2 are visisble.

If we login with the user Cormac, we can only see Cluster 3 & 4 as expected.

Although this may not be a common request in your environment, I can see some interesting use cases for having such a setup like on-boarding a new junior admin and wanting to provide them Administrative access to particular Clusters and removing the views for others they should not have access to.

I would like to thanks Rupam from our GSS organization for sharing the reasoning behind "No access" as well as a specific use case for the feature.