WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Search Results for: guest operations

Changing GuestOS Type Using a Custom vCO Workflow in the vSphere Web Client

10.01.2012 by William Lam // 6 Comments

Something you might not have noticed, is the fact that you can not change or modify the guestOS type after a virtual machine has been created in the new vSphere Web Client, this option is just grayed out.

Though this is a change in behavior compared to the old vSphere C# Client, I actually took this as an opportunity to try out one of the most interesting and unrealized feature in the vSphere 5.1 release. This feature being a tighter integration between vCenter Server and vCenter Orchestrator. This means that you can now take any of your existing vCO workflows or create new workflows and make them directly available to any of the vSphere objects within the new vSphere Web Client as a custom action. 

Note: A feature request/bug has already been filed with VMware to have the ability to change the Guest OS and Guest OS Version for a virtual machine after creation in the vSphere Web Client.

Here is an example of a custom workflow that I created called Change Guest OS Type and as you can see that it only shows up under the context of a virtual machine object in the vSphere Web Client. 

From my perspective, the use cases are endless as you can create ANY custom workflow to perform any action or series of operations that can span across VMware products as well as 3rd party systems and directly present them to your end users in the new vSphere Web Client. Not only that, users can specify which workflows they see by default on a given vSphere object and this can differ from user to user based on their daily set of tasks.

So going back to our scenario, here is a way to change the Guest OS and Guest OS Version using a custom vCO workflow.

Step 1 - Download Change Guest OS Type vCO workflow to local desktop.

Step 2 - Open up the vCO Workflow Client, you can do this by pointing your browser to your vCO Server and click on "Start Orchestrator Client" link.

Step 3 - Import the Change Guest OS Type vCO workflow from your desktop to your vCO Server

Step 4 - Next, we need to go to the vSphere Web Client to make this vCO workflow available on a particular vSphere object, in our case it is a virtual machine. On the home page of the vSphere Web Client, click on "vCenter Orchestrator" icon in the center pane or select it from the navigation pane on the left. Once you are in the vCenter Orchestrator configuration page, select the "Manage" tab and click on the "plus" icon.

In this view, you can specify which default vCO workflows are made available across the various vSphere objects. These can be modified or removed based on the frequency of workflow usage.

Step 5 - Locate the Change Guest OS Type vCO workflow on the left hand side and then click on the Add button. Finally, select type to be virtual machine as this workflow is only applicable to a VM and OK to save the settings.

If we take a look at the vCenter Orchstrator configuration page, we will see our new workflow is now listed as one of the defaults for a virtual machine object. You can edit and modify any of these based on the workflows you wish to see by default. I highly recommend you add workflows that you use frequently so you do not have to search through the entire list each time.

Finally, it is time to test drive our new workflow! Locate a virtual machine and right click on the object, in a second you should see a sub-menu for All vCenter Orchestrator Actions and then select our vCO workflow Change Guest OS Type which will start off a very familiar wizard.

The first screen is the object selected, which in our case is our virtual machine. You can of course change this, but we will leave it as it's context was automatically picked up.

The next screen is to select the Guest OS Family (Windows, Linux & Other) that you wish to modify your virtual machine to.

The last part is just to select the Guest OS Version which is provided as a list of the guest OSes based on your previous selection.

To apply the Guest OS change, just click finish and watch the vCO workflow execute.

Though the functionality of changing the Guest OS is not available in the new vSphere Web Client, you can still provide the same functionality to your end users through a custom vCO workflow which are now tightly integrated into the vSphere Web Client. Hopefully this sparks some ideas on other vCO workflows you can create or expose through the vSphere Web Client in your own environment. I know I have a few in mind 🙂

A big thanks goes out to Christophe Decanini for helping me with a few questions while creating this workflow.

Categories // Uncategorized Tags // guest, guest os, vcenter orchestrator, vCO, vSphere 5.1, vsphere web client, workflow

Automate Update Manager Operations using vSphere SDK for Perl + VIX + PowerCLI + PowerCLI VUM

07.30.2010 by William Lam // Leave a Comment

I recently saw an interesting question on the VMTN developers forum asking about vSphere SDK for Perl and VUM API integrations. As it stands today, VMware has not publicly exposed or documented the VMware Update Manager APIs, though they have released a few PowerCLI VUM cmdlets for PowerCLI users. This is one feature, in my opinion, that PowerCLI has over the other vSphere SDKs. This is quite unfortunate, since automating VUM operations is something I have looked forward to and the process can be slow from clicking around in the GUI. I think VMware sometimes forget that the world does not run on Windows and that VMware != Windows.

