Understanding VMWare PSA and NMP

Pluggable Storage Architecture (PSA)

To manage storage multipathing, ESX/ESXi uses a special VMkernel layer, Pluggable Storage Architecture (PSA). The PSA is an open modular framework that coordinates the simultaneous operation of multiple multipathing plugins (MPPs). PSA is a collection of VMkernel APIs that allow third party hardware vendors to insert code directly into the ESX storage I/O path. This allows 3rd party software developers to design their own load balancing techniques and failover mechanisms for particular storage array. The PSA coordinates the operation of the NMP and any additional 3rd party MPP.

  

Native Multipathing Plugin (NMP)

The VMkernel multipathing plugin that ESX/ESXi provides, by default, is the VMware Native Multipathing Plugin (NMP). The NMP is an extensible module that manages subplugins. There are two types of NMP subplugins: Storage Array Type Plugins (SATPs), and Path Selection Plugins (PSPs). SATPs and PSPs can be built-in and provided by VMware, or can be provided by a third party.

If more multipathing functionality is required, a third party can also provide an MPP to run in addition to, or as a replacement for, the default NMP.

VMware provides a generic Multipathing Plugin (MPP) called Native Multipathing Plugin (NMP).

What does NMP do?

• Manages physical path claiming and unclaiming.
• Registers and de-registers logical devices.
• Associates physical paths with logical devices.
• Processes I/O requests to logical devices:
  • Selects an optimal physical path for the request (load balance)
  • Performs actions necessary to handle failures and request retries.
• Supports management tasks such as abort or reset of logical devices

MPPs that are not implemented as SATPs or PSPs can be implemented as MPPs instead. MPPs run side by side with NMP. An example of that is EMC PowerPath/VE. It is certified with vSphere 4.x and is planned for vSphere 5

VMware storage device managed path policies

Managing Path Policies

For each storage device managed by NMP  an ESXi host uses a path selection policy. The following path policies are supported by default.

Private VLAN quick refresher

The following table shows the traffic which can flow between all these ports.

]

• Promiscuous port (P-Port): The switch port connects to a router, firewall or other common gateway device. This port can communicate with anything else connected to the primary or any secondary VLAN. In other words, it is a type of a port that is allowed to send and receive frames from any other port on the VLAN.
• Host Ports:
  • Isolated Port (I-Port): Connects to the regular host that resides on isolated VLAN. This port communicates only with P-Ports.
  • Community Port (C-Port): Connects to the regular host that resides on community VLAN. This port communicates with P-Ports and ports on the same community VLAN.

Lowest level of the permission heirarchy for Content Library.

When assigning a user the Content Library administrator role, what is the lowest level of the permission heirarchy that this role can be granted to the user and still allow them to create a Content Library? What if Content Libraries are not visible.

What is a possible solution?

Apply at the global permission level.  Assign the user the read-only role at the global permission level.

vSphere objects inherit permissions from a parent object in the hierarchy. Content libraries work in the context of a single vCenter Server instance. However, content libraries are not direct children of a vCenter Server system from an inventory perspective.

The direct parent for content libraries is the global root. This means that if you set a permission at a vCenter Server level and propagate it to the children objects, the permission applies to data centers, folders, clusters, hosts, virtual machines, and so on, but does not apply to the content libraries that you see and operate with in this vCenter Server instance. To assign a permission on a content library, an Administrator must grant the permission to the user as a global permission. Global permissions support assigning privileges across solutions from a global root object.

The figure illustrates the inventory hierarchy and the paths by which permissions can propagate.

vSphere Inventory Hierarchy

Global Permissions

Global permissions are applied to a global root object that spans solutions, for example, both vCenter Server and vCenter Orchestrator. Use global permissions to give a user or group privileges for all objects in all object hierarchies.

Each solution has a root object in its own object hierarchy. The global root object acts as a parent object to each solution object. You can assign global permissions to users or groups, and decide on the role for each user or group. The role determines the set of privileges. You can assign a predefined role or create custom roles. See Using Roles to Assign Privileges. It is important to distinguish between vCenter Server permissions and global permissions.

