Auteursarchief: RobinP

No WIFI card found on your MacBook air

My daughter has a MacBook Air, she is using it for schoolwork, gaming and watching Netflix.

She came to me because her MacBook Air was no longer able to access the WIFI network. I noticed that the WIFI card was no longer visible under System Preferences>Network>WIFI

At first I tried to reenable the WIFI card via a Terminal Session but the card was not visible via the Terminal session.

Next suggestion was to reset the NVRAM (nonvolatile random-access memory), this is a small amount of memory that your MacBook uses to store certain settings and access them quickly.

Settings that are stored in NVRAM include sound volume, display resolution, startup disk selection, time zone, and recent kernel panic information.

To reset the NVRAM of your MacBook you need to shut down your MacBook, then turn it on and immediately press and hold these four keys together: Option, Command, P, and R. You can release the keys after about 20 seconds, during which your Mac might appear to restart.

When her MacBook had finished booting up the WIFI was available again and connected.

VMware vCenter upgrade, Test RPM transaction failed

Geef een reactie

VMware has identified a security thread within vCenter. An upload vulnerability in vCenter’s Analytics service allows attackers to run arbitrary code on vulnerable servers. On a scale of 1 to 10 in terms of impact, the vulnerability, CVE-2021-22005, is rated 9.8. “The implications of this vulnerability are serious and it will only be a matter of time, probably minutes after the announcement, before working exploits appear,” VMware said on September 21. The thread has been registered by VMware under VMSA-2021-0002.

To mitigate the security issue you need to upgrade your vCenter instance to version 7.0U2d build 18455184.

At a customer I am upgrading a vCenter from version 7.0.1.00100 to 7.0.2.00500. This version was released on September 16, VMware confirms in knowledge base article 85717 that this version fixes the above mentioned issue.

To install the update you need to logon to the vCenter Server Appliance Management Interface (VAMI). To access the VAMI you need to browse to https://vcenter.fqdn:5480. In the left side menu click on Update.The vCenter updates are cumulative so click on the latest version (in this case that is version 7.0.2.00500), and click on “Stage and Install””.

The update starts running.

But after a couple of minutes the installation fails and the installation is stuck in an infinity loop.

To break trough this loop you need to close the browser and logon to the vCenter via SSH.

After you logon you enter “Shell” to launch the BASH (Unix) Shell. Enter to following command to delete the state file that is causing the loop.

“rn /etc/applmgmt/appliance/software_update_state.conf”

When the file is deleted you need to reboot the vCenter Appliance.

After the reboot you execute the following command from the appliance shell: “software-packages install –url –acceptEulas”. Next you are prompted to enter SSO password for the administrator@vsphere.local account.

After some patient waiting the message appears that the installation process was successful.

When you log back into vCenter you can confirm that vCenter is now upgraded and the security thread is mitigated.

File locks on vSphere

Geef een reactie

In a project we where starting an action to export a VM to an OVF file. We launched the export from the vSphere WebClient. During the export action the file stream failed and we cancelled the export action. Because we where running into a time restriction with the allowed time frame we wanted to boot the machine so it would be available to the end users.

Once we booted the machine we received the following error: File system specific implementation of Ioctl[file] failed. This resulted in not being able to boot the machine.

Together with VMware Support we where able to resolve this issue by identifying what was locking this VM files, and remove the lock.

With the command lsof | grep vm name we get a list of the current locks on the files for this VM. In the above screenshot you can see that the vpxa process is still locking the files. The process that is locking the VM files (vpxa) is the vCenter Agent Services.

With the kill –9 67866
The –9 switch means, the process will be killed by the kernel. This command cannot be ignored by the OS.

After the kill command we run the lsof command to be sure that the process is gone. We are now able to boot the machine.

Reset VMware ESXi root password

Geef een reactie

The root account is the only login account to vSphere ESXi. There is no extra account to create a backdoor to logon to vSphere ESXi when the root password is lost. When a vSphere ESXi host is added to a vCenter instance, management of the host is primary done via vCenter. Troubleshooting ESXi is done primarily on the command line via an SSH connection. By default the SSH service is stopped. To start the SSH service you have to access the server via vCenter Host>Configure>System>Services. When you don’t have the root password for the vSphere ESXi host you have to follow the following procedure.

This procedure uses the Host profile functionality that is only available when you have an Enterprise license. If you have lost the root password but you don’t have an Enterprise license you have no other option but reinstall the host.

Lees verder →

VMworld 2021 Top 10 session to watch

Geef een reactie

