WilliamLam.com

vSphere 6.5b prevents vSphere Web Client logins for users w/o VC permissions

by // 8 Comments

A patch update was just released for vCenter Server 6.5, dubbed vSphere 6.5b. While glancing through the release notes, I caught one interesting "resolved issue" which I thought was worth sharing.

Users with no vCenter Server permissions can log in to the vSphere Web Client

Users without permissions can log in to the vSphere Web Client. Users can click the menu options, but no inventory is displayed.

Users with no permissions can no longer log in to the vSphere Web Client.

To enable the login, set the allow.user.without.permissions.login = true property in the webclient.properties file.

This particular behavior has been something that has confused a few customers and has been asked about since the introduction of vCenter Single Sign-On (SSO) service. The issue or rather the confusion is that prior to the SSO service, vCenter Server handled both authentication as well as authorization.

With SSO, authentication was no longer being handled by vCenter Server and this meant that even if you had no permissions in vCenter Server but you could authenticate to SSO (especially common when Active Directory is configured), you would still be allowed to login to the vSphere Web/H5 Client.


Although vCenter Server would does the right thing and does not display any inventory if you do not have any permissions, it was still not a desired behavior in addition to the confusion it caused. I was pleasantly surprised to see that we have changed this default behavior by disallowing logins to the vSphere Web/H5 Client if a user has no VC permissions. Below is the message you will receive if you try to login without VC permissions.


If you wish to revert to the original behavior, you can do so by simply adding the allow.user.without.permissions.login = true setting into the vSphere Web/H5 Client configuration file (webclient.properties) and restart the vSphere Web/H5 Client service. I think many of our customers will appreciate this fix as well as the new default behavior!

Virtual Hardware Plug-N-Play improvements in vSphere 6.5

by // 1 Comment

Have you ever noticed when you create a new VM, a floppy device is present in the GuestOS regardless if you had actually added one or not? If not, it is pretty simple to demonstrate. Create any Windows VM using a non-vSphere 6.5 release, install the OS and then power it on. You should now see a floppy device (A:) show up under "My Computer" as seen in the screenshot below.


Although this may look like a strange behavior (more on this in a bit), it is completely harmless as there is no real floppy device being presented to the VM. For many customers, this behavior was either unnoticed or it was just ignored as it did not bother them. However, there is a concern for some customers who must prove that the virtual hardware seen from the GuestOS matches the virtual hardware presented to the VM, usually for compliance purposes. To prevent a floppy device from showing up, you can edit the BIOS, but this generally does not scale as it must be done manually (no APIs exists) and even some of the BIOS editing utilities are fairly limited in their capabilities.

So why does this happen and how does vSphere 6.5 help?

In talking to one of our Principal Engineers about this topic, as this question comes up from time to time about disabling floppy devices in the BIOS. I came to learn more about the behavior described above and the nice enhancement that was introduced in vSphere 6.5 for Virtual Hardware Plug-N-Play.

[Read more...]

Cross vCenter Server operations (clone / migrate) between versions of vSphere 6.x

by // 7 Comments

When cross vCenter Server operations such as clone and migrate was first introduced in vSphere 6.0, it required that both the source and destination vCenter Server (includes ESXi hosts) to be running the same vSphere version. With the release of vSphere 6.5, this base requirement still holds true (e.g. vSphere 6.5 for both source and destination), especially when performing these operations using the vSphere Web Client where mixed-vSphere versions is not supported outside of a rolling upgrade.

Having said that, it is possible and supported to clone or migrate a VM across different versions of vSphere 6.x, for example a vSphere 6.5 and a vSphere 6.0 Update 3 environment. This can be accomplished by performing a xVC-vMotion or xVC-Clone operation using the vSphere API. For the the xVC-vMotion use case, I have extensively written about it here and here and with PowerCLI 6.5r1, the Move-VM cmdlet has even been updated based on my feedback to support this capability natively. Furthermore, you can even perform these operations across completely different vCenter Single Sign-On Domains, which enables a new level of mobility for your VMs and access to resources of independently deployed vCenter Server instances.

UPDATE (11/01/17) - The following VMware KB 2106952 has just been updated to reflect what is officially supported in terms of Cross vCenter Operations ( Clone / Migrate) across different versions of vSphere. The matrix in the KB reflects what has been tested by Engineering and one thing you may notice is that Cross vCenter vMotion/Clone from vSphere 6.x to vSphere 6.5 is only supported when running at least vSphere 6.0 Update 3. After speaking with the PM, the reason for this change is that pre-vSphere 6.0 Update 3, there were no pre-checks in the code to prevent Cross vCenter Operations for un-supported target hosts such as ESXi 5.5, which could lead to poor user experience as well as undefined failure scenarios. In addition, vSphere 6.0 Update 3 also includes additional enhancements to properly clean up failed provisioning operations which will make Cross vCenter Operations much more robust. Due to these reasons, though it is possible to perform Cross vCenter vMotion from earlier versions, it will not be officially supported. I have also updated my summarized table below to reflect what is in the VMware KB, but please use the KB as your official source of truth for what VMware supports.

To help make sense of the different combinations of vMotions and cloning operations, below are a few tables to help outline what is possible and supported today.

vMotion

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported N/A
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Cold Migrate

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported API
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5 Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Clone

Source vCenter Server Destination vCenter Server Supported  UI or API
vSphere 6.0 vSphere 6.0 Yes UI and  API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 No N/A
vSphere 6.0 Update 3 vSphere 6.5 No N/A
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No N/A
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Virtual Networking Migration

Source Type Destination Type Supported
VDS VDS Yes
VDS VSS No
VSS VSS Yes
VSS VDS Yes

Note1: vMotioning and/or cloning of VMs which uses the new vSphere Encryption feature introduced in vSphere 6.5 is not supported.

Note2: "Compute" only xVC-vMotion insufficient space issue has now been resolved with vSphere 6.0 Update 3, see this post here for more details.

Note3: xVC-vMotion is not supported on 3rd party switches as we can not checkpoint the switching state.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of: