vSphere 6.0 issue: the VMware Client Integration Plugin has updated its SSL certificate in Firefox

I have noticed that with the recent releases of Mozilla Firefox and Google Chrome, the ability to launch VMware Client Integration Plugin was broken again. vSphere Web Client 6.0 constantly keeps showing a pop-up message as follows:

CIP Issue - 01

It happens because both browsers have removed support for the NPAPI plugins. So it drops some operations in the Web Client, such as deploying OVF or OVA templates and transferring files with the datastore browser.

The only workable solution for this issue I found is to use Firefox 52 Extended Support Release (32-bit version) which will support the NPAPI plugins until early 2018.

Alternatively, vCenter Server Appliance should be upgraded to the version 6.5 where “the VMware Enhanced Authentication Plug-in replaces the Client Integration Plug-in from vSphere 6.0 releases and earlier“, and the NPAPI support does not require.

21/06/2017 – Update 1: This message pops up also when the web-browser is configured to use a proxy server. Switching to ‘no proxy’ mode stops it from appearing.

A few noticeable changes to vROps 6.6 and Log Insight 4.5

With the recent releases of VMware vRealize Operations Manager 6.6 and Log Insight 4.5, VMware has made some changes to its products. They are as follows:

  • vRealize Operations Manager Plugin for vSphere Web Client should be removed after upgrading to vROps 6.6.vROps Plugin - 01
    In KB 2150394, VMware provides detailed instructions on how to do it for both vCenter for Windows and vCenter Virtual Appliance.
  • Native support for Active Directory in vRealize Log Insight is now deprecated.Log Insight - AD Integration - 01
    As per KB 2148976, VMware Identity Manager (VIDM) should be configured as an alternative. It is not confirmed yet whether VIDM is available for free for Log Insight users. More information will be posted on this thread on VMware Technology Network.I understand that this change widens the business scenarios for the product. However, for those of us who use Log Insight purely for collecting and analysing vSphere logs, it would be great to have Active Directory replaced with vCenter Single Sign-On (vCenter SSO). It sounds more logical.You can vote for the Log Insight integration with vCenter SSO on this link. It will be great if more people request this feature.

21/06/2017 – Update 1: VMware Identity Manager for Log Insight has been officially released and it is free! The VIDM virtual appliance is available on the Log Insight 4.5 download page.

VCSA 6.5: The mysterious dependency on the IPv6 protocol – Part 1

Starting from vSphere 4.1, IPv6 support has been introduced to the virtual platform from VMware. It is enabled in the vCenter Server Appliance by default and can be controlled in VCSA 6.0 and 6.5 from the Direct Console User Interface (Customize System > Configure Management Network > IPv6 Configuration).

IPv6-Issue-01

To my surprise, disabling IPv6 can cause some problems with the VCSA updates. I will explain this statement and provide a workaround in the paragraphs below.

Imagine your security team requires IPv6 to be turned off on vCenter Server. Following this call, you proceeded with the configuration change in DCUI.

IPv6-Issue-02

After rebooting the virtual machine, it all should work fine. Now, it is time to update the virtual appliance to a newer version. You downloaded a patch file, attached it to the VM, and started the update process from the VMware vSphere Appliance Management Interface.

When the server reboots, you will notice the Appliance Management User Interface is not accessible anymore. To troubleshoot this issue further, we need to open SSH session with the appliance and enable Shell mode.

Firstly, we need to netstat command to see if any service is listening on TCP port 5480. The command output does not show anything.

IPv6-Issue-03

The next step is to identify the service which provides the Appliance MUI and its current status. Fortunately, I have noticed an error message which is related to the problem when the operating system is booting up.

IPv6-Issue-04

Querying the vami-lighttp.service status shows the following results.

IPv6-Issue-05

So it is a duplicate parameter server.use-ipv6 in the configuration file which was causing this behaviour. To find this file, I was using a combination of rpm and egrep commands to filter the output.

IPv6-Issue-06

A quick search in /opt/vmware/etc/lighttpd/lighttpd.conf shows that there are two identical lines with IPv6 settings as follows:

IPv6-Issue-07

To fix this issue, I removed one of the lines, started the vami-lighttp.service and checked that the service works as expected.

IPv6-Issue-08

To be continued…

vSphere 6.x: The beauty and ugliness of the Content Library – Part 2

In part 1 of this mini-series, I wrote about some technical problems that I had had with the Content Library and provided the workable solutions for them.

Here I am going to touch the security aspect of this technology. Fortunately, there are no complications with restricting the virtual machine provisioning. It is just not as straightforward, as I or some of the readers would expect.

Issue #3 – Preventing users from provisioning the virtual machine from the Content Library

Affected platform: vSphere 6.0 and 6.5, all versions.

In vCenter, permissions are assigned to objects in the object hierarchy called vSphere Inventory Hierarchy. The individual permissions are called privileges. They are combined into roles which then allocated to the users.

The Content Library has its own set of privileges under All Privileges > Content Library. They designed to manage different settings related to the configuration of the object. There is a predefined role in vSphere called Content Library Administrator. The primary purpose of it is to give a user privileges to monitor and manage a library and its contents.

However, if you would like to restrict the VM provisioning from the Content Library and look at the long list, there is no privilege which can help to achieve this task there.

After doing some testing and discussing this subject with VMware GSS, the only solution we were able to come up was removing all Content Library privileges from the role and assigning it to the users on the vCenter Server level. In this case, users won’t be able to get access to the items in the Content Library. I was a bit frustrated with this limitation and even contacted the engineering team at VMware directly about the issue.

Coincidentally, I was working on restricting the VM provisioning from other sources: vApps and OVA/OVF Templates. It was then I realised it was actually possible to implement the complete solution to my problem.

As you might know, the Content Library keeps the VM template objects in OVF format.

CL-02

So I decided to play with the privileges that control deploying process from OVF templates. Surprisingly, it was a vApp import that helped me to achieve my goal. Happy days!

CL-03

Resolution: Remove All Privileges > vApp > Import privilege from the user role, as described in VMware KB 2105932.

vSphere 6.x: The beauty and ugliness of the Content Library – Part 1

The title of this blog post seems to be a bit provocative, and this has been done for a reason.

I believe many VMware engineers, including myself, were really excited about the Content Library feature introduced in vSphere 6.0. The product itself is not completely new for VMware, as it merges code from the content management feature of vCloud Director.

In What’s New in the VMware vSphere 6.0 Platform whitepaper, VMware states the following:

“The Content Library… centrally manages virtual machine templates, ISO images, and scripts, and it performs the content delivery of associated data from the published catalog to the subscribed catalog at other sites.”

Sounds really cool! Now we can centralise all objects that were previously residing on different datastores in one place, and manage them from vSphere Web Client.

In vSphere 6.5, VMware continues improving and polishing this feature:

“Administrators can now mount an ISO directly from the Content Library, apply a guest OS customization specification during VM deployment, and update existing templates.”

However, this article is not only about embracing the tool provided. 🙂 I would like to share with you three specific examples when it doesn’t work as expected, and possible workarounds.

Issue #1 – Provisioning a virtual machine template with the advanced parameters

Affected platform: vSphere 6.0 prior to Update 3.

It was a great surprise to know that provisioning a virtual machine from a VM template which has advanced parameters set can cause any problems in vSphere 6.0. Although the provisioning operation starts as expected, it shows an error message “Failed to deploy OVF package” at the end of it.

CL-Issue01-01

Unfortunately, the Error Report in vSphere Web Client wouldn’t be able to clarify the root cause of this event.

CL-Issue01-02