It is that time of the year again to start looking forward to VMworld 2021. Due to the ongoing Covid-19 pandemic VMworld 2021 will again be “fully virtual” again.

The upside to a virtual event is that you don’t need to walk across a big conference complex to get from one session to another. You can follow the conference from the luxury of you own chair and desk. Poor your own drink of choice, sit back and relax and take in all the information on VMware latest and greatest from your own home. Because VMworld 2021 will be fully virtual, like last year that will make it easier for people to attend since you don’t need to arrange travel (flight/hotel) to attend VMworld.

Lees verder →

VIBS Error vSphere ESXi upgrade

Geef een reactie

Recently I was upgrading vSphere ESXi host from version 6.5.0 (7388607) to version 7.0.1. vCenter for this environment is upgraded to version 7.0.2.0000. at first I was trying to start the upgrade via VMware LifeCycle Manager but that resulted in an error indicating that the vCenter/LifeCycle Manager and the ESXi version where not working well together. In order to make progress I’ve accessed the server via it’s Integrated Lights Out (ILO) interface (HPE). Mounted the HPE ESXi image through ILO and booted the server.

During the upgrade progress the installer finds the drive where ESXi is installed. The next step is that the installer scans the current installation to see if an upgrade is possible. At this point the installer throw’s the following error.

Some investigation through the list the installer is showing here it is clear that these VIBs are for storage drivers that are no longer in use by ESXi.

The correct way to resolve these errors is to remove the unused storage drivers from ESXi. The next step is to reboot (F11) the server. When the ESXi is completely loaded I connect via SSH (I use the MobaXterm client).

With the following command we retrieve the name of the package:

esxcli software vib list | grep 4.0.2.1

The output shows that the package is called net-mst.

With the following command we remove this VIB.

esxcli software vib remove –n net-mst

After we remove all the VIBS that are mentioned in the above error, the VMware vSphere ESXi upgrade can be restarted.

Fixing an interrupted NSX-T Manager upgrade

Geef een reactie

The process for upgrading the NSX-T managers in an environment is a automated process that works through three managers and finishes the moment all the NSX-T managers are upgraded to the new desired version. Recently I was upgrading a NSX-T datacenter environment from version 3.1.0.0.017107177 to version 3.1.1.0.0.17483065 in my lab environment. The Edge nodes and Transport Nodes had already been upgraded successfully. While we where in the middle of upgrading the the NSX-T manager upgrade got interrupted and the NSX-T managers rebooted when the upgrade was not yet finished.

After all the nodes where back up again I was not able to logon to the Management environment, the designated Virtual IP (VIP) appeared to be down. When I connected to the first NSX-T Manager machine I was presented with a message indicated that the upgrade had not fully completed. When I executed the following command at the prompt Get upgrade progress-status I was presented with the following output:

The output shows that all the upgrade steps where completed successfully. When I connected to the second NSX-T manager machine I got the same output.

I then connected to the third NSX-T Manager, this one was not completed and caused the other NSX-T managers to remain in the upgrading status and the Management VIP to remain unavailable.

I first executed the command to see the available upgrade packages on the NSX-T Manager machine. get upgrade-bundle playbooks To resume the NSX-T Manager upgrade I executed the following command: resume upgrade-bundle VMware-NSX-appliance-3.1.1.0.0.17483186 playbook

The upgrade process resumed and completed successfully in a manner of minutes, after which the environment became functional again and Management VIP became accessible again.

Advanced Cross vCenter vMotion

Geef een reactie

VMware released vSphere version 7.0 U1c – 17327586 in December 2020. Next to the cool new features that is included in this version (This blog is al about one of those cool features) another very important reason to download and install this version of vSphere is that it closes a major security issue with previous versions. You can find more info on this here.

New features in this version of vSphere include the following:

Physical NIC statistics
Advanced Cross vCenter vMotion
Parallel remediation on host in clusters that you manage with vSphere Lifecycle Manager baselines
Third-party plug-ins to manage services on the vSAN Data Persistence platform

The VMware release notes have the following to say about this new feature:

With vCenter Server 7.0 Update 1c, in the vSphere Client, you can use the Advanced Cross vCenter vMotion feature to manage the bulk migration of workloads across vCenter Server systems in different vCenter Single Sign-On domains. Advanced Cross vCenter vMotion does not depend on vCenter Enhanced Linked Mode or Hybrid Linked Mode and works for both on-premise and cloud environments. Advanced Cross vCenter vMotion facilitates your migration from VMware Cloud Foundation 3 to VMware Cloud Foundation 4, which includes vSphere with Tanzu Kubernetes Grid, and delivers a unified platform for both VMs and containers, allowing operators to provision Kubernetes clusters from vCenter Server. The feature also allows smooth transition to the latest version of vCenter Server by simplifying workload migration from any vCenter Server instance of 6.x or later.

