WilliamLam.com

Quick Tip - vSphere 6.0 Update 3 resolves "Compute" only Cross-vCenter vMotion operation

by // Leave a Comment

Previously when a "Compute" only Cross-vCenter vMotion (xVC-vMotion) was initiated, which only migrates the VMs compute from one vCenter Server to another while maintaining its current storage configuration, an insufficient space error may be thrown under certain conditions. This behavior was due to the way vCenter Server used to calculate the available space on the destination vCenter Server.

Prior to vSphere 6.0 Update 3, vCenter Server used the Managed Object Reference (MoRef) ID of the vSphere Datastore determine whether the source and destination was the same. Even if you have the exact same vSphere Datastore mounted in both the source and destination vCenter Server, there was a good chance the MoRef ID will be different which then causes this calculation to occur. Now, the "insufficient space" error only occurs IF, the free space on the current vSphere Datastore is less than the size of the VM to be migrated which is why this behavior was only observed in some environments. Some customers workaround the problem by simply freeing up enough capacity which then allowed them to perform the operation.

The good news is this has now been resolved in the latest vSphere 6.0 Update 3 release which came out last Friday and has been outlined as one of the resolved issues in the release notes:

  • Attempts to perform an exclusive compute resource cross vCenter vMotion might fail.
    When a VM is migrated using vMotion or cold migrate from a vCenter to another vCenter and space available on datastore is less than size of the Virtual Machine Disk (VMDK), an error similar to the following is displayed:
    insufficient space

Rather than using the MoRef ID to determine if the vSphere Datastore is the same in both the source and destination vCenter Server, it is now using the datastore URL path. This means, if you want the correct behavior for a "Compute" only xVC-vMotion, you should ensure that the vSphere Datastore is mounted using the same name in both the source and destination vCenter Server.

How to forward other VCSA 6.5 logs to remote syslog server?

by // 6 Comments

As mentioned in my previous article (which I strongly recommend you review before continuing further), the VCSA 6.5 no longer uses syslog-ng as the syslog client and it has been replaced with rsyslog. This means the instructions outlined in my old article here is no longer valid on forwarding logs from a VCSA 6.5 system to a remote syslog server. Luckily, the process to forward logs within VCSA 6.5 is also pretty straight forward using rsyslog.

Disclaimer: This is not officially supported by VMware, please use at your own risk. For very large environments, forwarding additional logs can potentially impact the vCenter Server service, so please take caution in the logs you decide on forwarding and test in a lab environment before applying this across your environment.

To help provide a concrete example, I will be using a real world scenario that often comes up from customers on auditing failed vSphere Web Client login success/failures as well as SSO user creation, deletion and password changes. The following two log files provides us with this information which we will forward to our syslog server:

  • /var/log/vmware/sso/ssoAdminServer.log - Auditing SSO logins
  • /var/log/vmware/sso/vmware-identity-sts.log - Auditing SSO user changes

We will be making using of rsyslog Text File Input Module (imfile) which will allow us to process local log files in the VCSA.

[Read more...]

What logs do I get when I enable syslog in VCSA 6.5?

by // 17 Comments

The native remote syslog functionality in the vCenter Server Appliance (VCSA) for vSphere 6.5 introduces several new changes from vSphere 6.0. With some of the questions that I have been receiving on this topic, I figure it would be useful to take a closer look at some of the different behaviors and configuration differences. Hopefully by the end of this article, you will have a better understanding of the syslog capabilities in VCSA 6.5

Remote Syslog Configuration

In VCSA 6.0, to configure the remote syslog configuration, you needed to use the vSphere Web Client. Although this may have felt like a convenience, it also added an unnecessary dependency on both vCenter Single-Sign On (SSO) and the vSphere Web Client UI. In VCSA 6.5, the remote syslog configurations is now part of the VAMI UI (https://[VCSA]:5480) which is an out-of-band interface that can still function if either SSO or vCenter Server is down. Once you have saved your changes, the syslog client will automatically be restarted for the changes to go into effect. If you wish to disable the remote syslog functionality, simply click on the reset button.


Note: If you decide to use port 1514, I have found that you must use the TLS protocol rather than TCP or else it will not work.

[Read more...]