Omnissa Horizon REST API with PowerShell: An API Adventure

At Omnissa One, I took attendees on an API adventure in session TSH452 — a hands-on tour of the Omnissa Horizon REST API. The API lives past the “recommended settings,” past the “don’t worry about that warning,” and way past the part of the console everyone pretends to understand. It’s a door very few have choose to open and step through.

Instead, many admins keep doing things the hard way, battling desktop operations one at a time and fighting their evil nemesis: time. That ended for my session attendees. They walked out with a new set of API tools in their toolbelt, the kind that make your boss think it’s magic and your coworkers think you’re a superhero.

For those who were there — or wished they were — I’m sharing all the knowledge from my session right here in this post.

Unlocking Horizon’s secret lair:
A VLSI API Adventure
Cover slide for Omnissa One session TSH452

From SOAP to REST: The Horizon View API Is Being Deprecated

Astute readers may notice the session was originally supposed to cover the Virtual Language System Interface (VLSI) API, the SOAP-based interface. And it was! That’s what I’d used in the past whenever I wanted to work programmatically with an Omnissa Horizon environment.

Then I went to the Omnissa Developer site to start building my presentation… and guess what? Omnissa KB 6000139 states:

“…deprecation of the Horizon View APIs in the Q2 Release of 2026 (earlier planned for the Q4 Release of 2025) and its removal in upcoming future releases… The Horizon Q2 2026 Release will be the last version to include the SOAP-based Horizon View APIs. The newer releases after Q2 2026 will only contain the Horizon REST APIs.”

Translation: let’s make sure this presentation stays useful.

Your Built-In API Documentation: Swagger

So, running to the nearest phone booth and swapping our superhero capes, let’s talk about the Omnissa Horizon Server REST API. There’s a great section covering it on the Omnissa Developer site, but the better news is that your connection server ships with a built-in Swagger instance that documents the API for your specific environment. You can reach it at:

https://[connection-server]/rest/swagger-ui/index.html

If you haven’t used Swagger before, it’s a powerful API documentation tool that tells you just about everything you need to make a given API call: the structure of the request, the possible return codes, and what the response content looks like.

We’ll use PowerShell for these examples because we’re just getting started. If you wanted to build a full system, you’d reach for something like Python. Luckily, most of this code ports over easily, because it’s all just API calls.

Step 1: Authenticate and Get a Bearer Token

The first thing we need is a connection with the API: what REST folks call getting a bearer token. The idea is simple: authenticate once, then fire off a bunch of API calls by presenting the token instead of re-authenticating every time. Eventually the token times out and you renew or request a new one.

Here’s how you get that bearer token and build a reusable header with it:

# Bypass cert validation (PS 5.1 & 7 compatible fallback)
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }

$BaseUrl = "https://[connection server]/rest"

# Construct credentials body for initial login
$Body = @{
    "username" = "api_admin"
    "password" = "SecretPassword"
    "domain"   = "YOURDOMAIN"
} | ConvertTo-Json

# Request the login token
$LoginResponse = Invoke-RestMethod -Uri "$BaseUrl/login" -Method Post -Body $Body -ContentType "application/json"

# Capture the bearer token (Horizon returns access_token)
$BearerToken = $LoginResponse.access_token

# Define standard headers for future calls
$Headers = @{
    "Authorization" = "Bearer $BearerToken"
    "Accept"        = "application/json"
}

A few things worth noting in this block:

  • We start by bypassing certificate validation because my lab uses self-signed certs. If you’re working in production, set this to $false.
  • I create a $BaseUrl variable so I only have to change one location if the base REST URL ever changes.
  • The login body carries our credentials to the connection server. I strongly recommend creating a dedicated API user for these tasks; it makes auditing much easier. Bonus: Swagger tells you which privileges each API call requires, so you can limit the account to only the permissions it needs.
  • We convert the body to JSON, then we can make our first call.

Throughout the rest of this post we’ll use Invoke-RestMethod for every API call to the Horizon connection server. This first call appends the login path to the base URL, uses the POST method, and passes the body we just built. The response returns several items, but the only one we care about right now is access_token. Drop that token into the $Headers hashtable and we can make additional calls without re-authenticating.

Step 2: Anatomy of an Invoke-RestMethod Call

Let’s add another tool to the toolbelt by looking closer at how Invoke-RestMethod is structured. Each call needs:

  • -Uri – the path of the API you want to run
  • -Method – Get, Post, Put, or Delete
  • -Headers – your bearer token
  • -Body – typically a JSON payload (when required)
  • -ContentType – "application/json"

That’s everything a typical PowerShell API call needs, and the return value is a JSON response. The basic building block looks like this:

$Response = Invoke-RestMethod -Uri "$BaseUrl/$APIpath" -Method Get -Headers $Headers -Body $JsonPayload -ContentType "application/json"

Now that we understand the pattern, let’s do something practical.

Step 3: List Horizon Desktop Pools

Let’s find out which desktop pools exist in our environment. Heading back to Swagger, the endpoint is inventory/v1/desktop-pools, it uses GET, and no request body is required:

# API location
$DSPoolPath = "inventory/v1/desktop-pools"

# API GET call
$DSPoolList = Invoke-RestMethod -Uri "$BaseUrl/$DSPoolPath" -Method Get -Headers $Headers

This returns a listing of every desktop pool and all of their settings. That’s genuinely useful: it’s the foundation for a script that checks whether desktop pools have been added or removed over time. Think daily reports.

Step 4: Disable (and Re-enable) a Desktop Pool

Let’s take it a step further and disable a pool. It’s a two-step process: the disable action doesn’t accept pool names, so first we need the pool ID, then we disable it.

The first part is the longer one: get the pools, extract the ID (or IDs, since yes, you can do more than one at a time), and convert them into a JSON array:

# Get pool information
$DSPoolList = Invoke-RestMethod -Uri "$BaseUrl/$DSPoolPath" -Method Get -Headers $Headers

# Create a JSON array of desktop pool IDs
$DSPoolID = $DSPoolList.id
$DSPoolRawIDs = @($DSPoolID)
$DSPoolJsonIDs = ConvertTo-Json -InputObject $DSPoolRawIDs   # PowerShell 5.1+ compatible

Let me pause on that last line. I only have a single desktop pool in this lab, which is why there’s no loop hunting for a specific pool. More importantly, the JSON body expects an array, and ConvertTo-Json treats a single-item array as a single object and drops the square brackets — which breaks the call. Using -InputObject preserves the brackets, and this approach stays backwards compatible with PowerShell 5.1.

Now that we have the pool ID, disabling it looks familiar: same structure as before, except it’s a POST that needs a -Body (the JSON array we just made):

# Disable the desktop pool
$DSPoolDisResult = Invoke-RestMethod -Uri "$BaseUrl/$DSPoolPath/action/disable" -Method Post -Headers $Headers -Body $DSPoolJsonIDs -ContentType "application/json"

The desktop pool should now be disabled. To re-enable it, run almost the same command and just change disable to enable in the URI.

Step 5: Modify a Desktop Pool (the Big One)

One last tool for the toolbelt: modifying a desktop pool. This one requires retrieving several different IDs and potentially a very long JSON body; it can easily run over 100 lines. Why? Think about everything you configure across all those screens when you create a desktop pool. All of that information is reflected in a pool update.