After contacting VMware GSS about this issue (SR # 16255562909) in late 2016, I had been advised that this bug would be addressed in vSphere 6.0 Update 3.

In March 2017 I updated my environment to this version and tested this feature, the VM creation was working smoothly. So it took almost two years for VMware since the Content Library feature was generally available to fix it.

Gladly, vSphere 6.5 does not have this problem at all.

Resolution: Update your environment to vSphere 6.0 Update 3 or newer version.

Issue #2 – Provisioning a virtual machine from the Content Library on the vSAN datastore

Affected platform: vSphere 6.5 Standard.

The issue is not related to the Content Library directly, rather to OVA/OVF provisioning. For some reason, when you create a new VM from the template in vSphere 6.5, it triggers “Call DRS for cross vMotion placement recommendations” task.

If you use vSphere 6.5 Standard, for which the DRS feature is not available, it causes this task to fail with the error message “The operation failed due to The operation is not allowed in the current state.”

CL-Issue02-01

CL-Issue02-02

The Error Report in vSphere Web Client looks similar to one in the picture below.

CL-Issue02-03

In the Known Issues in VMware vSAN 6.6 Release Notes, the vendor states the following:

VM OVF deploy fails if DRS is disabled
If you deploy an OVF template on the vSAN cluster, the operation fails if DRS is disabled on the vSAN cluster. You might see a message similar to the following: The operation is not allowed in the current state.

Workaround: Enable DRS on the vSAN cluster before you deploy an OVF template.

After doing some troubleshooting and trying different scenarios, the only difference with the provisioning task I was able to identify was the VM storage policy. Regardless the way the VM creation was initiated (from the OVA/OVF file, or Content Library template), it was the Virtual SAN Default Storage Policy call for the DRS to perform a cross vMotion check.

For example, if you set the VM storage policy in the Select storage dialogue box to “None”, the OVA/OVF file can be provisioned on the vSAN datastore.

CL-Issue02-04

The same happens for the VM template from the Subscribed Content Library when the VM storage policy is “None”.

Unfortunately, this trick doesn’t work with the templates in the Local Content Library.

So I decided to dig a bit dipper into the Content Library structure to see if anything can be done there.

The Content Library keeps its data in the contentlib-GUID folder. Each template has its own subfolder with the unique name. Inside the subfolder, there are few files: a descriptor (*.ovf) and one or more data files (*.vmdk).

In vSphere 6.0 those files are named as descriptor_GUID.ovf and disk-vdcs-Disk_Number_GUID.vmdk.

With vSphere 6.5 the files are self-explanatory: Template_Name_GUID.ovf and Template_Name-Disk_Number_GUID.vmdk.

CL-Issue02-05

I compared the descriptor files for the VM templates in the Local and Subscribed Content Libraries, and found they had different vmw:name values in the StorageGroupSection. For the Local Content Library it was a “Virtual SAN Default Storage Policy”, and for the subscribed one it was different.

CL-Issue02-06

It all led me to the idea of changing this descriptor for the VM template in the Local Content Library. So I could provision the VMs using one of the workarounds below.

Workarounds:

  • When provision from the OVA/OVF file, set the VM storage policy in the Select storage dialogue box as “None”,
  • You can provision from the Subscribed Content Library if it has the VM templates with the VM storage policy different from the “Virtual SAN Default Storage Policy”. Set the VM storage policy in the Select storage dialogue box as “None”,
  • You can provision from the Local Content Library if you edit the descriptor file for the VM template and replace the “Virtual SAN Default Storage Policy” with something else. Set the VM storage policy in the Select storage dialogue box as “None”.

Resolution: The support case has been opened, and I am waiting for VMware to resolve this issue. The ETA for this to be fixed is in vSphere 6.5 Update 1 (please refer to SR # 17393663302 when contacting VMware GSS for the future updates).

To be continued

Configuring static network in Photon OS

As more virtual appliances from VMware come with Photon OS, I would like to share a few simple workarounds to assign a static IP address and other network parameters to the virtual machines based on this operating system.

In Photon OS, the process systemd-networkd is responsible for the network configuration. You can check its status by executing the following command:

[ ~ ]# systemctl status systemd-networkd -l

It should give you an output similar to one in the picture below.

PhotonOS-Net-01

 

By default, systemd-networkd receives its settings from the configuration file 10-dhcp-en.network located in /etc/systemd/network/ folder. It has the following format:

[Match]
Name=e*

[Network]
DHCP=yes

I would recommend renaming this file to 10-static-en.network. So it will be easy to troubleshoot network issues in the future.

The file syntax is similar to what is used in Arch Linux. With few additional lines in the file, the network configuration can be set to our requirements. They are as follows:

  • In section [Network]
    • Address – the IP address and subnet mask in the format of XXX.XXX.XXX.XXX/YY
    • Gateway – an IP address of the default gateway
    • DNS – IP addresses of one or more DNS servers (space-separated values)
    • Domains – domain name(s) in FQDN format (space-separated values)
    • NTP – IP addresses or FQDNs of NTP sources (space-separated values).

An example of the static network configuration is shown below.

[Match]
Name=e*

[Network]
DHCP=no
Address=192.168.1.101/24
Gateway=192.168.1.1
DNS=192.168.1.21 192.168.1.1
Domains=testorg.local
NTP=0.au.pool.ntp.org 1.au.pool.ntp.org

The hostname of the system can be added to /etc/hostname file in FQDN format.

All changes should apply after rebooting the virtual machine. To test the results, we can use the following commands:

  • ip a – shows the IP addresses of the network interfaces

PhotonOS-Net-02

  • ip route – shows the routing table,

PhotonOS-Net-03

  • systemctl status systemd-timesyncd -l – shows time synchronisation status.

PhotonOS-Net-04

VMware Log Insight 4.0 and a slow login with the domain user credentials

Recently I was spinning up one more instance of VMware Log Insight 4.0 appliance in a branch office.

After enabling authentication against Active Directory, I have noticed it was relatively slow to log on to the Log Insight web interface. Moreover, when I pointed the Authentication Configuration to the local domain controllers the connection test was always failing.

li-ad-integration-02

I did not have enough time to troubleshoot this issue. So I decided to continue with this task later on.

Few days after the situation became even worth: domain users could not successfully log on to the appliance with the rolling wheel appears when pressing the login button.

li-ad-integration-01

Fortunately, I am not the first customer who came across of this issue. VMware has published an article “Unable to Log In Using Active Directory Credentials” which helps to locate the cause of this behaviour.

As suggested by the vendor, I looked through the records in the /storage/var/loginsight/runtime.log file and have found the following:

[com.vmware.loginsight.aaa.krb5.KrbAuthenticator] [Attempting Kerberos login: [[ user=XXXXX ], [ domain=XXXXX ]]]

[com.vmware.loginsight.aaa.krb5.KrbAuthenticator] [Kerberos login in 270817ms]

jsonResult: {“result”:”Cannot reach kerberos servers through TCP.“}

suggestion Please verify that your firewall settings allow TCP ports for active directory and kerberos.

Here I need to say that Active Directory has the hub-and-spoke topology with the domain controllers in the local and central sites being available to the clients.

By default, Log Insight could be pointed to the specific domain controllers, but not Kerberos servers. As a result, the Kerberos client uses auto-discovery as a mechanism to contact any server listed in the _ldap._tcp.dc._msdcs.[domain_name] namespace and delays with reaching ones that are available. To illustrate this, you can execute the following command from the Log Insight CLI:

~# netstat -A inet –program | egrep -i “kerberos”

It should show you all active UDP sessions which were initiated by the Kerberos client.

The next step is to find the way to narrow down a list of the domain controllers to those which are available to the client. VMware helps us with this task providing “advanced options for Active Directory integration in Log Insight beyond what is available in the administrative user interface.

The problem can be resolved with the following steps:

  1. Open https://loginsight_hostname_or_ipaddress/internal/config web-page.
  2. Add krb-domain-servers option with the appropriate values for the available domain controllers to the advanced configuration and save those changes.
  3. Restart Log Insight server.

After all those changes completed, you should be able to log on quickly to Log Insight with the domain account:

[com.vmware.loginsight.aaa.krb5.KrbAuthenticator] [Attempting Kerberos login: [[ user=XXXXX ], [ domain=XXXXX ]]]

[com.vmware.loginsight.aaa.krb5.KrbAuthenticator] [Kerberos login in 22ms]

03/03/2017 – Update 1: With the release of vRealize Log Insigh 4.3 the issue has been resolved. Please see the release notes for more details.