The last months we have had several issues with ESXi hosts going in a “Not responding” status. The VMs are still active and online in this scenario, but the ESXi cannot be managed. This also affets backup as it won’t be able to reach the VMs through the APIs.
Previously we have normally just restarted the management agents on the host and it has been able to connect to vCenter and after this we have managed to migrate the VMs off the host.
In a previous post I’ve talked about issues in the StoragePolicy and Tag cmdlets in PowerCLI. I found a workaround by ignoring certificate warnings and setting my date format to en-US.
Today I tried to replicate some Storage Policies from one vCenter to another and I found that I got new errors…
I can export the policies without issues, but when I try to Import the policy to the new vCenter I get the following error: “Object reference not set to an instance of an object”.
This weekend our primary OneView appliance crashed.
This particular OneView appliance handles 10 blade chassis and over 120 blade servers
As OneView handles only the management side of the hardware nothing in production was affected by this crash.
TLDR; There is a bug in version 3.10.04 which doesn’t delete expired sessions. This is fixed in version 3.10.07
A few troubleshooting steps was taken initially.
First we restarted the appliance, it took a while but it stopped when loading it’s resource managers and threw the same error We also gave it some more CPU’s and more RAM to see if it was a resource issue, after powering on the VM it eventually threw the same error Unfortunately we are not doing backups of the appliance from OneView.
We are using Storage Policies on all VMs in our environment and rely on those to give the VM’s the correct storage. Storage Policy based management is a key area for VMware going forward it seems, especially with things like vSAN and VVOL.
In addition to matching a VM and it’s storage we are using the policies to set limits on the VM’s. We have a shared environment and we have to have some limitation on the VM’s so that one VM couldn’t impact all the others.
I’m using the Scheduled Tasks functionality in Windows Server quite extensively. I have tasks for importing stuff to a database with Powershell scripts, running some cleanup scripts etc
Almost all of my scripts run on different intervals during the day. Some maybe just once a day and some might run every x minutes.
Recently I encountered a difference in the way Scheduled Tasks work on Windows Server 2012R2 (and below) and on Windows Server 2016.