Here’s the first part: retrieving the information we need, then building the JSON body with the appropriate schema:

# Retrieve the access group
$AccessGroups = Invoke-RestMethod -Uri "$BaseUrl/config/v1/local-access-groups" -Method Get -Headers $Headers

# Retrieve the pool ID
$DSPoolList = Invoke-RestMethod -Uri "$BaseUrl/$DSPoolPath" -Method Get -Headers $Headers
$DSPoolID = $DSPoolList.id

$UpdateDSPoolPayload = @{
    "access_group_id"                 = $AccessGroups.id
    "allow_multiple_user_assignments" = $true
    "display_name"                    = "API TESTING POOL"
    "enabled"                         = $false
    # ... the rest of the schema goes here
}

# Convert payload
$ConvertedDSPool = $UpdateDSPoolPayload | ConvertTo-Json -Depth 5

The access group and pool ID retrievals should look familiar by now. I cut the payload short because, frankly, I suspect you don’t want to scroll through nearly 100 lines of code to reach this paragraph. Even IT superheroes have their limits.

That last line adds something new: -Depth 5. The JSON body contains nested arrays, and ConvertTo-Json doesn’t fully traverse them by default, so we explicitly tell it to go five levels deep.

With the JSON body built, we can attempt the update:

try {
    $DSPoolUpdate = Invoke-RestMethod -Uri "$BaseUrl/$DSPoolPath/$DSPoolID" -Method Put -Headers $Headers -Body $ConvertedDSPool -ContentType "application/json"
}
catch [System.Net.WebException] {
    $Reader = New-Object System.IO.StreamReader($_.Exception.Response.GetResponseStream())
    $ResponseText = $Reader.ReadToEnd()
    Write-Error "HTTP Status: $($_.Exception.Response.StatusCode)"
    Write-Error "Server Response: $ResponseText"
}

This is the first time I’ve used a try/catch block in this post, and there’s a good reason for it. The schema for this call includes a bunch of fields that may or may not apply to your desktop pool, and if they don’t apply, they’ll make the call fail. The catch block surfaces the server’s actual response so you can figure out what to add or remove. Here’s what that looks like in practice:

APIcall.ps1 : HTTP Status: The remote server returned an error: (400) Bad Request
+ .\OmnissaOneScripts_v4.ps1
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,OmnissaOneScripts_v4.ps1

Server Response: {"status":"BAD_REQUEST","timestamp":1789503512351,"errors":[{"error_key":"inventory.desktop-pool.provisioning_settings.automated.unset.error","error_message":"provisioning_settings must be set for automated desktop pools."}]}

The error_message at the end is the gold. In this case, I never configured provisioning_settings for my desktop pool, so I add it to the JSON payload and run the call again. I’ll let you iterate on your own payload for your environment.

Get the Slides and Scripts

Hopefully this adds a few new tools to your toolbelt, and helps you feel more comfortable walking through that door few dare to venture through.

I’ve posted the full slide deck from Omnissa One for your enjoyment and reference: link to slides. All the code from the session is also on my GitHub account for you to use.

Try things out, see what you can develop, and share what you build on developer.omnissa.com.

Permanent link to this article: https://www.wondernerd.net/omnissa-horizon-rest-api-with-powershell-an-api-adventure/

GPU Management with PowerCLI and Python | VMware Explore 2026

You missed my session on GPU Management with PowerCLI and Python at VMware Explore this year!?!? That’s fine – more than 50 people watched it live. Maybe you were one of them. 😉

Regardless, if you’re interested in learning more about managing GPUs in VMware VCF using either PowerShell or Python, I’ve got you covered. I’m sharing all the resources from my session right here for your enjoyment and enlightenment.

Title slide of 2026 VMware Explore Session. 
Session title: The Wondernerd Returns: Scripting GPU Management with PowerShell and Python

From DirectPath Profiles to GPU Performance Stats

Last year I talked about managing DirectPath profiles using PowerShell and PowerCLI (VCF and VVF 9 New GPU Management Scripting with PowerShell and Python – CODEQT1767LV). This year I went for something that seemed simpler, but isn’t: pulling GPU performance statistics.

Both VMware and NVIDIA have been working hard on adding additional stats around GPUs. This is helpful for many reasons – regardless of whether you’re doing AI, VDI, or maybe something else entirely with GPUs. The intent, of course, is to feed these stats into vSphere monitoring tools like VCF Operations.

Having all this information at your fingertips is awesome. You should also be able to build automation workflows around some of the data that comes out of it – which is great if that’s your only tool.

But wouldn’t it be even better to feed GPU stats into Grafana, or build a system that watches for hot spots in your data center and balances workloads by temperature?

That’s where the scripts I shared come into play. They’re the basic building blocks needed for any project that consumes GPU stats.

Watch the Session and Get the Slides

If you’d like to watch the session, the video can be found in the VMware Explore video library.

If you’d like the slides from the session, I made sure to share them.

Now, on to how all this stuff actually works.

What GPU Metrics Are Available in VCF 9.1?

Let’s start with what GPU metrics you can pull from a 9.1 environment. In my research I was only able to find values for clusters and hosts. Metrics should exist for VMs as well, but I was not able to get them to appear correctly in my lab environment with an NVIDIA L4 GPU and various vGPU configurations for the VM.

The performance counters are the same for both clusters and individual hosts. They are:

  • gpu.utilization.average – The compute utilization of a GPU in percentage
  • gpu.mem.used.average – The amount of GPU memory used by workloads in kilobytes
  • gpu.mem.reserved.latest – The amount of GPU memory consumed by virtual GPUs in kilobytes
  • gpu.power.used.latest – The power used by a GPU in watts
  • gpu.temperature.average – The temperature of a GPU in degrees Celsius
  • gpu.mem.total.latest – The total amount of GPU memory in kilobytes

The Complete GPU Counter List

There are other GPU counters if you query the perfManager object. Currently, many do not appear to have values when I query for them – it may be that my GPU doesn’t support them, or they haven’t been linked and activated yet. The first six in the following list are the ones that returned values I was able to query. The complete list from my environment:

ID: 286 | Metric: gpu.utilization.average
ID: 287 | Metric: gpu.mem.used.average
ID: 288 | Metric: gpu.mem.reserved.latest
ID: 289 | Metric: gpu.power.used.latest
ID: 290 | Metric: gpu.temperature.average
ID: 291 | Metric: gpu.mem.total.latest
ID: 479 | Metric: gpu.utilization.latest
ID: 480 | Metric: gpu.mem.used.latest
ID: 481 | Metric: gpu.temperature.latest
ID: 482 | Metric: gpu.compute.clock.demand.latest
ID: 483 | Metric: gpu.compute.clock.used.latest
ID: 484 | Metric: gpu.compute.utilization.latest
ID: 485 | Metric: gpu.mem.utilization.latest
ID: 486 | Metric: gpu.mem.demand.latest
ID: 487 | Metric: gpu.encode.utilization.latest
ID: 488 | Metric: gpu.decode.utilization.latest
ID: 489 | Metric: gpu.power.limit.latest
ID: 490 | Metric: gpu.compute.clock.limit.latest
ID: 491 | Metric: gpu.shutdown.temperature.latest
ID: 492 | Metric: gpu.slowdown.temperature.latest
ID: 493 | Metric: gpu.mem.errors.ecc.corrected.latest
ID: 494 | Metric: gpu.mem.errors.ecc.uncorrected.latest
ID: 495 | Metric: gpu.tensor.utilization.latest
ID: 842 | Metric: gpu.utilization.none
ID: 843 | Metric: gpu.utilization.maximum
ID: 844 | Metric: gpu.utilization.minimum
ID: 845 | Metric: gpu.mem.used.none
ID: 846 | Metric: gpu.mem.used.maximum
ID: 847 | Metric: gpu.mem.used.minimum
ID: 848 | Metric: gpu.mem.usage.none
ID: 849 | Metric: gpu.mem.usage.average
ID: 850 | Metric: gpu.mem.usage.maximum
ID: 851 | Metric: gpu.mem.usage.minimum
ID: 852 | Metric: gpu.mem.used.gb.latest
ID: 853 | Metric: gpu.mem.reserved.gb.latest
ID: 854 | Metric: gpu.mem.total.gb.latest