In this blog we will describe the process of importing VMs form a 6.7 vCenter to the updated 7.0.1 vCenter, making use of the cross vCenter technology. To prepare the environment for cross vCenter vMotion the vMotion network has to be configured with a gateway.

At the receiving side we tried to VMKping the sending host over the vMotion VMKernel port. When this failed we added a route to any foreign network across the gateway. When we retried the VMKping it was successful.

On the sending side we also configured the vMotion network with a gateway entry.

To start the process of performing a cross vCenter vMotion we right click on the cluster or ESXi host.

Click on Import VMs

Select source vCenter

Select the VMs you want to move.

Select the host to transfer the compute to.

Select the destination storage.

Select networks.

Select vMotion priority.

Ready to complete, click Finish.

The 7.0.1 environment also makes use of NSX-T network virtualization. Why is this important to mention? If you want to perform a roll back you can’t move a VM that is connected to a NSX-T managed portgroup to a none NSX-T managed portgroup. To remediate this issue you should create a none NSX-T portgroup with the same vLAN and add the VM you want to rollback to that portgroup.

Upgrade NSX-T Edge Nodes

Geef een reactie

VMware NSX-T delivers virtual networking in a software defined datacenter. In this article we are going to take a look at a VMware NSX-T environment that is ready for upgrading. In this blog we will upgrade the seven NSX-T Edge nodes. Let’s first take a look at what is the function of Edge nodes within the NSX-T architecture. An NSX Edge nodes are service appliances that run centralized network services that cannot be distributed to the hypervisors. An NSX Edge node can belong to one overlay transport zone and multiple vLan transport zones.

Today we are performing an upgrade for the Edge Nodes of a NSX-T environment. We are upgrading 7 Edge Nodes from version 3.1.0.0.017107177 to version 3.1.1.0.0.17483065. Before the upgrade we first preform a pre check of the environment, to make sure it is ready for the upgrade.

The above image shows that during the pre check there where 6 NSX-T Edge nodes with issues in the environment that could prevent a successful upgrade. Before we go any further we are going to investigate what those issues are.

By clicking on one of the affected NSX-T Edge nodes we can see that this node had two issues.

When we click on the blue two with the exclamation mark next to it we can drill further down to identify the current issue. The two alarms indicate that the password expiration is approaching for both the admin and root account.

To remediate this issue we will change the password for the Admin and Root account. To accomplish this task we connect to the NSX-T Edge node as root via SSH and execute the following commands:

/etc/init.d/nsx-edge-api-server stop
passwd admin
passwd root
touch /var/vmware nsx/reset_cluster_credentials
/etc/init.d/nsx-edge-api-server start

The Edge-TN-07 is now without errors, we proceed by checking the other NSX-T Edge nodes and preform the same actions on those nodes.

The other NSX-T Edge nodes are now also without errors.

In the upgrade window we select the Edge Node cluster and we start the upgrade.

Grab a drink (coffee) and wait for the progress bar to fill up to 100%

In the upgrade overview window we can now see that the seven NSX-T Edge nodes are now upgraded.

Awarded vExpert 2021

Geef een reactie

VMware vExpert is an honorary title VMware grants to outstanding advocates of the company’s products.

The vExpert title is held in high regards within the community due to the expertise of the selected vExperts. The vExpert honorees are sharing their knowledge towards enabling and empowering customers around the world with VMware’s software defined hybrid cloud technology adoption.

The vExpert award is for individuals, not for companies. The title last for one year. Employees of both customers and partners can receive the vExpert award. VMware started the vExpert program in 2009.

I am honored, happy and very proud that I am named vExpert 2021. I look forward to participate in the vExpert program and to continue to share knowledge about the VMware products and their different use cases.

My travels through the IT world

Robin Plomp

Auteursarchief: RobinP

No WIFI card found on your MacBook air

VMware vCenter upgrade, Test RPM transaction failed

File locks on vSphere

Reset VMware ESXi root password

VMworld 2021 Top 10 session to watch

VIBS Error vSphere ESXi upgrade

Fixing an interrupted NSX-T Manager upgrade

Advanced Cross vCenter vMotion

Upgrade NSX-T Edge Nodes

Awarded vExpert 2021