virtuallyGhetto

Automation

Cross vCenter Workload Migration Fling v3.1

by Leave a Comment

Here is a small update to the Cross vCenter Workload Migration Fling which includes a couple of commonly requested features along with some bug fixes.

What's New in v3.1

  • Support for disk format conversion between Thick (Lazy Zeroed), Thick (Eager Zeroed) and Thin provisioning
  • Support for VM rename pattern for Clone operation
  • Fixed duplicated network selection when performing bulk migration
  • Fixed startup failure when a new home vCenter is specified as a command line argument

vSphere HTML5 and Standalone UI Client Support

In our 3.0 release, we added support for a native vSphere HTML5 (H5) Client experience which leverages new remote plugin framework that was introduced in vSphere 6.7 Update 1 and enables customers who prefer to use the H5 Client for their day to day use to also take advantage of the Cross vCenter Workload Migration Tool directly from the same UI. However, the addition of this new consumption UI created some confusion as some folks assumed this was the only mechanism. As stated in the release notes, we support both the new H5 UI as well as the standalone UI which many customers have been using for quite some time.

I suspect the confusion was due to the new CLI syntax which now requires specifying a vCenter Server endpoint to register. It is true that if you wish to use the new H5 Client integration, you will need to have a vSphere 6.7 Update 1 environment and provide credentials to that "home" vCenter Server. However, if you do not wish to use the H5 Client and you wish to use the old standalone client, you simply omit the vCenter Server registration details and the standalone client will work. In fact, even if you decide to use the H5 Client UI, you can always use the standalone client as that is the actual backend of the system.

Option 1: vSphere H5 Client Plugin

The following command will register the Cross vCenter Workload Migration Fling plugin to the specified vCenter Server:

java -jar xvm-3.1.jar --vcenter.fqdn=VCENTER-IP-OR-FQDN --vcenter.user=ADMIN-USER --vcenter.pass=ADMIN-PASSWORD

You will need to logout and then log back in to see the plugin which is located under "Menu" as shown in the screenshot below.

Option 2: Standalone UI Client

The following command will start the Cross vCenter Workload Migration Fling in standalone mode:

java -jar xvm-3.1.jar

You can then access the standalone client by opening a browser to localhost and port specified (default is 8443). You can always access the plugin locally whether you are using Option 1 or 2.

Forwarding vCenter Events into AWS EventBridge using vCenter Event Broker Appliance

by Leave a Comment

After attending Mike Deck's AWS reInvent session last year on Building event-driven architectures faster than ever with Amazon EventBridge, I could not help but draw a number of parallel concepts between AWS EventBridge and our recently released vCenter Event Broker Appliance (VEBA) Fling. I thought it was a very interesting solution and certainly wanted to give it a try as I think it could really benefit some of our customers, especially for those already using our VMware Cloud on AWS solution and being able to take advantage of the various AWS Services in an event-driven fashion.


In fact, one of the use cases that I had in mind was one that we had from a VMware Cloud on AWS customer who wanted to take a vCenter Event and forward that off to AWS CloudWatch. The solution that I had shared last year was utilizing our vRealize Log Insight Cloud solution which is integrated into VMware Cloud on AWS and leveraging its webhook functionality to call into a AWS Lambda function which would then process the payload directly into CloudWatch. Although this solution works and I know several customers who have implemented something similiar, I think EventBridge could certainly provide a more flexible way to integrate not only with CloudWatch but almost any AWS Service or 3rd party service.

[Read more...] about Forwarding vCenter Events into AWS EventBridge using vCenter Event Broker Appliance

Simulating the VMware Cloud on AWS API using Stoplight Prism Tool

by Leave a Comment

As more customers and partners on-board the VMware Cloud on AWS service, the topic of Automation has been coming up more frequently. There are a number of resources that are available to help users get started including here, here, here, here and here to just name a few.

Customers and partners can spin up 1-Node SDDC which includes the full stack (vSphere, vSAN and NSX-T), fully configured and ready for use for less than $8/hour (list price) and start exploring the rich APIs provided by the VMware Cloud on AWS service. Nothing beats playing with the real thing but we definitely have heard from customers and new developers that it would be nice to have the ability to test out some of the Automation prior to running against a real SDDC.

The VMware Cloud APIs is based on OpenAPI (formally Swagger) and has a very rich eco-system of tools that are available to developers and end-users. One really cool thing you can do with OpenAPIs is to "mock" or simulate the APIs just based on your API specification. This is really useful for API development but it can also come in handy for end users to be able to try out your APIs. Prism Mock by Stoplight is an OpenAPI mocking tool that was introduced to me by Jake Robinson.

Over the break, I finally found some time to play with this tool and I think this could be really useful for those wanting to get a taste of the various VMware Cloud APIs. As I have mentioned already, nothing beats the real APIs and there are some limitations with the mocking tool, so you should still consider using the real APIs when you are ready.

[Read more...] about Simulating the VMware Cloud on AWS API using Stoplight Prism Tool

Application Discovery in vSphere with VMware Tools 11

by 10 Comments