Finding Available GPU Metrics with PowerCLI

You might be wondering how to know what’s available on your hosts or clusters. In PowerShell you can run the following commands to get information about your GPU metrics:

#$TargetEntity = Get-Cluster -Name "91-lab-vdi-cl01"
$TargetEntity = Get-VMHost -Name "esx04.wondernerd.lab"
Get-StatType -entity $TargetEntity | where-object {$_ -match "gpu"}

For this command set I have two different $TargetEntity values defined – one gets the cluster object, the other gets the host object. That’s passed to the Get-StatType command and then piped to an object search that matches items with “gpu” in the name. The result is the list of objects I described above.

Finding Available GPU Metrics with Python (pyVmomi)

We can do this in Python as well – it’s just a bit longer:

from pyVim.connect import SmartConnect
from vmware.vapi.vsphere.client import create_vsphere_client, VsphereClient
from pyVmomi import vim
import ServiceInstance #file with login info

si = ServiceInstance.ConnectToVC()
content = si.RetrieveContent()
perfManager = content.perfManager

counter_ids = [] #Base ID Values
counter_info = {} #Full ID and name pairs
counter_id_dict = {} #GPU ID name pairs

for counter in perfManager.perfCounter:
    full_name = f"{counter.groupInfo.key}.{counter.nameInfo.key}.{counter.rollupType}"
    counter_info[counter.key] = full_name
    if "gpu" in full_name:
        print(f"ID: {counter.key} | Metric: {full_name}")
        counter_ids.append(counter.key)
        counter_id_dict.update({counter.key : full_name})

This code produces the second list I provided above, with the IDs and metric names.

Reading Actual GPU Metric Values with PowerCLI

You’re probably thinking: it’s good to know what metrics exist, but how do we find out what the actual values are? In PowerCLI we do it by passing one more parameter to Get-Stat and running the results through a ForEach loop:

$HostPerf = get-stattype -Entity $TargetEntity | where-object {$_ -match "gpu"}
foreach ($HostHas in $HostPerf) {
    $GPUresults = Get-Stat -Entity $TargetEntity -Stat $HostHas –Realtime -MaxSamples 1
    Write-Host $GPUresults.MetricId
    Write-Host $GPUresults.Description
    Write-Host $GPUresults.Value
}

The output looks something like this:

gpu.utilization.average
The compute utilization of a GPU in percentage
0
gpu.mem.used.average
The amount of GPU memory used by workloads in kilobytes
8238592 ...

Reading GPU Metric Values with Python

Python, again, is a little longer:

host = content.searchIndex.FindByDnsName(dnsName="esx04.wondernerd.lab", vmSearch=False)
metrics = [vim.PerformanceManager.MetricId(counterId=cid, instance="*") for cid in counter_ids]
query = vim.PerformanceManager.QuerySpec(
        entity=host,
        metricId=metrics,
        intervalId=20,
        maxSample=1
    )
perf_results = perfManager.QueryPerf(querySpec=[query])
for result in perf_results:
    for metric_value in result.value:
        counter_id = metric_value.id.counterId
        # Fetch the most recent value from the value array
        latest_val = metric_value.value[-1] if metric_value.value else 0
        print(f"Description: {counter_id_dict[counter_id]} | Value: {latest_val}")

We basically set up a query for a single sample and pass that into perfManager using the QueryPerf property. This gives us an array we can work with, then we filter the results using nested for loops. The result looks something like this:

Description: gpu.power.used.latest | Value: 17
Description: gpu.mem.used.none | Value: 4633728
Description: gpu.mem.used.average | Value: 4633728
Description: gpu.mem.used.maximum | Value: 4633728
Description: gpu.mem.used.minimum | Value: 4633728
Description: gpu.mem.reserved.latest | Value: 4633728
Description: gpu.temperature.average | Value: 42
Description: gpu.utilization.none | Value: 0
Description: gpu.utilization.average | Value: 0
Description: gpu.utilization.maximum | Value: 0
Description: gpu.utilization.minimum | Value: 0
Description: gpu.mem.usage.none | Value: 1964
Description: gpu.mem.usage.average | Value: 1964
Description: gpu.mem.usage.maximum | Value: 1964
Description: gpu.mem.usage.minimum | Value: 1964
Description: gpu.mem.total.latest | Value: 23586816

Practical Use Case: Detecting Data Center Hot Spots

Being able to get the values is great and all, but how do we apply it to something practical – say, a data center, or even a single host, getting too warm?

Easy enough. Let’s pull the temperature from the GPU for the last day and run some statistics on it. With PowerCLI:

$GPUtemp = Get-Stat -Entity $TargetEntity –Stat gpu.temperature.average -Start (Get-Date).AddDays(-1) -IntervalMins 5
$CleanTempArray = @()
[system.Int32[]]$CleanTempArray = @($GPUtemp.Value)
($CleanTempArray | Measure-Object -StandardDeviation -Average -Sum -Maximum -Minimum)

We use the Get-Stat command and pass it the stat we want along with the time range. Next we create a temp array to hold our statistics from processing the GPU temp data. Then we process it using Measure-Object and ask for our statistics. The result:

Count             : 288
Average           : 42.5902777777778
Sum               : 12266
Maximum           : 44
Minimum           : 41
StandardDeviation : 0.687501099847781
Property          :

If you’d like to read more about standard deviation, I’d recommend the Wikipedia article on it.

The takeaway: if my GPU temperature climbs above 43.965 degrees, the cooling should be investigated because something isn’t “normal.” We could then use some of the other functions in Python or PowerShell to look at the whole environment and see if the problem is specific to a host, a rack, a cluster, or any other grouping. We can then take appropriate action for the impacted VMs, maybe that’s putting the host in maintenance mode or sending a notification. The results can help optimize and protect your workloads.

Get the Scripts

You can find all of these scripts (plus last years scripts) on my GitHub and work with them yourself. If you find a fun way to use them, please share your approach.

Permanent link to this article: https://www.wondernerd.net/gpu-management-with-powercli-and-python-vmware-explore-2026/

Revealing Data, Reviving the Idea of Virtual Mobile Devices

The concept of a virtual mobile device isn’t new. Now may be the time to revive that idea to keep phones from revealing data they shouldn’t. The idea for such capabilities goes back to before 2011 when it was announced that Verizon and VMware were working on “Dual Identity Smartphones.” This was one of the BIG things discussed in the EUC space during that VMworld. Now it may be worth reconsideration.

