This post is to help address a how-to question that came in through twitter.
Essentially we have alarms in vCenter that are defined at every object level in the hierarchy, that is at the datacenter level , cluster level etc. By enabling or disabling a specific alarm, all of the child objects under the specific object will be effected with the change.
Given this behaviour, there is no direct method to maintain an “exclusion list” of objects that should *not* be affected by an alarm action.
This may be required if there are some exceptions wherein you need to filter out some VM’s from being monitored either due to them being less critical or due to a known condition.
In this walk through we shall disable the alarm at the root of the vCenter and then enable it back only on critical VM folder(excluding the VMs that do not need to monitored). In other words the objects outside of the folder will excluded from the alarm.
1- Login to vCenter from the vSphere Webclient and traverse to the vCenter object
2- Navigate to Monitor => Alarm Definitions and locate the specific alarm and disable it
3- Create a new folder -Ex: “crit-vm”
4-Leaving the VM’s t be excluded, the remaining VMs are multiselected and moved it to “crit-vm” folder
5-Enable the alarm back on the newly create ”crit-vm” folder
This will ensure that VM’s known for high memory usage or non critical VM’s that are designed/known to be affected due to resource constraints are not flagged with alarms unncessarily.
Comments/Feedback is welcome if there are easier alternatives or corrections..
Issue : You are deploying an OVA and it fails with an error message “Failed to deploy OVF” in the UI
On reading the detailed error message it indicates that the OVF descriptor was not available.
Cause : The OVF descriptor is ~40 KB file and may not be detected either due to file integrity of the downloaded OVA or while extraction incorrectely.
1- Validate integrity of the downloaded OVA, redownload if needed
2- Extract the OVF and manually check existence of OVF descriptor
3- Retry the deploy workflow, by manually selecting all the individual files associated to the OVA as below
4-Complete the workflow
Troubleshooting any performance related issue could be quite daunting. In any virtualized platform there are additional layers of indirection, hence we need to invoke a layered approach to troubleshoot and resolve such issues.
In this blog series, we shall breakdown the various components and how we can identify if a specific component is contributing to the storage latency.
Types of Storage
Storage can be broadly classified into three types,
- File-Based Storage
- Block storage
- Object Storage
Here is a nice blog outlining a definition and usecases for each of them Storage types
In the context of vSphere,
- A File-based storage is provisioned through NFS
- A block based storage is provisioned via iSCSI & Fiber Channel
- VVOLs and vSAN represent object based storage (although with subtle variations)
Now lets take a closer look at storage architecture and its components specifically around block storage.
Storage Architecture & Components
In the following diagram, we have broken down the components into 7 layers that can be isolated from a troubleshooting standpoint,
- In a typical block storage architecture, the most fundamental component is the hard disk. Hard disks have evolved over a period of time from magnetic disks to flash/solid state drives to NVMe. This forms our first layer.
- LUN/RAID groups – The hard disks are seldom presented in raw form to the servers in a datacenter setup, A set of hard disks are grouped together as logical units for optimizing performance, availability and security. These are typical referenced as LUNs(Logical Unit Number) in a SAN environment.
- The points of entry into a storage array are termed differently by different vendors as Controllers, Storage Processors, Directors or simply array front end ports. Server can connect directly to the controllers or through fabric switches.
- SAN/Fabric or Network Switch aids in multipathing and eliminating single points of failure my being an intermediary between the servers and storage array. In an FC SAN, these are termed as fabric switches , in the context of iSCSI or NFS, the existing network switches play the same role
- The physical connectivity is enabled through fiber channel cabling or ethernet cables for FC & iSCSI/NFS respectively
- Host Bus Adapter or Network Interface Cards are exit or entry points for I/O, subsequently the drivers enable the devices
- Hypervisor Layer introduces specific path/component within the kernel depending on the type of virtual disks associated to a VM, for instance an Virtual RDM follows a different I/O path from a standard vmdk within the kernel
Now that we have outlined the different components in the architecture, next we shall understand how to isolate a performance bottleneck at the different layers.