One of my customers had a issue with the native driver igbn (version 1.3.1-1OEM.600.0.0.2768847) that was automatic loaded after install the ESXi host using the Dell Custom install media for 6.5.
After pining with Dell and VMware support desks the result was to switch from the native driver (igbn) to the standard driver (igb)(vmlinux)
Here a link to a VMware KB that gives more info on how to enable or disable native drivers.
Here the steps I followed to disable the igbn driver.
* enable SSH and connect to the ESXi server with admin right
* esxcli system module list | grep igb
* esxcli system module set –enabled=false –module=igbn
* enable SSH and connect to the ESXi server with admin right
* esxcli system module list | grep igb
For a customer I was doing a POC where we had to link the vCenter form the VMware on AWS offering from VMware with an AD that we created in a VPC in AWS. At the moment we where doing the POC there was no really good documentian besides Configuring Hybrid Linked Mode (HLM) for VMware Cloud on AWS.This helped me but was missing steps like setting up the VPN between a VPC and VMware Cloud on AWS Management Gateway.
Following steps need to be executed.
VMware on AWS
VPC on AWS
AD in Amazon AWS
Step by step
Steps taken on Amazon AWS
Create accounts in AD
Before this can be done you need to create a EC2 instance with AD features activated to access the AD and create user accounts. Detailed step by step can be found here:
Create a VPN connection on AWS
This is done in 3 steps
On your VPC configuruation page you can create a Customer gateway
During the creation of this customer gateway you have to specify the public IP address you can find in your VMWare on AWS console for the vCenter in the Management Gateway
Virtual Private Gateway
Here you create a entry that points to your VPC
Here you link your Customer Gateway with your Virtual Private gateway.
During the configuration of your VPN connection in AWS you need to specify the subnet of your vCenter. This can be found on the VMware on AWS console
Now you can download the configuration file. I used the Microsoft Windows format as that was for me the most readable
In this document you find the 2 public IP addresses of you AWS VPC that can be used to create redundant VPN connection to your vCenter Management Gateway on your VMware on AWS console
Also the Passphrase needed to setup on the VMware on AWS side can be found in this configuration file
Steps taken on VMware on AWS console
Create IP SEC VPN connection on the Management Gateway on VMware on AWS Console. Use the public AWS ip address and Passphrase you find in the configuration file downloaded in previous step.
If requited a second VPN can be setup with the second AWS ip address found in the configuration file for redundancy.
Steps taken on the vCenter console
Login in the vCenter console
Go to Administration
Go to Linked Domains
Before you can can add an Identity Source you need to know the Distinguished Names (DN) for the groups and users. This can be found using the AD Users and Groups tool you can find on the machine used to manage AD users and groups
Now you know the DN, you can start linking the domain using an AD over LDAP connection
The ip address of the DNS can be found on your configuration page of AD on AWS
Now just a Administrator group of the AD needs to selected and you are up and running to grant permissions on the users or groups created in your AD.
Some screenshots are taken from Configuring Hybrid Linked Mode (HLM) for VMware Cloud on AWS.
In preparation for a SRM project we had to check and migrate all RDM files to VMDK.
Check which VM has RDM using PowerCLI
Get-VM | Get-HardDisk -DiskType “RawPhysical”,”RawVirtual” | Select Parent,Name,DiskType,ScsiCanonicalName,DeviceName
Verify how RDM is connected
Edit the settings of the virtual machine in the VMware web client (while the machine is running) to verify if the RDM is connected physical or virtual.
The field compatibility tells how the RDM is connected, Physical or Virtual
Convert Physical RDM to VMDK
A physical connected RDM cannot be converted online to a VMDK. Before that we need to convert the Physical RDM to a Virtual RDM. (VMware KB)
- Write down the drive letter of the disk in the guest OS
- Stop the Virtual Machine by doing a shutdown of the guest OS
Note-down the LUN ID of the RDM by going into the multipath settings of the RMD connected to the VM
Remove the RDM, and check “Delete fr
Re-Add the RDM but change the compatibility mode to Virtual. Be sure the RDMs are connected to a separate SCSI-Controller (VM-PARAVIRTUAL). Select the same LUN ID as the LUN disconnected.
- Power on the virtual machine
Go into storage management and check if the disk is online. Default it will be offline, bring it back online and connect it to the correct drive letter.
- No your server is up and running with a Virtual RDM wich can be migrated online to a VMDK (see Convert Virtual RDM to VMDK)
Convert Virtual RDM to VMDK
A Virtual connected RDM can be migrated to a VMDK while the machine is running. (VMware KB)
Check if the RDM is connected virtual. Edit the VM settings and check compatibility mode of the disk
Start the Storage migration of the virtual machine
Be sure you change the disk mode to Thin or Thick provisioned.
- If you select “Same format as source” then the RMD link file will be moved and NO migration to VMDK will happen.
If needed you can select this setting for each disk (and VMX config file) if you go into the advanced
Change the setting for each individual disk and start the migration
- After the migration check the disk to see it is a VMDK and not a RDM.
In a migration project to VMware vSphere 5.5 I bumped into duplicate MAC address issue (I found out after some investigation).
Some info on the setup.
There are ESXi hosts that we are migrating from 5.0 to 5.5. Some VM’s where 2 VM’s (VM1 and VM2) share the same MAC address (production and test machine).
On ESXi 5.0 these 2 VM’s can run together on the same ESXi host.
I want to move the VM’s to an already upgraded ESXi 5.5 host, the first VM (VM1 moves without any problems. ) For the second VM (VM2) I get following error during vMotion. Same error happens when I cold migrate the VM2 to the same host (ESXi 5.5) as VM1 and try to power VM2 on.
After some Google research I came across following blog
And adding the advanced setting to VM2 fixed the problem.
Before starting an upgrade at a customer site I was surprised how long an ESXi host can run. Here the proof.
A lot of my customers are running the vCenter Appliance version 5.1. Now they start to ask to upgrade this appliance to the newest version.
Here I will show you step by step the upgrade process. This is based on the VMware KB article 2058441
- Verify the time set on the old (VMware vCenter 5.1) appliance and the new (VMware vCenter 5.5) appliances are in sync. Be aware that from version 5.5 the clock on the appliance is always set to the UTC time zone. In the older version you could select your own tome zone. (see VMware KB)
- Be sure SSO (if installed on separate machine) is on the same version of the vCenter you want to upgrade to.
- If the vCenter database is external, make backup on the Database server. For backing up the embedded database look at this KB
- Create a snapshot of the OLD vCenter appliance before you start the upgrade procedure.
- First step of the upgrade procedure is deploying a fresh VM of the latest vCenter Appliance.
- Next is to configure the VM so that network connectivity is possible. The only thing that needs to be configured is IP address, subnet and gateway. The Original vCenter hostname and IP settings will be configured (copied) in the NEW vCenter Appliance based on the setting of the old vCenter.
- Connect to the old and new vCenter appliance via a supported web browser. (personal experience is that IE works and Chrome not! For the upgrade process.
On the NEW vCenter, Accept the EULA
- Next step in the upgrade process is to specify that you want to upgrade from a previous version
- Still in the NEW appliance, copy the local appliance code to the clipboard
On the OLD vCenter appliance, go to the Upgrade tab and paste the clipboard content in the text box and press the import button.
If the import was successful you get a notice and then copy the upgrade key back to the clipboard
On the NEW server paste the upgrade key in the bottom text box and proceed by clicking the next button.
There is an option to replace the SSL certificates on the NEW with those ones from the OLD vCenter Appliance
Now the new SSO password must be entered for the SSO administrator account firstname.lastname@example.org. (this was admin@system-domain in pre 5.5 versions)
Select now all the servers that need to check for compatibility with the new vCenter
After pressing next we see that we are ready to start the migration.
Pressing next will get following screen where you have to confirm that the upgrade process can proceed.
When you hit the start, the migration process start.
When you start the migration you will notice that the OLD vCenter server will be shut downed and the NEW vCenter server will have the IP configuration (hostname, IP settings) of the OLD ESX host.
After a successful upgrade you can start upgrading the ESXi hosts to the latest ESXi version.
- Can you login in the new vCenter Appliance via the Web Client and everything works fine you can remove the old vCenter Appliance from the inventory and from disk.
During an upgrade at a customer site we removed a Dell Appliance that was connected to vCenter. We dit remove the aplliance just by powering it off and then remove it from the entry. Normally you should do an unregister from in the Dell Appliance.
Now we saw that there was a plugin that could not be loaded.
After some research on the internet I passed by on the website of William Lam (virtuallyGhetto).
He has written a nice article that describes step by step how to fix the problem we had. Look here.
Problem solved, thanks William for the good work.
Today I am at customer site to upgrade en vSphere environment to the latest and greatest version of VMware vSphere 5.1.
We started the migration process by importing the VMware ESXi image we downloaded from the VMware download website.
In Update Manager we checked the server and saw that the server was not compliant with the new ESXi version so we could start the remediation.
After the remediation started we got the following message in Update Manager stating that the server was incompatible for this upgrade.
After some research on the internet I found following VMware KB 2034945 article.
As pointed out in this article the upgrade worked after a reboot of the ESX host.
Today I was asked to expand a local datastore of a ESXi 4.1. Expanding a disk is normally no problem when you are able to increate the size of the disk. After increasing the disk size you should be able to increate the partition size.
The ESXi was managed by a vCenter 5.0. On the storage adapter I did a RESCAN data stores after the disk size was increased. Then I went into the DATASTORE properties and I saw following
This above view was via a vCenter connection. Then I found following VMware KB which told me to make a direct connection to the ESXi host. After going to into the datastore properties I found out that I could increase.
When I selected this local datastore and finished the expansion I saw following result in the vSphere Client direct to the ESXi and via vCenter.
Lucky for the customer this expansion went OK.
Hopefully if you have this problem this KB article fixes also your problem.
Gert Van Gorp