Copilot. (2026). Ghostly spirits escaping a collapsing smartphone interface in Soviet-style propaganda illustration [AI-generated image]. Microsoft Copilot.
Copilot. (2026). Ghostly spirits escaping a collapsing smartphone interface in Soviet-style propaganda illustration [AI-generated image]. Microsoft Copilot.

Having phones with multiple, or seemingly multiple personalities could be beneficial. Not necessarily from a technology standpoint, as the concept is over 15 years old. Instead the benefits come from security and political concerns that are now more prevalent than they were when this concept was first developed.

Burner Devices

It is a common practice for business people traveling to certain countries to receive a ‘burner’ phone and laptop with minimal access to corporate assets. The list of countries where this applies has grown in the last couple of years, increasing the need for security at organizations and for individuals. Typically when folks return these ‘burner’ devices, they are wiped and ‘hopefully’ destroyed. This is to ensure any possible surveillance systems that ‘accidentally’ got installed on them while out and about are mitigated. The idea being that it may not be possible to tell if the device was tampered with, so let’s not take any chances.

This technology would also make phone upgrades/replacement so much easier. Because the phone is now a VM, the underlying hardware could be replaced with minimal disruption enabling a consistent user experience. Additionally, if for some reason the mobile device was lost or stolen, the information is not compromised. It could be recovered from the safety of a data center. Not to mention all the program isolation and sandboxing that could be done. It brings so many benefits to users and organizations alike.

An Example

Let’s look at an example of this, you fly to a country that surveilles foreigners entering the country (pick your country, I can think of 3 without even trying). As you go through security to entry one of these countries, your electronic devices are inspected. The security detail powers up your laptop and has you login, they poke around. They have you unlock your mobile device and do the same, inspecting and downloading any data resident on the device they wish (see ‘advanced search’).

Copilot. (2026). Sinister officer inspecting smartphones in Soviet-style propaganda illustration [AI-generated image]. Microsoft Copilot.
Copilot. (2026). Sinister officer inspecting smartphones in Soviet-style propaganda illustration [AI-generated image]. Microsoft Copilot.

They clear you and you move on with your day. Only ever since your phone hasn’t been the same. The ‘security’ team ‘infected’ your mobile device with something. Spyware, malware, tracking, worms, who knows what. The same with your laptop. If you refuse to allow an ‘inspection’ of these devices you might be detained or refused entry. This is the reason for burner devices.

This is also why VDI is so important for corporate users. Your files and materials are all safely locked away in your country of origin and not present on the device. There is nothing for all that malicious software or prying eyes to see. Only right now, this isn’t entirely true for mobile devices like cell phones. And arguably, they are becoming more important in protection strategies. They have become the life blood for many and contain as much if not more important information (think contacts, appointments, and text messages) than a laptop.

Time to Revive Virtual Mobile Devices?

For these and many other reasons, I feel the idea of virtual mobile devices might be worth reviving. I started thinking about this and outlined this blog post as I was flying back from VMware Explore 2025, where I’d heard stories from several who came for the conference regarding their journey through United States Customs. Needless to say, I found it disturbing.

There are ways to deliver applications to users mobile devices for organizations where IT can geofence the applications so they uninstall or wont run or contain data in certain areas. This is good for some business applications. But…

As I sat on my flight back from VMware Explore I see some scenarios where it maybe more appropriate to have a full virtual mobile device, so things aren’t cached. With reports of USCB demanding full reviews of travelers mobile devices it might be better to have a fully separate virtual mobile device, that way when you land you disconnect from your virtual mobile device, and there is nothing to see. 

What a Virtual Mobile Device (VMD) Looks Like

You might wonder what the technical design of a VMD would look like. Let’s break it down really quickly. There are a couple of ways to deliver them, one is to use an ARM emulator on an x86 platform, the other is to have a cluster of ARM servers capable of delivering a native mobile OS using virtualization technologies. These would of course be virtual machines and could easily be deployed in a number of different configurations including something like Omnissa’s Instant Clone technology. Where the mobile user environment is rebuilt each time from a base image. Or it could be a static VMD where it exsists as a persistent image.

Then, the user just connects to their VMD from their phone when needed and they disconnect prior to entering locations subject to inspection. This would be handled using a broker like, Omnissa Horizon. The result being, a separated mobile device experience.

Other VDM Considerations

There are also a few other things to consider with this. What about SIMs, phone calls, cameras, and other functions of most modern mobile devices. The SIM can be addressed in one of two ways, a virtual SIM or it can be linked back to a hardware SIM in the data center where the VMD resides. Everything else could easily be passed through.

Additionally, things like facial recognition could continue to work seamlessly by creating a two way trust and key-chain pairs between the mobile device and VDM. The recognition system functions similarly to how it works now, only the trust is first established with the VDM, and the VDM then establishes the trust with the application.

(At this point you’ve probably figured out, that at least for the time being, this would preclude IOS based VMDs. This is mainly due to licensing restrictions.)

ARM Hosts

You might also be thinking that ARM isn’t available on any mainstream virtualization platforms. That’s not entirely true. At VMware Explore this last year there was a session on delivering ARM VMs through VMware VCF. You can watch it here: VMware Cloud Foundation on Arm: Where We Are and Where We’re Headed [CLOP1126LV] 

If a vendor would bring together all the work from the past, they could create a powerful sandbox where all (application, data, etc.) remains in a sovereign data center and make a mint. And if done well they could commercialize it. Imagine you no longer need to fear losing your phone and all the pictures on it, or someone stealing it.

You might be thinking apps can just be delivered using existing methods with similar outcomes. Just think about how long it takes to restore everything following a reset of your phone. There are a lot of ways to deliver the individual apps, we could make it simpler by delivering the whole mobile environment.

It Just Makes Sense

A “burner phone” that maintains a consistent user experience might be overkill for some. However, with unlimited data, minimal dead spots, and the fact that most mobile devices first purpose is no longer phone calls (when was the last time you heard someone asking “can you hear me…”), isolating data operations using VDMs just makes sense.

This would also mean the data that organizations (or individuals) do not want disclosed to governments or others for whatever reason could be safely disassociated from the mobile device. Completely severed, because there is technically nothing kept on the device.

If this became wide spread, it would become almost pointless for bad actors to request a review of a mobile device. The data is out of their grasp kept safe in a data center, and only streamed to and from the mobile device.

Furthermore, organizations could establish geofences around known areas of device intrusion where it is not possible to connect to VMDs. This ensures that private data remains private and privileged. It also forces bad actors (nation state or otherwise) to show more respect to the privacy of individuals. It could still be possible to use the mobile device to make phone calls if needed, just not opening the kimono wide enough to see all the private data.

Plus, when someone returns from a country with such surveillance on visitors, the end user can dispose of their “burner” devices with minimal disruption, without revealing their data. The old is new again!

Copilot. (2026). Joyful crowd discarding smartphone into flaming trash can in Soviet-style propaganda illustration [AI-generated image]. Microsoft Copilot.
Copilot. (2026). Joyful crowd discarding smartphone into flaming trash can in Soviet-style propaganda illustration [AI-generated image]. Microsoft Copilot.

Permanent link to this article: https://www.wondernerd.net/revealing-data-reviving-the-idea-of-virtual-mobile-devices/