I was hoping with the release of vSphere 4.1, the VUM APIs would finally be exposed as a standard web service like the vSphere API provided with proper SDKs for the various languages. My reply to the VMTN user was exactly this: this type of integration does not exist today. If you would like to automate VUM operations, you must use the PowerCLI VUM cmdlets. The follow-up comment was how one might integrate between vSphere SDK for Perl and PowerCLI VUM cmdlets. Initially, I did not recommend this but it could potentially work with some type of WMI call or hooks from some Perl modules. The solution might get a little messy and it would probably be faster to just set up the PowerCLI VUM cmdlets on a Windows host.

As I thought about the question later that evening, I realized that there is potentially another method if you wanted to use the vSphere SDK for Perl but utilize the PowerCLI VUM cmdlets. The following solution will demonstrate the use of vMA, vSphere SDK for Perl, VIX Perl API, PowerCLI and PowerCLI VUM cmdlets. VMware VIX is used for guest management for VMs running on a VMware hypervisor, whether it be Workstation, Fusion or ESX(i). There is a Perl SDK for the VIX API which I use to generate a PowerCLI script that is transferred directly into a Windows VM running both PowerCLI and PowerCLI VUM. This dynamic PowerCLI script will contain the host information and VUM baseline provided from the vSphere SDK for Perl script. The script will remediate the host and then it will be deleted by VIX. This configuration is not ideal, but if you wanted to automate some of the available VUM operations but continue to use your vSphere SDK for Perl scripts, then you can.

The dynamic PowerCLI script that is generated is the following:

Connect-VIServer -Server [vc-server] -Protocol https -User [vc-user] -Password [vc-password]
$vmhost = Get-VMHost [vi-host]
$baseline = Get-Baseline [host-baseline]
$baseline | Attach-Baseline -Entity $vmhost -Confirm:$false
$vmhost | Scan-Inventory
$baseline | Remediate-Inventory -Entity $vmhost -Confirm:$false

Note: This is just one example, you can easily customize the script to generate other VUM operations or more complex PowerCLI script. Once the operation is completed on the ESX(i) host, the script is deleted via VIX.

Before we get started, you will need to have a Windows VM that has both PowerCLI and PowerCLI VUM installed which resides in the same infrastructure as your VUM Server. You will also need to have VMware vMA available and installed with VMware VIX which will be documented down below.

1. Download VMware VIX 1.10

2. Transfer VMware-VIX-1.10.1-266898.x86_64.bundle installer to vMA

3. Install VIX:

VMware-VIX-1.10.1-266898.x86_64.bundle

================================================================