vCenter Serverpermissions	In most cases, you apply a permission to a vCenter Server inventory object such as an ESXi host or a virtual machine. When you do, you specify that a user or group has a set of privileges, called a role, on the object.
Global permissions	Global permissions give a user or group privileges to view or manage all objects in each of the inventory hierarchies in your deployment. If you assign a global and do not select Propagate, the users or groups associated with this permission do not have access to the objects in the hierarchy. They only have access to some global functionality such as creating roles.

Add a Global Permission

You can use global permissions to give a user or group privileges for all objects in all inventory hierarchies in your deployment.

Use global permissions with care. Verify that you really want to assign permissions to all objects in all inventory hierarchies.

Prerequisites

To perform this task, you must have .Permissions.Modify permission privileges on the root object for all inventory hierarchies.

Procedure

1	Click Administration and select Global Permissions in the Access Control area.
2	Click Manage, and click the Add permission icon.
3	Identify the user or group that will have the privileges defined by the selected role. a From the Domain drop-down menu, select the domain where the user or group is located. b Type a name in the Search box or select a name from the list. The system searches user names, group names, and descriptions. c Select the user or group and click Add. The name is added to either the Users or Groups list. d (Optional) Click Check Names to verify that the user or group exists in the identity source. e Click OK.
4	Select a role from the Assigned Role drop-down menu. The roles that are assigned to the object appear in the menu. The privileges contained in the role are listed in the section below the role title. For the issue above assign the user the read-only role.
5	Leave the Propagate to children check box selected in most cases. If you assign a global and do not select Propagate, the users or groups associated with this permission do not have access to the objects in the hierarchy. They only have access to some global functionality such as creating roles.
6	Click OK.

vSphere 6 vCenter error: You do not have permission to view this object or this object does not exist

vSphere 6 vCenter error: You do not have permission to view this object or this object does not exist

Windows AD account being used may not be administration member of the vsphere.local domain identity source domain provided by the vCenter Single Sign-On system.

Solution:


Log onto vCenter using the administrator account for the vsphere.local identity source domain provided by the vCenter Single Sign-On system.  This account was configured during the vCenter installation.

In vSphere web client, navigate to Administration -> Single Sign On -> Users and Groups -> select the ADMINISTRATOR group name and add the Windows AD domain account or group to be used for administration of the vSphere infrastructure.

Logout and re-login with the Windows AD account used above.

LDAP and SSO in vSphere 6

Vsphere web client -> Administration-> Single Sign-On -> Configuration -> Idemtity Source

Add the AD LDAP information.

Username can be a service account limited to accessing the LDAP.

Domain Alias is the NETBIOS domain name.





You can specify the identity source a a default.

Virtual Storage Area Network (VSAN) on ESXi 6

For shared storage, no need for separate dedicated storage solution.

Each ESXi hosts contributes some of the disk storage resources.  Minimum of 3 ESXi hosts required.
SSD drive is recommended.  In vSphere 6, all drives can be SSD or flash.  More flash disks means better performance and more HDD means more datastore capacity.

A logical virtual SAN datastore to store VM files .

VSAN requirements:

* At least 3 ESXi hosts
* VMKernal ports enabled for VSAN - Create a dedicated VMKernal port for VSAN on standard or distributed switch with plenty of uplink bandwidth.
* Cluster enabled for VSAN.  Virtual cluster must contribute at least 1 flash disk. Number if HDD disk host contributes must be >= to number of flash disk it contributes.
* Create disk groups
* Allocate disks




 For each ESXi host, VMKernal ports enabled for VSAN - Create a dedicated VMKernal port for VSAN

 Cluster enabled for VSAN (Temporarily, Turn off vSphere HA to turn on/off virtual SAN)

Create disk groups

Select eligible disks

Flash cache drive not counted towards the total disk vSAN storage