VCF and VVF 9 New GPU Management Scripting with PowerShell and Python [CODEQT1767LV]

VCF and VVF 9 introduce some new methods for managing GPUs both in the GUI and through code such as PowerShell and Python. I presented on this at VMware Explore in a VMware {Code} session CODEQT1767LV. Here are are the details on whats new with GPU management in vSphere 9 from my session.

The biggest addition in GPU VCF and VVF are DirectPath Profiles. Direct Path Profiles or DPPs when vGPU profiles were added to them in 9.0. They provide a view of how the GPUs in your environment are being consumed. For example, lets say I have 10 NVIDIA GPUs in a cluster. At a cluster level I can see the combined consumption of vGPU profiles on everything in the cluster or I can drill down and look at consumption at a host level.

Bellow is a screen capture of what this looks like in vCenter.

In this image from my home lab you can see that DPPs are located under the monitoring section for both clusters and hosts. In use in the environment is one GPU consuming a NVIDIA L4-3B profile. We can see how that impacts the other profiles as well as the remaining number of each profile defined that are available.

Justin Murry did a fantastic blog on DPPs. To get a full understanding of what one is and how it works I recommend a quick read of his blog post.

CODEQT1767LV

Now let’s dig into why you are probably here and what I was presenting on. Interacting with DPPs. Below is a link to my slide deck that I presented at Explore and when the video posts, I will link that here as well.

Again the session will be linked once it is posted.

The MOB

With 9.0 the Managed Object Browser or MOB is disabled by default. This may not sound like a big deal to those who don’t do much coding for virtual environments. But for those of us who relish this, you’ll find that you spend a lot of time in the MOB looking up structures, functions, and paths.

Let’s quickly talk about enabling that. Broadcom KB 401669 provides details of how to enable the MOB. This is a rather straight forward task of modifying the vpxd.cfg file on the vSphere environment you want to enable it from.

There are a couple of things that need done first though. You’ll need to enable BASH shell access and (optionally) SSH access to the vCenter. This is so you can actually get to the vpxd file. Then you open up your favorite editor, in my case VI, and change the value of <enableDebugBrowse> to true. Only my instance didn’t have the <enableDebugBrowse> in the vpxd file, so I had to add it. I added it right under the <hostnameUrl> and it appears to work just fine. Here’s a screen shot of what that looks like.

Once the value has been set to true or added, save the vpxd.cfg file and restart the vpxd service. Then you’ll have MOB access.

If you would like to find DirectPath Profiles in the MOB. From the [home] location go to the content section, then select directPathProfileManager and you can see all the functions exposed for it. It should look like the screenshot below.

VCF PowerCLI Scripting

As you can see above there are five functions for DirectPath Profiles. One creates, one modifies, and one destroys, the other two are the interesting ones. These are the two I will focus on the Capacity and the List functions. These are the most valuable for scripting and automation. The other three are less impactful for development purposes as they tend to be one and done.

DirectPathProfileManagerList()

Let’s start simple with getting a list of DPPs. The code to do this is straight forward. I establish a connection to my vSphere environment and use the following code:

#------------- List all DPP specs -------------
$DPP_MGR = Get-View -Id 'DirectPathProfileManager-DirectPathProfileMgr'
$Spec = New-Object VMware.Vim.DirectPathProfileManagerFilterSpec
$DPP_MGR.DirectPathProfileManagerList($spec)

This code block has 3 lines to it. First we create a view of the DirectPathProfileManager and assign it to a variable. Next we create a new DirectPathProfileManagerFilterSpec or specification and assign it to a $Spec value. This is basically a filter object that allows us to specify what we are looking for. Lastly we use the DirectPathProfileManagerList function of our view and pass it the DPP spec we created in the previous line. When we run this we get the following output:

Id           : QML5Zhf++WjN2WcyOgEeNyzTdatxaAHj
Name         : NVIDIA L4-4Q profile
Description  : DPP for L4-4Q profile
VendorName   : Nvidia
DeviceConfig : VMware.Vim.DirectPathProfileManagerVmiopDirectPathConfig


Id           : LZYJZ1jfbn9zSli2xwatXrvO7FICWh+z
Name         : NEW --> NVIDIA L4-3B profile
Description  : NEW vGPU Profile in 19.0
               DPP for L4-3B profile
VendorName   : Nvidia
DeviceConfig : VMware.Vim.DirectPathProfileManagerVmiopDirectPathConfig


Id           : 3QuKKcBqBXRj1oF/fAwUAcjUXX5qWpio
Name         : L4-1Q profile
Description  :
VendorName   : Nvidia
DeviceConfig : VMware.Vim.DirectPathProfileManagerVmiopDirectPathConfig


Id           : ibQrFoQHGzIfYVVhQt9YZLTLyi2FYGnU
Name         : NVIDIA L4-2Q profile
Description  : DPP for L4-2Q profile
VendorName   : Nvidia
DeviceConfig : VMware.Vim.DirectPathProfileManagerVmiopDirectPathConfig


Id           : ucbsCQSDIl3CHG5b2WGDvfADuCUorM8t
Name         : NVIDIA L4-6Q profile
Description  : DPP for L4-6Q profile
VendorName   : Nvidia
DeviceConfig : VMware.Vim.DirectPathProfileManagerVmiopDirectPathConfig

It’s all the DPPs defined in the environment. This can be helpful when you need to know names or objects in the environment. You can iterate through the list and get details for each DPP.

Wouldn’t it be great if we could filter the list, find just the vGPU profile we are interested in? We can do that! Remember that $Spec variable we created in the previous PowerShell script? We’re going to use it now to filter our list to just a single DPP.

#------------- List specific DPP specs -------------
$DPP_MGR = Get-View -Id 'DirectPathProfileManager-DirectPathProfileMgr'
$Spec = New-Object VMware.Vim.DirectPathProfileManagerFilterSpec
$Spec.Names = 'NEW --> NVIDIA L4-3B profile'  #Accepts single items or arrays
$DPP_MGR.DirectPathProfileManagerList($Spec)  

In the above code block you’ll see that we added one new line. We added the $Spec.Names and set the value to a profile name. This allows filtering for only a specific DPP. This will come into play in a moment. The output from this code block looks like the following:

Id           : LZYJZ1jfbn9zSli2xwatXrvO7FICWh+z
Name         : NEW --> NVIDIA L4-3B profile
Description  : NEW vGPU Profile in 19.0
               DPP for L4-3B profile
VendorName   : Nvidia
DeviceConfig : VMware.Vim.DirectPathProfileManagerVmiopDirectPathConfig

DirectPathProfileManagerQueryCapacity(Target, Capacity_Query)

What we did was pretty cool, still not very useful on its own. Let’s step it up and do some capacity queries. This is where the usefulness starts to show. The capacity queries give us the utilization of our GPUs that we see in the GUI. Let’s start with the Cluster level and se what’s happening across all the hosts. This code snipit is a bit longer than the previous one but uses much of what we just saw.