[vi-admin@kate ~]$ sudo sh VMware-VIX-1.10.1-266898.x86_64.bundle
Password:
Extracting VMware Installer...done.
You must accept the VMware VIX API End User License Agreement to
continue. Press Enter to proceed.
.....
The product is ready to be installed. Press Enter to begin
installation or Ctrl-C to cancel.
Installing VMware VIX API 1.10.1
Configuring...
[######################################################################] 100%
Installation was successful.

To complete the next section, you will need GCC to be installed which is not part of the default vMA installation. If you are using vMA 4.1, it is running CentOS and you can setup CentOS YUM repository. This will require that your vMA host can proxy out to internet or to specific site. I will document the changes that need to be made to talk to CentOS repository for package installs.

4. Create repository file:

[vi-admin@kate ~]$ sudo vi /etc/yum.repos.d/centos-base.repo

Add the following to the repo file:

5. Install GCC using yum:

[vi-admin@kate ~]$ sudo yum -y --nogpgcheck install gcc.x86_64

6. CD to vmware-vix directory and extract VIX Perl

[vi-admin@kate ~]$ cd /usr/lib/vmware-vix/

[vi-admin@kate vmware-vix]$ sudo tar -zxvf vix-perl.tar.gz
vix-perl/
vix-perl/vix.h
vix-perl/includeCheck.h
vix-perl/vm_basic_types.h
vix-perl/VixBinding.xs
vix-perl/VixBinding.pm
vix-perl/ModuleList
vix-perl/lib/
vix-perl/lib/API/
vix-perl/lib/API/API.pm
vix-perl/lib/API/Host.pm
vix-perl/lib/API/Job.pm
vix-perl/lib/API/VM.pm
vix-perl/lib/API/Snapshot.pm
vix-perl/lib/API/PropertyList.pm
vix-perl/lib/API/Constants.pm
vix-perl/lib/Simple.pm
vix-perl/Makefile.PL
vix-perl/typemap
vix-perl/ppport.h
vix-perl/README
vix-perl/samples/
vix-perl/samples/findhosttest.pl
vix-perl/samples/powertest.pl
vix-perl/samples/vmrun.pl
vix-perl/libvixAllProducts.so

7. Install VIX Perl

[vi-admin@kate vmware-vix]$ cd vix-perl

[vi-admin@kate vix-perl]$ sudo perl Makefile.PL
Writing Makefile for VMware::VixBinding

[vi-admin@kate vix-perl]$ sudo make

[vi-admin@kate vix-perl]$ sudo make install

If you did not want to go through all these manual steps after installing VIX, I actually wrote a quick shell script that will automate the configuration of the CentOS repository, GCC installation and extraction and installation of VIX Perl.

Download installVIXPerl.sh

Executing installVIXPerl.sh:

[vi-admin@kate ~]$ chmod +x installVIXPerl.sh

[vi-admin@kate ~]$ sudo ./installVIXPerl.sh

9. Download patch-host.pl script and transfer it to vMA

10. You will need to edit 4 variables defined within the script:

$psvm_username = Is the username to your Windows system running PowerCLI
$psvm_password = Is the password to your Windows system running PowerCLI
$powercli_bin = Is the full path to your powershell binary, if it is a default installation, you can leave this unchanged
$powercli_options = Is the path to vSphere PowerCLI psc file, you can also leave this as the default

Note: If you do decide to change either $powercli_bin or $powercli_options, make sure you add an extra "forward slash" which needs to be escaped in the Perl script.

The script requires you to connect to your vCenter server and provide the following parameters:

--vihost = Name of ESX(i) host to be patched

--baseline = Name of the VUM basline to attach

--psvm = Name of the Windows VM running both PowerCLI and PowerCLI VUM

Here is an example patching an ESXi host that is running on 4.0u2 and using the script to apply vSphere 4.1 baseline:

[vi-admin@kate]$ ./patch-host.pl --config --server reflex.primp-industries.com --username primp --vihost esxi4-3.primp-industries.com --psvm powerclivm --baseline vSphere4.1-Upgrade

Entering maintenance mode for esxi4-3.primp-industries.com
Successfully entered maintenance mode for esxi4-3.primp-industries.com
Guest login successfully!
Copy patch-host-esxi4-3.primp-industries.com-22174.ps1 to guest successfully!
PowerCLI/VUM script executed successfully!
Script removed successfully!
Successfully patched esxi4-3.primp-industries.com using VUM baseline: vSphere4.1-Upgrade

One thing I did notice, after the script is transferred to the Windows VM, it takes about 15-20 seconds before the script executes. I am not exactly sure why this occurs, as this does not happen when running the PowerCLI script logged into the VM. This may be due to the way VIX is executing the script within the guest.

The following resources were used in creating this script:

  • Referenced growdisk.pl vSphere SDK for Perl/VIX script written by Matt Lamantia
  • Referenced Alan's video on Getting Started with Update Managed cmdlets

Categories // PowerCLI, Uncategorized Tags // PowerCLI, vix, vsphere sdk for perl, vum

Identifying VMware Cloud Foundation (VCF) managed service accounts in vCenter Server

10.30.2025 by William Lam // 1 Comment

When users log in to a vCenter Server to manage roles and permissions within a VMware Cloud Foundation (VCF) 9.0 environment, they may notice several accounts that already have vSphere permissions assigned.


This might come as a surprise, especially if you do not recall creating these users, let alone granting them privileges within vCenter Server.

A large majority of the user accounts that you see are internal to the vCenter Server Appliance (VCSA) and represents the different application services running within the VCSA. There are also a handful of VCF accounts that are automatically created to enable communication between the various VCF components, but at the end of the day these are all service accounts that is either managed by vCenter Server or VCF.

With that said, it might be useful to understand which of these accounts are service accounts, so organizations can properly audit their environment for compliance and configuration management.

[Read more...]

Categories // VMware Cloud Foundation, vSphere 9.0 Tags // VCF 9.0

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 22
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • What Host Lifecycle Operations Are Available after Importing vCenter into VCF 9.x Fleet? 06/24/2026
  • VCF 9.1 - Enabling High Availability for a Small VCF Management Services (VCFMS) Deployment 06/22/2026
  • Clarifying Minimum Required ESX Hosts for VCF Deployments 06/18/2026
  • VCF 9.1 - Auditing VCF Management Services (VCFMS) IP Pool Usage  06/17/2026
  • VCF 9.1 - Auditing vCenter Server Connections using the Connection Utilization API 06/15/2026
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026

Loading Comments...