The holidays are just around the corner and hopefully everyone is taking some time off to spend with their families, I know I certainly will! As I start to wind down 2019, I like to use this time catch up on things in my backlog that I was not able to get to in the year. This can range from blog posts that I still need to read, to session recordings that I have attempted to watch but have only made it half way to random notes on topics to potentially investigate in.

When VMware Tools 11 was released back in September, I had noticed an interesting feature that was delivered as part of that release:

Added appInfo to publish information about running applications inside the guest.

I thought this might be something worth looking at when I found some time. One of the nice benefits of having VMware Tools de-coupled from a specific vSphere release is that VMware can now ship additional GuestOS capabilities to customers without requiring them to upgrade the entire vSphere infrastructure, which brings us to the new appInfo feature.

AppInfo is a new plugin within VMware Tools that enables the collection of the "raw" running application processes within a GuestOS. Once enabled, this information is then published into new VM guestinfo property called guestinfo.appinfo which can then be consumed by standard vSphere Automation Tools. This has been one of the most common VM Automation questions I have received over the years from customers and we can now provide additional insights to our administrators on the underlying applications and its version running within a Virtual Machine. 

By default, this new AppInfo capability is enabled by default after installing VMware Tools 11 and is supported with both Windows and Linux GuestOS. If you wish to disable this feature, you can find the instructions here. Below is a Windows Server 2016 which I have Active Directory among other applications running which has the appInfo collection enabled.


Once enabled, the default collection period runs every 30 minutes which can be changed following the instructions mentioned earlier. To make this easier to consume, I wrote a quick PowerCLI function called Get-VMApplicationInfo.ps1 which expects a VM object and then retrieves the appInfo details. As part of the output, the results also includes the last discovered time along with an update counter which can be used to track the number of times the collection has ran since enabling.

[Read more...] about Application Discovery in vSphere with VMware Tools 11

RSS feed for VMware release notes

by 8 Comments

Staying up to date with the latest VMware product releases can be a challenge and with something like VMware Cloud on AWS, which is delivered as a service, it can be even more tricky as new updates are constantly being made available. Historically, there has not been a consistent method for how customers can get notified of new releases and this has also come up from our VMware Cloud on AWS customers.

We posed the challenge to our Information Exchange (documentation) team to see how we can help our VMware Cloud on AWS customers and the team came back with an initial implementation of providing a standard RSS feed which you can now find at the upper right hand corner of the VMware Cloud on AWS release notes page. You can subscribe using your favorite RSS reader, I personally use Feedly and when a new release of the SDDC and/or service, you will get notified via your RSS reader. For those that want a different delivery mechanism such as email for example, you can use the free If This, Than That (IFTTT) service which I also personally use and setup an email notification or any other type of notification that IFTTT supports.


Although this initial requirement was driven by the VMware Cloud on AWS product team, we definitely wanted to see this capability delivered across all VMware products and services which is what the team has done as well. When you navigate to a specific product and/or service release notes, you will now see the additional RSS feed that you can subscribe to.

Here are just a few of the popular RSS feeds that I know folks will want to subscribe to. For a complete list of all VMware product/services, please take a look here.

I think this be a great first step in helping our customers easily get notified of new releases, so that can start reviewing the release notes and start planning. I know many of you have also asked for other methods such as programmatic access to release notes updates or even having a specific changelog for things like our APIs. If folks have any feedback in this area, feel free to leave a comment and I will be more than happy to share this with our documentation team.

Configuring Github Actions self-hosted runners on PhotonOS 

by Leave a Comment

Ever since Github announced Github Actions, which is now generally available for everyone, I have been a huge fan of the service. I even shared a blog post earlier this year on how you can easily incorporate automated application deployment to a vSphere or VMware Cloud on AWS based environment, which can automatically be triggered by native developer workflows directly from Github. This can be a really powerful and enabling capability for your developers, especially when taking advantage of an on-demand solution like VMware Cloud on AWS.
Right before VMworld Barcelona, I saw a tweet from the Github Twitter account announcing another cool feature which is the ability to run your own self-hosted runners. By default, when you use Github Actions, the runners are hosted by Github and when a Docker Container is launched, it is running within their infrastructure. During the beta, I had noticed some inconsistencies on how long it would take my Github Actions to kickoff which is usually within a minute or so but I have seen cases where it has gone up 5 to 10 minutes.

I was told that this was an infrastructure issue, but it did raise an interesting question in my mind on SLAs. As far as I know, nothing is publicly documented and Github also mentioned they did not have an SLA for the service. If you need a more predictable experience, you now have the option of running the "runners" in your own infrastructure which can be on-premises environment or even a public cloud where you have available compute capacity.

I finally got a chance to explore this capability and of course, I had to figure out how to get this working with our very own VMware PhotonOS. With a bit of trial and error, I was able to get everything working. In fact, I was able to run my Github runner directly in my VMware Cloud on AWS environment which can be quite useful for customers with development and CI/CD-based workloads and being able to leverage Github Actions.

[Read more...] about Configuring Github Actions self-hosted runners on PhotonOS