$DPP_MGR = Get-View -Id 'DirectPathProfileManager-DirectPathProfileMgr'
$Spec = New-Object VMware.Vim.DirectPathProfileManagerFilterSpec
$Spec.Names = 'NEW --> NVIDIA L4-3B profile' 
#vSphere Cluster
$Cluster_View = Get-View -ViewType ClusterComputeResource -Filter @{"Name" = "GPU Cluster"}
#DPP Cluster
$DPP_Target_Entity = new-object VMware.Vim.DirectPathProfileManagerTargetCluster
$DPP_Target_Entity.Cluster = $Cluster_View.MoRef
#Target
$DPP_QC = New-Object VMware.Vim.DirectPathProfileManagerCapacityQueryByName
$DPP_QC.Name = $spec.Names
$DPP_MGR.DirectPathProfileManagerQueryCapacity($DPP_Target_Entity, $DPP_QC)

The first three lines should look familiar from the previous code blocks. Next we need to get our cluster object that we want to get DPP details from. We do this with a get-view call. Now we are going to create a target object with a type of DirectPathProfileManagerTargetCluster. We then set the cluster value to the MoRef of our cluster.

Using the MoRef of our cluster is important, as the query capacity function only operates with full objects.

Lastly we create our capacity query object and pass it the Spec we created on line two and set on line three. This gives us the following output:

Profile           : VMware.Vim.DirectPathProfileInfo
Consumed          : 1
Remaining         : 7
Max               : 8
UnusedReservation : 0

It shows how the specific vGPU profile is being consumed. Now we’re getting somewhere! We should see how we can query a specific host. That’s what this next block of code does.

$DPP_MGR = Get-View -Id 'DirectPathProfileManager-DirectPathProfileMgr'
$Spec = New-Object VMware.Vim.DirectPathProfileManagerFilterSpec
$Spec.Names = 'NEW --> NVIDIA L4-3B profile'  
#vSphere Host
$Host_View = Get-View -ViewType HostSystem -Filter @{"Name" = "ESX04.wondernerd.local"}
#DPP Host
$DPP_Target_Entity = new-object VMware.Vim.DirectPathProfileManagerTargetHost
$DPP_Target_Entity.Host = $Host_View.MoRef
#Target
$DPP_QC = New-Object VMware.Vim.DirectPathProfileManagerCapacityQueryByName
$DPP_QC.Name = $spec.Names
$DPP_MGR.DirectPathProfileManagerQueryCapacity($DPP_Target_Entity, $DPP_QC)Now lets look at a specific host. 

If you look this code block, at first glace it probably appears identical to the previous block. In reality we made two minor changes when we want to look at DPP for a specific host. We changed lines 5, 7, and 8. First we get a view containing our host on line 5. Then we call DirectPathProfileManagerTargetHost on line 7, and set the .host value on line 8. Everything else is the same as the cluster level. Which provides the following output:

Profile           : VMware.Vim.DirectPathProfileInfo
Consumed          : 1
Remaining         : 7
Max               : 8
UnusedReservation : 0

We can see that this host has one L4-3B profile consumed on it and can support 7 more. Now we have a complete set of tools to work with. Now we are going to make this do some cool stuff.

Something Useful

This is sort of useful. There are several things we can do at this point. We can use this to optimize VM placement for vGPUs, for example, I want all the L4-3B vGPUs consolidated on the same host, or maybe I want to use this with a VDI by day compute by night scenario, or something else. The possibilities are really endless. In this case I’m just going to share a simple script that just powers up several VMs until it reaches a specific amount of GPU capacity and then shuts them down.

$DPP_MGR = Get-View -Id 'DirectPathProfileManager-DirectPathProfileMgr'
$Spec = New-Object VMware.Vim.DirectPathProfileManagerFilterSpec
$Spec.Names = 'NEW --> NVIDIA L4-3B profile'  #Accepts blank, single, or arrays
#vSphere Host
$Host_View = Get-View -ViewType HostSystem -Filter @{"Name" = "ESX04.wondernerd.local"}
#DPP Host
$DPP_Target_Entity = new-object VMware.Vim.DirectPathProfileManagerTargetHost
$DPP_Target_Entity.Host = $Host_View.MoRef
#Target
$DPP_QC = New-Object VMware.Vim.DirectPathProfileManagerCapacityQueryByName
$DPP_QC.Name = $spec.Names

#Priming Read
$DPP_Usage = $DPP_MGR.DirectPathProfileManagerQueryCapacity($DPP_Target_Entity, $DPP_QC)

Write-Output("Setting Vars:")
$Reserve_VM_Space = 2
$VM_Floor = 0
$Starting_VM = $DPP_Usage.Consumed + 1

Write-Output("Starting Loop")
Write-Output("DPP Remaining: " + $DPP_Usage.remaining)
Write-Output("Reserved Space: " + $Reserve_VM_Space)
while ($DPP_Usage.remaining -gt $Reserve_VM_Space) {
    #Create VM Name
    $VM_Name = "VM_GPU_0" + $Starting_VM
    Write-Output("Starting VM: " + $VM_Name)
    $Next_VM = Get-VM -Name $VM_Name
    Start-VM -VM $Next_VM
    $DPP_Usage = $DPP_MGR.DirectPathProfileManagerQueryCapacity($DPP_Target_Entity, $DPP_QC)
    $Starting_VM = $Starting_VM + 1
}
Write-Output("No more VMs to start. Cleaning up") 
Start-Sleep -Seconds 20
Write-Output("Starting Value is: $Starting_VM")
while ($DPP_Usage.remaining -gt 1 -and $Starting_VM -gt 1){
    $Starting_VM = $Starting_VM - 1
    #Create VM Name
    $VM_Name = "VM_GPU_0" + $Starting_VM
    Write-Output("Stoppinng VM: " + $VM_Name)
    $Next_VM = Get-VM -Name $VM_Name
    Stop-VMGuest -VM $Next_VM -Confirm:$false
    if ($Starting_VM -gt $VM_Floor){
        do {
            Start-Sleep -Seconds 5
            $Next_VM = Get-VM -Name $VM_Name
            $VM_Power = $Next_VM.PowerState
            Write-Output("The power state is: " + $VM_Power)
        } until ($VM_Power -eq "PoweredOff")
    }
    else {
        Write-Output("Reached the floor. Bye!")
        break
    }
    $DPP_Usage = $DPP_MGR.DirectPathProfileManagerQueryCapacity($DPP_Target_Entity, $DPP_QC)
}

Everything until the priming read looks identical to what we had seen previously. From there it gets into basic coding. We have a loop that goes through and counts up as we start more VMs. Each time it checks to see what the new DPP numbers are and goes until it reaches the capacity set.

We then wait 20 seconds for all the VMs to fully come on line, at which point we start powering them down. And that loops through shutting down the VMs. Here’s a video of what running the code looks like.

That brings us to the end of this blog. I’m going to cover the python version of this code in another blog as there are still some things being worked out. In summary DPPs are an awesome addition to VCF and VVF 9.0. You should check them out!

Permanent link to this article: https://www.wondernerd.net/vcf-and-vvf-9-new-gpu-management-scripting-with-powershell-and-python-codeqt1767lv/

Make Room for Another End User at the EUC Table

Last week (August 4th through the 7th 2025) I attended the EUC World conference. It was a great time where I got to nerd out on all things end user computing (EUC). I realized on Wednesday that soon, we nerds will be adding another end user to the EUC table.

Visionary

I’m going to start by prefacing this with, when I have these moments of inspiration, they take about six years or more to become mainstream. For example, at GTC17, I had the idea of and started working on how to create a GPU based storage system, and this year Jensen started talking about all the storage vendors working on it. Additionally, there is VDI by day compute by night, which has just recently had key parts incorporated into major hypervisors, I was working on it before 2018. The same is true with vGPU based developer virtual desktops. It was the topic of my 2018 NVIDIA GTC breakout session and it’s now all the rage.

