Monthly Archives: July 2014

Re-Ordering VMware Network Adapters the Right Way – Existing Installation Process

Note: Changing VMNIC names by editing the /etc/vmware/esx.conf file is not supported by VMware.We are not going to make any changes to the /etc/vmware/esx.conf file manually.

Using this method we will let VMware ESXi/ESX do it automatically.

These instructions are for VMware ESXi hosts with vSwitches or Port Groups already configured.

You can also use these instructions for many situation like any of these:

1) If you lost host network connectivity either after:
a) System BIOS update
b) Firmware update
c) Patch Upgrade/update
d) Add a new Network Card

Step # 1
Place the ESXi/ESX host into Maintenance Mode.
Step # 2
Remove all VMNICs from the virtual switches except vmnic0, which is used for management.(Note: Make a note and/or diagram of which VMNICs are assigned to which vSwitches.)
Step # 3
Shut down the ESXi/ESX host.
Step # 4
Remove/disable all NICs except vmnic0.a) On-board NICs can be disabled in the System BIOS.

b) NICs installed in PCI slots should be physically removed.

(Note: Make a note and/or diagram from which slot each Network Card was installed.)

Step # 5
Boot the server. At boot time, all removed/disabled VMNICs are removed from the /etc/vmware/esx.conf file.
Step # 6
Shut down the ESXi/ESX host.
Step # 7
Add/enable all required NICs.a) Enable the On-Board NICs in the BIOS.
b) Re-insert the PCI bus NICs into the slots they came from.
(Note: I do this one at a time, shutting down and restarting the ESXi host after adding back each NIC.

This way I can check that my order is correct. You can use this process to check after adding each NIC.)

(Note: You can verify this by going into the Direct Console User Interface (DCUI) Console.)

Step # 1 Login to the DCUI.
Step # 2 Under System Customization, select Configure Management Network.

Step # 3 Under Configure Management Network, select Network Adapters.

Step # 8
Boot the ESXi/ESX host.All VMNICs are assigned per segment, bus, slot, and function ID, and are ordered correctly.
Step # 9
Assign VMNICs back to the virtual switches they were assigned to before.
Step # 10
Exit maintenance mode on the ESXi/ESX host.
Step # 11
Now all of your Network Cards should be back into the system and correctly ordered.
More Information on how VMware ESXi/ESX deals with the Network Card ordering.
The PCI ID to VMNIC numbering relationship is determined at boot time and is automatically entered into the esx.conf file for persistence.

The ESXi/ESX host first scans the segment number, then the bus number, the slot number, and finally the function number. This order ensures that ports on the same multi-port NIC are numbered sequentially.

Initially, when ESXi/ESX is installed, the VMNIC order will be sequential. This may change over time as NICs are removed and other NICS are added. This can result in VMNIC ordering that is undesirable and not in sync with the naming convention on other ESXi/ESX hosts.




Re-Ordering VMware Network Adapters the Right Way – Fresh Installation Process

Note: Changing VMNIC names by editing the /etc/vmware/esx.conf file is not supported by VMware.We are not going to make any changes to the /etc/vmware/esx.conf file manually.Using this method we will let VMware ESXi/ESX do it automatically.

These instructions are for a VMware ESXi hosts without vSwitches or Port Groups configured.
This is a freshly installed ESXi host that does not have the Network Adapters in the correct order.

If you are not using a Dell iDRAC/HP iLO or other Remote Management Interface, you need to follow my other process “Existing Installation Process”, because we disable all Network Cards and you will not be able to access your ESXi host.

I have another Blog post on doing this process if you already have your vSwitches or Port Groups setup and configured.

Step # 1
Place the ESXi/ESX host into Maintenance Mode.(Note: If ESXi/ESX host has already been added to vCenter, if not then you can safely skip this step.)
Step # 2
Shutdown the ESXi/ESX host.
Step # 3
Physical Network Cards need to be physically remove from the system.(Note: Make a note and/or diagram from which slot each Network Card was installed.)
Step # 4
1) Boot into System BIOS to disable the On-Board Network Cards.
(Note: We disabled even our Mezzanine Card Slots, if using Blade Technology.)
2) Shutdown ESXi/ESX host.
Step # 5
Boot the ESXi/ESX host.(Note: At boot time, VMware ESXi/ESX will remove all removed and/or disabled Network Cards from the /etc/vmware/esx.conf file.)
Step # 6
Shutdown the ESXi/ESX host.
Step # 7
Add/Enable ESXi/ESX host Network Cards in the required order.1) Enable the On-Board Network Cards.Re-start the ESXi/ESX host.(Note: You can verify this by going into the Direct Console User Interface (DCUI) Console.)Step # 1 Login to the DCUI.
Step # 2 Under System Customization, select Configure Management Network.Step # 3 Under Configure Management Network, select Network Adapters.
Step # 8
Add your Physical Network Cards back into the same slots from which they were installed.(Note: You can add them back into the system one at a time. This way you can re-check them using the DCUI Console process.)Continue this process until you have all of your Network Cards back into the system.
Step # 9
Now all of your Network Cards should be back into the system and correctly ordered.
More Information on how VMware ESXi/ESX deals with the Network Card ordering.
The PCI ID to VMNIC numbering relationship is determined at boot time and is automatically entered into the esx.conf file for persistence.

The ESXi/ESX host first scans the segment number, then the bus number, the slot number, and finally the function number. This order ensures that ports on the same multi-port NIC are numbered sequentially.