So, if history is any indication, what I’m about to discuss will be the big thing for EUC and AI around 2031, maybe sooner as hot as AI is right now. We will just have to wait and see.

What is this new EUC user?

You’re probably wondering what this new user type is that’s going to take EUC and AI by storm is. Simply put, it will be an agentic agent user. For those unfamiliar with the concept of agentic agents, all the geeks on TV keep talking about how these AI agents will be able to do things for you, like book dinner reservations, or hotels, schedule meetings, and other mundane tasks. This will make you a manager or conductor of many of these agents, telling them what you need, and they will go out and do it for you. In the coming years you may have 1, 3, 10, or hundreds of these agents at your beck and call making you more productive.

Humans and robots working in cubicles with virtual desktops delivered by EUC as someone looks out over the vast expanse of users. 

This image is AI generated using the following prompt in Copilot:

Create a digital illustration of a vast office landscape filled with hundreds of cubicles stretching to the horizon. Each cubicle is separated by light gray walls and contains either a humanoid robot or a human worker seated at a desk with a computer. Approximately 80% of the cubicles should contain robots, and 20% should contain humans. The robots should vary in eye color (e.g., blue, green, amber, violet) and some should wear ties to resemble office attire. The humans should be dressed in typical business clothing. The humans should be both male and female. The humans should represent different nationalities. There should be only one human or robot per cubical. In the foreground, include a person standing in an elevated position, looking out over the cubicle grid as if surveying the scene. The overall tone should be muted and professional, with soft lighting and a sense of depth created by the receding cubicles.

If you are grounded in present day reality, you’re probably thinking that agentic agents use the same interfaces and systems that we use, they don’t need anything different. If we ask an agentic agent to book a hotel for the next EUC World, the agent will query the web, to find out where EUC World is, then looks for hotels in the area on Google or another system, next it selects the optimal hotel, uses the hotels booking system, and books it for me.

This sounds like a regular user? We don’t need a different user type for this? They can just use a regular system? Right? Right? RIGHT?

Today’s EUC isn’t optimal

They can, but it’s not optimal. For example, if I give an architect a virtual desktop designed for an accountant and tell them to create a new facility. They can probably do it, but it won’t be efficient or easy to do. You want to give the end user the best tools to do their job.

The same holds true, in the future, for these agentic agents. They don’t need a mouse, meta data will be important, they aren’t as susceptible to marketing ploys, and well pop-ups for car insurance won’t really work. They will need new “desktops” optimized for them to use.

Possibilities

The first generation of agentic agents are just now being developed. They are trying to get them to accomplish tasks correctly and until that happens optimized workspaces are not going to exist for agentic agents.
When that happens a whole new set of ponderances will emerge:

  • Will all agents use the same type of workspace? (I seriously doubt it.)
  • How will these new workspaces be licensed?
  • Will a given number be included per human seat, so for every user they get x number of agentic agent workspaces? Or will you buy workspaces per agent and agent operation?
  • How will they be managed?
  • Are traditional approaches sufficient or do we need more advanced tools to enable their management?
  • How will that management system be licensed? If I onboard one human with 7 agentic agents, is that 8 seats or 1 seat in the management system?
  • Agents may not be persistent, are the workspaces?
  • How quickly do these workspaces need instantiated?
  • And the list goes on…

Just an API?

I’m sure someone reading this is thinking this sounds like an API, not something that needs a workspace. An API might be a way we get information from these agentic agents but is that how they do their work? For example, chances are you have or have had a boss. If your boss asks you to write a paper on how agentic AI will reshape your industry. That request may have come in the form of an email, or during a meeting, or a direct message. That’s your boss’s interface to you. It says nothing about how you accomplish the task; you might pop the request into Copilot or ChatGPT, you might hit up google for details, or you may go and interview your co-workers to get their feedback.

How you perform each of those tasks may require a different method, maybe even a different user interface. This is why I think it is inevitable that in the future our agentic agents will be new end users with new workspaces. I guess we will see in about six years.

Permanent link to this article: https://www.wondernerd.net/make-room-for-another-end-user-at-the-euc-table/

VMUG EUC Day Session: Virtual Desktops, GPUs, and Things You Didn’t Know You Could Do

Did you know AI is an ideal workload to run in an EUC environment? That’s what I cover in this VMUG EUC Day session, Virtual Desktops, GPUs, and Things You Didn’t Know You Could Do. We explore how AI instances benefit from virtual desktop environments and why organizations who are developing AI workloads should consider running their AI development environment with EUC functionality.

This session is part of the VMUG EUC day being offered today. You can find out more and check out all the great content at on the VMUG website. There will be many great presenters that are well versed in all areas of EUC. I recommend watching it live or in replays if your day is already full.

You can download the slides from my session to view and make notes if you would like.

After EUC Day is over I’ll post the session recording and you can watch the session at your leisure. Should you have questions following the event you can use the contact page to reach out with them or any of the other methods I mentioned in the session.

For those wondering why you want to do AI in a EUC environment, it boils down to the ability to have a known powerful set of management tools for you workload and having the ability to deliver that environment both repeatably and quickly for AI developers. Additionally it makes it easier for developers to consume AI resources like they do any other environment. This is a win – win for almost all organizations and unlocks the synergies of AI and IT.

I hope you enjoy the session!

Permanent link to this article: https://www.wondernerd.net/vmug-euc-day-session-virtual-desktops-gpus-and-things-you-didnt-know-you-could-do/

Unlocking the Magic of Gen-AI in VMware VCF: Where Dreams Meet Reality

If you had the chance to join us live for this community session at VMware Explore for session CMTY2254LV, thank you so much. If you are checking it after the event thank you as well! Your support means the world to us. This page contains links to the videos, the session abstract and a bunch of information for the session we submitted. If you have any questions or need additional details about unlocking the magic of GenAI in VMware VCF, please contact me.

VMware Explore Session Title Slide: [CMTY2254LV] Unlocking the Magic of Gen-AI in VMware VCF: Where Dreams Meet Reality

The abstract for this community session is:

The abstract for the session is: “Join us for an electrifying session where we decode the AI buzz and reveal its practical magic! Visionary leader Gina Rosenthal and renowned vExpert Tony Foster will guide you through the AI labyrinth without the jargon overload. Explore the inner workings of large language models (LLMs), demystify training and inferencing, and discover the secret sauce of retrieval-augmented generation (RAG). Learn how Gen-AI differs from traditional AI and how it can supercharge your business strategy, especially within the context of VMware VCF. We’ll delve into the intricacies of integrating Gen-AI seamlessly into your existing IT infrastructure, unlocking untapped potential. Get ready to leave this session with a data scientist’s swagger, poised to infuse AI brilliance into your organization! Don’t miss out!”

We have made a PDF copy of the slides available.

The session is available from VMware TV on YouTube under the live section:

This session really is about demystifying all the stuff that’s happening behind the scenes when it comes to AI. In short there is nothing magic or crazy happening, its just a computer program doing a big math problem. We hope you enjoyed the session or the replay!

Permanent link to this article: https://www.wondernerd.net/unlocking-the-magic-of-gen-ai-in-vmware-vcf-where-dreams-meet-reality/