Initially, when ESXi/ESX is installed, the VMNIC order will be sequential. This may change over time as NICs are removed and other NICS are added. This can result in VMNIC ordering that is undesirable and not in sync with the naming convention on other ESXi/ESX hosts.




Error Connecting to vCenter Server, using the vSphere Client after initial installation.

clip_image001

Full Error Message:

The vSphere Client could not connect to “your vCenter Server”.
You do not have permission to login to the server: your vCenter Server FQDN.

You will need to grant permissions for you domain account/group, before you can connect using your Domain Login credentials.
Step # 1
clip_image002
Login using Administrator@vsphere.local with your password that you created during installation.
Step # 2
clip_image004
Now that you are logged into your vCenter Server.

1) Click on your vCenter in the left pane, in my lab it is vc02.lab.local

2) Next, click on the Permissions tab.

3) Within the Permissions tab, you should see a VSPHERE.LOCAL\Administrator Account.

4) Right-Click anywhere on the white space, and select Add Permission…

Step # 3
In the Assigned Role Section, Click on the drop down box and select Administrator.

Leave Propagate to Child Objects “Checked”

Step # 4
In the Assign Permissions Section, click on the Add button.

On the Select Users and Groups, Click on the drop down box and select your current Domain.

In my case, I selected Administrator for my LAB domain.  If I were doing this in my production environment, I would select an VMware Administrator group and not an individual domain account.

Next, click the Add button, now you should see it in the Users: textbox area.

Then, click on the Check Names, and if you do not encounter any problems, click on the Ok button.

Once you click on the Check Names button, it will start validating users and groups.

Now, click on the Ok button again to exit.

Step # 5
Click File and Exit, so that you can logout of the VMware vSphere Client.

Now, try to log back in to vCenter, but this time use your Domain Login credentials.

If everything went perfect, you are now logged into vCenter with your Domain Credentials.

At this point I would start assigning my vCenter Permissions.




Here is a list of useful VMware Web Site Links

Here is a list of useful VMware Web Site related Links, that a VMware Systems Engineer shared with me and I wanted to share them with you.

For tech support:
http://www.vmware.com/support.html

 

Manage your support & licenses:
https://my.vmware.com/web/vmware/login

 

Patches:
http://www.vmware.com/patchmgr/download.portal

 

Trialware:
https://www.vmware.com/try-vmware/

 

VMWare on YouTube:
http://communities.vmware.com/community/youtube

 

WebCasts – including what’s new in 5.5:
http://webcasts.vmware.com/event

 

VMware Communities:
https://communities.vmware.com/welcome



VMware Workstation Technology Preview July 2014

The VMware Workstation team is providing public access to the latest VMware Workstation Technology Preview July 2014. This Tech Preview adds new features not included in the prior May 2014 Technology Preview in addition to general stability, application compatibility and usability improvements. The VMware Workstation Technology Preview includes changes to the core virtualization engine and new capabilities we are exploring.

VMware Workstation Tech Preview July 2014

We would appreciate feedback in the following areas:

  • New OS support including the latest versions of Windows, Ubuntu, Fedora, RHEL and OpenSUSE
  • VMware Hardware Version 11 including improved CPU support and upgraded USB 3.0 controller
  • Graphics memory configuration per virtual machine
  • Windows 8 Unity mode improvements
  • Create and boot virtual machine with EFI
  • Experimental performance tuning for VM suspend and resume

The VMware Workstation Technology Preview July 2014 is available to download HERE via our VMware Workstation Community. More details including installation instructions can be found on the What’s New page.

As with the prior Technology Preview May 2014, please post all of your feedback in the VMware Workstation Technology Preview 2014 community forum. Our Developers, Quality Assurance Engineers, Support Teams, Technical Writers, Product Marketing and Product Managers are all actively involved in the forums to ensure that your suggestions and comments get our attention.

Thank you!

The VMware Workstation Team

Author & Article Source: William Myrhang | VMware Blogs




VMware vCenter Orchestrator – vCenter Invalid Credentials

There are a few errors I’ve run into over the years that just stump me. Like you, I start doing some web searches and piecing things together. I cross-reference what I find with people I think may have more details for me. Well, I have recently had the “Invalid credentials” error in VMware vCenter Orchestrator (vCO) when viewing my vCenter Server instance in the vCO inventory. I hate to admit that it had me stumped for a while.

When adding my vCenter server in the vCO plugins section, the connection and credentials tested out just fine, so why was the VCO client giving me this error? 

vCO-vCenter-Invalid-Creds-01

Well, after doing some digging (and also cross-referencing the install-config guide), I found this describing when to use the “session per user” end point option: “Select this option only if your vCenter Server is in an Active Directory domain or if vCenter Server Single Sign-On is enabled. ” This setting was checked by default in my environment.

For background, I deployed the vCO appliance along with the vCenter Server appliance. I am also using the local root credentials for vCenter versus SSO.

As seen below, navigate the vCO configuration page (https://VCO-IP:8283), find the vSphere plugin, and click “Edit” on the appropriate vCenter Server instance.

vCO-vCenter-Invalid-Creds-02

Above “User name,” change the “session per user” selection to “share a unique session.”

vCO-vCenter-Invalid-Creds-03

Once you refresh the vCO client, you should see the error gone and you can now run workflows against this vCenter Server instance.

vCO-vCenter-Invalid-Creds-04

I hope this saves you some trouble! I spent more time than I care to admit, rebuilding environments and running multiple tests. It should have been something I never even missed from the start. :-)

Come back soon!

Get notification of new blog postings and more by following Harry on Twitter: @HarrySiii

Author & Article Source: Harry Smith | VMware Blogs