Quantum Computing: What Are You Scared of? [INVB1447LV]

This is the 2024 VMware Explore session that John and I presented on Quantum Computing. It was a well attended session for the last day and last time slot of the conference. I’m sharing the details of the session with those interested here.

Cover slide for the 2024 VMware Explore Session: Quantum Computing: What Are You Scared Of?

Session Abstract: The advent of quantum computing heralds a new era of computational power, promising unprecedented capabilities that could revolutionize industries and scientific research. However, along with its potential benefits comes a looming specter of uncertainty and fear. In this presentation, we delve into the implications of quantum computing, exploring the potential negative disruptions it could bring. One of the primary concerns is quantum hacking, where conventional encryption methods become vulnerable to quantum algorithms. As companies race to adapt their security technologies to fend off these threats, it begs the question: Are we adequately prepared for the quantum era? Join us as we navigate through the risks and challenges posed by quantum computing and contemplate strategies to mitigate its potential adverse impacts.

The recording of the session can be found on the Explore Video Library.

If you would like to view the slides presented a PDF copy we are pleased to share them with you. Should you have any questions about the content presented please feel free to use my contact page to reach out to us.

Permanent link to this article: https://www.wondernerd.net/quantum-computing-what-are-you-scared-of-invb1447lv/

AI Qubits You Need for Your VMware Explore Schedule

You got approval to attend VMware Explore this year! That’s fantastic, I look forward to seeing you there. By now you have probably started to build your schedule in session builder. I have a few Explore sessions you might want at the top of your list. And some of you might be wondering what AI Qubits are.

AI Qubits written in green with a multi-color quantum foam a.

As of today, they don’t exist, they aren’t real. They sound cool though, don’t they? I’ll be presenting on topics related to both qubits and AI this year at Explore. We’ll be breaking down topics to their atomic parts and spinning them to get the answers people are curious about.

I bet that means you’re curious about what all these sessions are.

There are four of them, and they range from introductory to deep dives and futuristic exploration of topics. The four sessions you will want to attend are:

Catch these sessions at VMware Explore:
•	Quantum Computing: What Are You Scared Of? [INVB1447LV] on Thursday, August 29th at 10:15 AM
•	Unlocking the Magic of Gen-AI in VMware VCF: Where Dreams Meet Reality [CMTY2254LV] on Thursday, Aug 29th at 9AM
•	Unlocking vGPU Power: From Code to vCenter Plugin [CODE2229LV] on Monday, August 26th, at 11AM
•	Empowering Virtual Environments: The vGPU Resource Scheduler Plug-in [CMTY2241LV] on Monday, August 26th at 1PM

Needless to say, you should be able to find me fairly easily Monday and Thursday (hint check the community space).

You are probably wondering about all these sessions and they’re making your head spin faster than a couple of entangled qubits.

Let’s start with the breakout session on quantum computing. John Arrasjid (VCDX001) and I are talking about the perceived perils of quantum computing. You may have even heard that quantum computing is going to break encryption sometime “really soon” and it’s going to be pandemonium. We’re going to demystify all this and talk about what it will take to achieve this, where we’re at currently, and what IT teams can start doing today to protect themselves from the big scary quantum computers whose qubits are smaller than the tip of a pin. Never have so many big companies and governments been scared of something so small, welcome to the future.

Quantum Computing: What Are You Scared Of? [INVB1447LV] on Thursday, August 29th at 10:15 AM

Speaking of the future let’s look at the session on unlocking the magic of Gen-AI. This isn’t a deep technical community session that will teach you to deploy an AI model on VMware VCF in under 30 minutes. That would be pretty cool, and I think it can be done, but that’s not what we are talking about in this session. Gina Rosenthal and I are going to break apart all the hype around AI and make it easier for folks to understand from how does AI and LLMs even work to what is RAG and why we need it. We also answer the question why you would want to run AI in a VCF virtual environment. This is going to be a fun session that allows almost anyone to sound good in a room and know what they’re talking about.

Unlocking the Magic of Gen-AI in VMware VCF: Where Dreams Meet Reality

Now it’s time to dive to the depths of things you can do with AI in my VMware Code session on taking code and turning it into a vCenter plugin. That’s exactly what I will demonstrate in this 25-minute Code session. Here a few years back I created some simple but powerful scripts that most people know as “VDI by day and Compute by Night.” The idea is simple you have all these users on virtual desktops (AKA Omnissa Horizon) with Virtual GPUs (vGPUs). Well, most users only use those desktops for about 1/3 of the day the rest of the time those resources are idle. My scripts allow you to recover those unused GPU resources and run your AI or other GPU intensive workloads on the idle GPUs.

I’ve converted those scripts into python and a REST API, during my code session, we are going to take that API and use it as the base for a vSphere plugin. We’ll explore the underlying structure of a plugin and all the things that need to exist to create one. Then we will do exactly that. Take my code and turn it into a functional plugin allowing you to reclaim vGPU resources in your environment.

Unlocking vGPU Power: From Code to vCenter Plugin

That brings me to the last session I’ll be presenting at Explore. I’ll show you how to install my resource recovery plugin in your own test/dev environment along with what you can do with it. It’s got some cool features not found in the scripts and it should make administering vGPU environments a lot nicer. I’d share some of the features, but they’re not all written yet, so you’ll have to wait for Explore.

Empowering Virtual Environments: The vGPU Resource Scheduler Plug-in

As a bonus, you will also want to attend Jodi Shely and John Arrasjid’s session on Resilient Infrastructures: Self-Healing with VCF, Aria & VMware Ecosystem [VCFB1444LV]. I’ve had a preview of the deck for this session, and this is one of the holy grails of IT, self-healing environments. If you manage an enterprise IT environment you’ll want to be in the audience and see how the concept of resilient infrastructures can help you move beyond keeping the lights on.

That’s a lot of content on the buzz worthy topics of AI and quantum computing. If you are attending explore and are even thinking about AI or quantum computing these are some of the sessions, you cannot afford to miss. They will help provide clarity on how both are continuing to grow and transform the datacenter and improve operations.

I challenge you to plunge your hands into the quantum foam at VMworld this year, seize some qubits, and elevate your knowledge.  

Permanent link to this article: https://www.wondernerd.net/ai-qubits-you-need-for-your-vmware-explore-schedule/

Quantum Leap: The Ever‐Changing Virtual Space of Quantum Computing [VMTN3079LV]

Thank you to everyone who was able to attend our session at VMware Explore in Las Vegas. The VMTN vBrownBag Tech Talk, VMTN3079LV, John Arrasjid and I presented on the Quantum Leap: The Ever‐Changing Virtual Space of Quantum Computing had great attendance. For those who want to watch it again or weren’t able to attend you can find both the slides and the recording below.

It’s important to reiterate that Quantum Computing is still an emerging technology and the capabilities it will provide in the future are still anyone’s guess. What we present in this session are just hypothesis about what could be possible. We have presented them here as a way to start the conversation and get folks thinking about what could be. The exciting time in the quantum fields are still to come.

Some great references on quantum computing can be found here:

If you have questions please use the contact me page and I will share the ask with John.

Permanent link to this article: https://www.wondernerd.net/quantum-leap-the-ever%e2%80%90changing-virtual-space-of-quantum-computing-vmtn3079lv/