VMware Explore VMTN3082LV – The SEO Strategies for My Community Blog That Gave Me Six-Pack Abs

Thank you to everyone who was able to join my session in person at VMware Explore in Las Vegas. I was honored to present the vBrownbag Tech Talk on “The SEO Strategies for My Community Blog That Gave Me Six-Pack Abs.” I am really excite that I had more that six people in the audience for one of the last sessions of the conference. In this post you can find my slides, the recording of the Tech Talk and some discussion of material that those in attendance asked following the session.

The SEO Strategies for My Community Blog That Gave Me Six-Pack Abs [VMTN3082LV] Cover slide for VMware Explore 2023 vBrownBag Tech Talk.

Below is the video recording of the session:

One of the questions following the presentation that came up was about AI generated content. The initial question that was asked was about the use of AI generated content for blogs. My answer for the foreseeable future is honesty is the best policy, you should disclose on both personal and commercial blogs that the certain content was AI generated.

Obviously, SEO systems are actively looking to determine if content is AI generated. They are or will be using the same (or better) tools as others to detect AI generated content. And if you aren’t upfront about it, they may eventually start dinging your SEO score. So you need to be honest about it, and the sooner the better.

In my personal opinion, there is nothing wrong with using AI generated content. If you don’t learn to do it someone else will. I haven’t done it on any of the blogs I write, as I’m waiting for the legal and business stuff to all shake out. Also, a lot of stuff I blog on wouldn’t be known by AI yet because its either a hair brained idea or it’s internal information.

Which brings up the last interesting point from the follow on discussions about my session. Everyone is trying to detect AI generated content for a lot of reasons. One is around not deceiving the reader, which we talked about above. Another major factor for businesses and government agencies is the disclosure of non-public information, be it outright inclusion or inclusion in the AI model. Both can be damaging and this is why so many vendors are starting to offer private models for organizations, so that corporate users can get the same ChatGPT experience but not leak sensitive information. Which, again is another good reason to disclose something is AI generated upfront.

If you have questions hit me up in the contact me page, tweet me on twitter, or DM me on Linked In.

Permanent link to this article: https://www.wondernerd.net/vmware-explore-vmtn3082lv-the-seo-strategies-for-my-community-blog-that-gave-me-six-pack-abs/

VMware Explore VMTN3081LV – AI on the Horizon: Delivering Virtualized AI Environments to Students

Thank you to everyone who joined me for VMTN3081LV at VMware Explore. It was great having the opportunity to present “AI on the Horizon: Delivering Virtualized AI Environments to Students.”

This session started as a submission as a full session, then was whittled down to a 26 minute vBrownbag Tech Talk, and finally squeezed in as 12ish minute vBrownbag Tech Talk. Which I’m sure you can guess means, each round more and more information got taken out. At some point I will record the full hour long version with a live demo, until then This is the goodness that is my vBrownbag.

You can watch the presentation here:

You can also download a copy of my slides for VMTN3081LV.

If you would like to find out more about this design, please use the contact me page.

Permanent link to this article: https://www.wondernerd.net/vmware-explore-vmtn3081lv-ai-on-the-horizon-delivering-virtualized-ai-environments-to-students/

2023 GTC Submission Abstracts (I just had to share)

One of the things I have wanted to do for a while is to post the abstracts I submit for various conferences. This is my first attempt at doing just that. These are the abstracts I can publish, that I submitted for NVIDIA GTC 2023 (spring). There is one abstract I can’t share with folks because it’s closely related to a project I’m working on. It’s also worth noting that none of these abstracts were accepted for the conference this year. However if you have a user group or a conference where you would like to hear about these topics please use the contact page and let me know.


Session Title: How to deliver Red Hat OpenShift with NVIDIA GPU capabilities on bare metal hyper-converged infrastructure

Session Abstract: Your organization uses Red Hat OpenShift for its workloads from containers to VMs. The only thing left to do… get your NVIDIA GPUs up and running in your OpenShift environment. Oh yeah, it’s on bare-metal, and you need to support multi-instance GPUs (MIG). This might sound daunting to accomplish. First you must install the NFD Operator, then the NVIDIA GPU operator, and finally you’ve got to configure MIG. If all that seems like a foreign language don’t worry, Tony and Praphul will guide you through the process step by step. They will demonstrate step by step how to bring NVIDIA GPUs into your OpenShift environment. They will even take it one step further and do it on a Dell PowerFlex hyper converged bare metal environment. If you’re using Red Hat OpenShift this is a session you won’t want to miss.


Session Title: Your MLOps desktop delivered virtually, the details behind the magic

Session Abstract: MLOps, it’s been a big buzzword for a few years. Everyone is trying to hire MLOps engineers from the financial institutions, to retailers, to the agriculture industry. That comes with some big issues for IT, like how do we get someone working from home a powerful MLOps capable work environment? And even more importantly how do we do it at scale? In this session join the WonderNerd for a deep dive into the magic of delivering Linux based virtual desktops for MLOps users. We will look at how to build Linux VDI environments using VMware vSphere and VMware Horizon. This session will go well beyond traditional VDI use cases, covering multi-instance GPUs (MIG) and designing virtual desktops with multiple vGPUs. We’ll then look at how these virtual desktops can be integrated with an existing MLOps strategy to scale as more engineers join the organization. We’ll even look at some examples of how all this can be easily automated as well as ways to reclaim resources at the end of a project.

Permanent link to this article: https://www.wondernerd.net/2023-gtc-submission-abstracts-i-just-had-to-share/

Talk Nerdy to Me VMworld {code} Session 2778

You’re in the right place if you are looking for resources from VMworld Code Session 2778 – Talk Nerdy to Me, Using Python to Create VMs with vGPUs for AI Workloads. Thank you to everyone who was able to join the session live. For those who weren’t able to attend the live session, you can catch the replay of it on VMworld.com.

Below you will find the slide deck of material I had for the session, it includes the code snipits I used during the presentation. You can also find the fully functional blocks of code up on GitHub in my VMworld21 repo, you’ll just need to update credentials/vcenter.

Click to download the CODE2778 Talk Nerdy to Me Slide Deck

This is a short 30 minute session and there’s a lot to cover when working with GPUs and VMs. Hopefully this session covers the material you need to get started in automating the creation of VMs with GPUs for AI/ML/DL/HPC workloads. Because everyone’s situation is different it’s very difficult to create a script that sorta fits for everyone.

UPDATE: The VMware {code} team posted the videos up to you tube you can watch my session below.

The Code

The way I’ve set the table for this session is starting out with a connection to the vCenter (I know it seems simple). From there we capture the GPUs in a host as well as what vGPU profiles those GPUs/hosts support. Next we add a vGPU to a VM programmatically and then remove it. Once we’ve worked through those basics we bring it all together and create a VM with a vGPU.

Now lets break down some of those parts as to why they are important. First of all it’s important to know that we have GPUs in the hosts we are working with. By using the first script to detect GPUs in the host we can do a safety check on our hosts to make sure we are able to do what we want. There are also many other things we can do with that information.

Next when creating an AI VM, you need to know what profiles are available to consume in that VM. It’s better to do this programmatically than to manually assign profiles. This is important especially when you have multiple GPUs in your environment and you need the right one for the right VM. Malformed VMs won’t start and that leads to service problems and user dissatisfaction. This is why knowing the vGPU profiles are important.

Now we get into the the actual meat of this, we add a vGPU to an existing VM. This may be all some folks need to do, they may already have VMs created and just need a vGPU profile to it. It’s really the foundational process to get a vGPU into a VM weather its at creation or later on.

Next we perform some clean up of the VM. This isn’t really necessary for VMs, it’s just helpful to know how to do it. This set of code modifies the VM and removes the last vGPU in the VM. If you want to be a bit more specific about which vGPU you want to remove from the VM, you’ll need to be a bit more specific in the for loop to pick the one you want to remove.

Lastly we bring this together and create a VM programmatically. This script is just a slight modification of the pyVmomi Community Samples to create a VM. You’ll see we took a bit of the code from the add a vGPU to a VM and pasted into the create a VM code sampe. That adds the vGPU to the VM when we create it. Now we just run the code using a quick script.

All of that fills up a 30 minute session really quickly. Especially with questions.

What to do with this?

Those bits of code are all you need to start creating VMs for AI/ML workloads. You need to incorporate them into your automation processes.

I didn’t deploy an OS or install the vGPU drivers during this session, that really outside the virtual hardware side of things, its the same reason I don’t deploy an app in this session. Additionally I’ve found that AI admins get really particular how these things get setup and would get very cranky about an outsider like me saying how it should be done.

A few other things you should know. First you need to use a vGPU profile that consumes the entire GPU if you want to have multiple vGPUs on a VM. Partial vGPU profiles will not work. So in my demo with the P4 GPU I need to use the P4-8Q or P4-8C profile for it to be able to power up. The other part of that is the profiles have to be the same for all vGPUs in the VM, so if you have an P4-8C and a T4-8C those can’t be on the same VM. They all have to be the same.

Hopefully this content is helpful content. If you have questions, or want to see more drop a comment at the end of the blog.

Now for some fun stuff

I’d like to thank the VMware {code} team for all their help promoting this session. They did a fantastic job with the promo video for this. You get to see me in my cape and WonderNerd glasses.

https://twitter.com/i/status/1443266825123340288

I did another version of a video tease for this. It was decided it may be a bit risque and is almost not safe for work. If you would like to watch it send me a DM.

I hope you enjoyed VMworld!

May your servers keep running and your data center always be chilled.

Permanent link to this article: https://www.wondernerd.net/talk-nerdy-to-me-vmworld-code-session-2778/

VMTN2835 – Update to VDI by Day Compute by Night

This is a quick post for my VMworld 2021 vBrownbag session VMTN2835. This session covers updates to the VDI by day compute by night scripts that I’ve been writing and updating for a couple of years. You can download all of the modules needed for this from my GitHub repo. The session is airs at 2:15 PM Central Time on October 5th.

VMworld 2021 vBrownbag session VMTN2835 front slide. Click to download the slide deck.

You can download the slide deck here or by clicking on he picture above. The demo of how the scripts work is part of the session. To watch the session, please sign up for VMworld and you can catch it on replay if you missed the live session.

UPDATE: A little while after VMworld the vBrownbag team posts the videos up to their YouTube channel. You can now watch the video below.

Some may ask why this collection of modules isn’t bundled up as a single set of scripts. I’ve done it this way because they can be used independently of the rest of the scripts. For example you may want to gather profile information about the GPUs in your hosts, or you may want to determine the carrying capacity of your hosts. Both of these can be done done with the scripts independently and don’t require the entire VDI by day set of scripts.

There are a several changes to the script that I talk about in the session. To quickly recap those for you, they are:

  • Support for the NVIDIA Ampere line of GPUs – A100, A40, and A10, the A16 will follow shortly after GA
  • A new module that gathers supported vGPU profiles from the environment instead of relying on a hard coded list
  • A lot of new parameter updates to be compatible with vSphere 7.0 U2
    • The view commands no longer support multiple hosts states
    • The default host states have been changed to “Connected” only
    • Work has been done to change from using the get-VMhost command

Looking at that list you can probably guess the next two items that will be changing soon for these scripts. First we will be changing to a get-View command to speed things up, especially for larger environments. The other one is to support the A16 GPU when it GAs. Though it is worth noting that, it’s not a good candidate for VDI by day compute by night because it’s optimized more for VDI than AI/ML. This is not unlike the A100 & A30 which can’t be used to drive graphics in VDI. The optimum card for most will be the A40.

For the rest of whats been updated be sure to catch VMTN2835. I hope you have a great VMworld, any feedback on these modules is greatly appreciated.

May your servers keep running and your data center always be chilled.

Permanent link to this article: https://www.wondernerd.net/vmtn2835-update-to-vdi-by-day-compute-by-night/

New PowerCLI Module – Finding vGPU Profiles

For those who’ve seen or are using my VDI by day Compute by Night PowerShell scripts you may have noticed that the vGPU profiles are entered manually in an array. Wouldn’t it be nice if those vGPU profiles could be easily captured and loaded into an array? That’s what this module does. This post is a deep dive on the PowerCLI module for finding vGPU profiles. It is now a key module in the VDI by day Compute by Night scripts and returns an object collection of vGPU profiles.

List of vGPU profiles supported by a host as shown in the VMware Managed Object Browser (MOB)

The vGPU_Profiles_In_Environment PowerShell module checks hosts, retrieves the supported vGPU profiles, and is now called in the VDI by Day script. This new module make this script more efficient, that’s because the script no longer has to iterate through all the GPU profiles, even for GPUs that aren’t in any of your hosts. Now you could comment out the array entries for cards not used. You just need to keep the array up to date.

You’re probably wondering at this point how it works and what’s at the set of commands at the core of this design. That’s what we’ll dig into first. Then I’ll go into how I used that to create this new module.

Breaking Down The Command

Getting the vGPU profiles can be done with two lines of code.

get-vmhost -state $vGPUHostState -location $vGPULocations | ForEach-Object { #iterate through the hosts
	#Do other stuff here
	echo $_.ExtensionData.Config.SharedPassthruGpuTypes 
}

Now you probably don’t want to just drop this code in and run it. There’s a pretty good chance you’re going to get some errors with it. Unless all the hosts that the get-vmhost view is retrieving have GPUs in them your script won’t like a call into .ExtensionData.Config.SharedPassthruGpuTypes. Most likely it will throw an error and kill your script. That’s part of the reason I have those two lines separated by several other lines of code in this module.

The way this code works is it takes an array of ESXi hosts and iterates through them in a ForEach loop. The resulting object variable (that represents a host) is represented as $_ . Having the host, we can then check to see if it has the .ExtensionData.Config.SharedPassthruGpuTypes properties.

If you look up .ExtensionData.Config.SharedPassthruGpuTypes in the Managed Object Browser for your vCenter (provided you have a host with an NVIDIA GPU) you will see that this returns a string array type. That array contains all the supported vGPU profiles for that GPU. It also means you can pass that array or iterate through it and perform some work on the profiles like I did in the new module. Which is where we’re heading next. I’m going to break down how the new module works for you.

Exploring the Module

You can get the module were looking from my GitHub repo. We’re going to break down the lines of code that make up the module. We’ll start at the top and work our way down through the module.

The first several lines of code define the function. It takes two optional arguments, $vGPULocations and $vGPUHostState. One tells us where we are looking for the vGPUs, by default it looks for all (*) hosts. The vGPUHostState is the state of the host in vSphere. This can be connected, disconnected, notresponding, or maintenance. You can pass only one of these states to the get-vmhost-view as of vSphere 7.0 U2. This shouldn’t be a problem. Rarely will you want to run this against anything but “connected” hosts. And even rarer still is running it against multiple states.

Function vGPUsInASystem {
	param(
	
	[Parameter(Mandatory = $false)]
	[string]
	$vGPULocations,
	
	[Parameter(Mandatory = $false)]
	[string]
	$vGPUHostState
	# Valid states (connected,disconnected,notresponding,maintenance) or comma seperated combination 
	)

# Take care of function paramaters
		if("" -eq $vGPULocations){ #if nothing is passed set the value to all clusters
			$vGPULocations = "*"
		} 
		if("" -eq $vGPUHostState){ #if nothing is passed set the value to all states
			$vGPUHostState = "connected" #,disconnected,notresponding,maintenance"
		}

We then instantiate the list of vGPUs as a collection. with some additional information you cant get directly from the ESXi hosts.

# Create a list of GPU Specs
		[System.Collections.ArrayList]$vGPUlist = @()
			#Name, vGPU per GPU, vGPU per Board, physical GPUs per board
			#Removed examples...
			#Null
			$obj = [pscustomobject]@{CardType="empty";vGPUname="default";vGPUperGPU=0;vGPUperBoard=0; pGPUperBoard=0}; $vGPUlist.add($obj)|out-null #catch any non-defined cards and force them out as zeros
		#help from www.idmworks.com/what-is-the-most-efficient-way-to-create-a-collection-of-objects-in-powershell/

You’ll notice most of this is comments with examples of how the entries are formatted. This ties back to how we did the collection prior to this script. We follow the same configuration, which is nice because it makes it accessible to the other scripts to use without major modification. You will note that we create a single NULL or empty object in the collection. This serves as a catch for when a host without any GPUs is passed.

This is where we get into the meat of this function. The block of code below gets a host view and starts processing it. We start with a “try” to catch any errors, remember when I said if you ran just the 3 lines of code it takes to get the profiles it may fail. Hence we should catch errors even though we test for failures. Then we create our host view and loop through the objects in a for loop all in one line.

We then take the $CurrGPU variable and set it to ’empty’ before we start iterating through the host. This way we can do some garbage collection within the loop. We then take the current host ($_) and create a new view with the Get-VMHostPciDevice, where wwe are looking for a Display controller with the NVIDIA name using a wild card at the end to capture any such cards. This view is the run through a forEach loop. (Because a host may have more than one GPU.)

This will then assign the GPU type to the CurrGPU value. This process is using an assumption on my part. I’m assuming that these hosts are following manufacturers guidelines of one type of GPU per host. (Yes, I know people who have put multiple GPUs into a single host and it doesn’t “break”.) If you wanted you could turn CurrGPU into an array and get all the card types per host and do a bit of extra processing.

Once we have that we do some garbage collection and check the existing GPU collection for any identical cards in a fun little where / select clause.

Try {
		#get-vmhost -state $vGPUHostState -location $vGPULocations | ExtensionData.Config.SharedPassthruGpuTypes | ForEach-Object {
		get-vmhost -state $vGPUHostState -location $vGPULocations | ForEach-Object { #itterate trhough the hosts
			#echo '------------------------------------------------------------'
			#echo "Host: " $_.name
							
			$CurrGPU = 'empty' #Set to empty so it catches the garbage collection if the host has no GPUs
			$_ | Get-VMHostPciDevice -deviceClass DisplayController -Name "NVIDIA Corporation NVIDIATesla*" | ForEach-Object {
				$CurrGPU = ($_.Name -split " ")[3] #only get the last part of the GPU name ie P4 
			} #this wil only get the last item in the list
			
			#Echo 'Looking for GPU: ' $CurrGPU
			#check if GPU is already in the list, if so skip it
			$GPUalreadyHere = $null #Set things to Null to make sure it's caught in the check below
			$GPUalreadyHere = $vGPUlist.CardType | where { $_.ToLower() -eq $CurrGPU.ToLower() } | Select -First 1;  #Find if the GPU is already in the array

In the next block of code we check and make sure the GPU hasn’t been added to the array. If it has there’s no point in adding it again. Assuming it’s a new GPU we create a variable that deals with the largest host size and make it 0 to start with. We then go to the host ($_) and get the ExtensionData.Config.SharedPasthruGpuTypes and iterate through them with a ForEach_object loop.

			if ($GPUalreadyHere -eq $null){  #The GPU is not in the array
				
				#Added 8-3-21 as the profile size changed in a previous vSphere release
				$LargestProfileSize4Host = 0 #Set to 0 for garbage collection
				$_.ExtensionData.Config.SharedPassthruGpuTypes | ForEach-object { #itterate through the cards supported configs and find largest size

Inside of this ForEach loop we do the work of creating the object entry for the object collection of GPUs. We start by removing the “grid” entry from the returned array entry as “grid” is understood at this point and not needed.

					$CurrProfile = ($_ -split "-")[1] #Get just the profile  (ex: 8q)
					#echo $CurrCard " : " $CurrProfile

The next set of code is handling some special cases that are tied more to using this for VDI than for AI workloads, because they focus on older profiles. The first two if statements check for the 2b4 profile and the 1b4 profile. These profiles are on some older cards. They will eventually be aged off as the cards reach end of life and will no longer be a concern with the code. For now we keep them in and equate them to their 2b and 1b counterparts. We also capture the profile number here for use later in the code.

					#Safety Check for 2b4 and 1b4 profiles which should be removed eventually
					if ($CurrProfile -eq "2b4") {
						$CurrProfile = "2b"
					}
					if ($CurrProfile -eq "1b4") {
						$CurrProfile = "1b"
					}
					#echo "==============="
					#echo $CurrProfile
					$ProfileNum = $CurrProfile -replace "[^0-9]" , '' #get just the profile number
					#echo $ProfileNum

Next we perform a conditional check to make sure we are dealing with a profile larger than 0 and set it accordingly. We do this so it doesn’t matter which order the cards are listed in the vSphere array that was returned and we are currently iterating through. We then exit out of the if the GPU and thus its profiles are in the array conditional check.

					if ($ProfileNum -gt $LargestProfileSize4Host) {
						$LargestProfileSize4Host = $ProfileNum #find the largest profile size and set it
						#echo "Largest Profile Size set to: " $LargestProfileSize4Host
					}
				}

We follow this block by looping through the vGPU profiles of the given host ($_) using the ExtensionData.Config.SharedPassthruGpuTypes again. This second loop through the vGPU profiles is what adds them to the collection. It starts by getting the card type and profiles and assigning them to the CurrCard and the CurrProfile variables using split. We then take care of the 2b4 and 1b4 profiles again for this loop. Then, we finish this block by retrieving the profile number (the 8 in 8q) and assigning it to the ProfileNum variable.

 				$_.ExtensionData.Config.SharedPassthruGpuTypes | ForEach-object { #itterate through the cards supported configs
					#echo "========================================================"
					#echo "vGPU Profile: " $_ #(ex: grid_p4-8q)
					
					$TempCard = ($_ -split "_")[1] #remove the grid-card entry from the profile name 
					$CurrCard = ( $TempCard -split "-")[0] #get the card type of the profile string (ex: p4)
					
					$CurrProfile = ($_ -split "-")[1] #Get just the profile  (ex: 8q)
					#echo $CurrCard " : " $CurrProfile
					
					#Safety Check for 2b4 and 1b4 profiles which should be removed eventually
					if ($CurrProfile -eq "2b4") {
						$CurrProfile = "2b"
					}
					if ($CurrProfile -eq "1b4") {
						$CurrProfile = "1b"
					}
					#echo "==============="
					#echo $CurrProfile
					$ProfileNum = $CurrProfile -replace "[^0-9]" , '' #get just the profile number
					#echo $ProfileNum

Now its necessary to deal with a couple of M series cards. Specifically the M60 and M10. These cards have multiple GPU chips on them which means they support 2 or more profiles each so we need to account for that by setting the GPUsOnBoard and setting the ProfileNum variable correctly for each card. In the near future this will also need to be done for the A16 GPU which also has 4 GPU chips.

					#########################################################################
					#Deal with M series cards even though not likely to use this
					#########################################################################
					$GPUsOnBoard = 1 #Everything but M series cards have a single GPU on the board
					if ($CurrCard.ToLower() -eq 'm60' -or $CurrCard.ToLower() -eq 'm6'){ #These two cards have 2 GPUs on the board
						$GPUsOnBoard = 2 #Set the number of GPUs on the board
						if ($ProfileNum -eq 0){ 
							$ProfileNum = 0.5 #Only these cards of 0 profiles which is technichnically 0.5 for math
						}
					}
					if ($CurrCard.ToLower() -eq 'm10'){ #This host has 4 GPUs on the board
						$GPUsOnBoard = 4 #Set the number of GPUs on the board
						if ($ProfileNum -eq 0){ 
							$ProfileNum = 0.5 #Only these cards of 0 profiles which is technichnically 0.5 for math
						}
					}

Now we start looking at profile sizes and how they relate to our vGPUs. It will take the ProfileNum that we got in previous lines of code, and compare it to the largest GPU profile size. This starts at 0 and keeps growing. We then take that largestProfileSize4Host and check to see if it’s greater than 0. (We dont want any division by zero issues.) We then divide the LargestProfileSize4Host by the ProfileNum to find out how may vGPUs per GPU chip are supported which is the vGPUperGPU variable. Lastly we multiply vGPUperGPU times the number of GPUsOnBoard to get the total number of profiles supported for the board.

					#########################################################################
					#Assumes that top most profile is the largest profile returned, so a P4-8q is largest
					#Assumes we are not mixxing card types in the same hosts
					#########################################################################
					#echo $ProfileNum
					
					if ($ProfileNum -gt $LargestProfileSize4Host) { #if the profile is larger than 0 set it as the max GPU size
						$LargestProfileSize4Host = $ProfileNum
					}
					
					#Saftey check to avoid division by 0
					if ($LargestProfileSize4Host -gt 0){
						$vGPUperGPU = $LargestProfileSize4Host / $ProfileNum #(ex: 1 vGPU per board)
						#echo "Max vGPU per GPU: "  $vGPUperGPU
					}
					
					$vGPUsPerBoard = $vGPUperGPU * $GPUsOnBoard #Set the number of vGPUs per board based on GPUs per board times number of vGPUs per GPU chip

Once we have all that information we can add the vGPU to the object list. All the previous code worked out our profile counts, GPUs per board, and much more. Amazing what you can get from a little list isn’t it. We have several commented out echos to validate our results. We then add the vGPU profile to the array. Exit our inner for loop. Exit our conditional statement insuring the GPU hasn’t been checked yet (the echo $vGPUlist line). Then exit the for loop for the hosts ($_). At this point we can return the vGPUlist to the calling program. At which point we conclude the try statement

					#echo '++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++'
					#echo 'Add entry to array'
					#echo $_
					#$obj = [pscustomobject]@{CardType="m10";vGPUname="grid_m10-8q";vGPUperGPU=1;vGPUperBoard=4; pGPUperBoard=4}; $vGPUlist.add($obj)|out-null
					$obj = [pscustomobject]@{CardType=$CurrCard;vGPUname=$_; vGPUperGPU=$vGPUperGPU; vGPUperBoard=$vGPUsPerBoard; pGPUperBoard=$GPUsOnBoard}; $vGPUlist.add($obj)|out-null
					#echo '++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++'
				}					
			}
			#echo $vGPUlist
			#echo "Just about to return"
			
		}
		#echo $vGPUlist
		#echo "this is what we want"
		return $vGPUlist
	}

The last part of this function is a catch statement. If anything went wrong that we didn’t test for and handle we through a catch statement. We use the write-host to make sure the error is seen as this should be presumed to be a fatal event. We also return a -1 for testing which is an invalid value. We also put an example of how to call it at the bottom.

Catch {
		write-Host "Error creating entries for vGPUs"
		#echo "failed to create entries for vGPUs"
		return -1 #return an invalid value so user can test
		Break #stop working
	}
	
}

#echo "pre call"
#Example: vGPUsInASystem "*" "connected"

vGPUsInASystem "*" "connected" #, maintenance"

That pretty well covers the way this module works. If you have questions let me know. If you want to improve the code please be sure to fire off a new branch of code.

May your servers keep running and your data center always be chilled.

Permanent link to this article: https://www.wondernerd.net/powershell-module-finding-vgpu-profiles/

Talk Nerdy to me & Updates at VMworld

It’s that time of year again. It’s VMworld time! Hopefully you’ve taken advantage of the fact that it’s free!!! Yup, it costs your nothing, zero, zip, zilch to attend. So, if you haven’t registered, get over to VMworld.com and get registered. If you don’t register I won’t talk nerdy to you!

This year VMworld is a virtual event again and that’s fine. I want everyone to be safe. Until our friends can join us that probably the best way to do a conference, and I want my friends from all over the world to be able to join in person. So if it’s another year of sitting at my desk in zooms till the wee hours of the morning, I’m ok with that and hopefully you’ll join us.

Aside from getting together with friends there are many things I really enjoy about VMworld. Of course there are the labs and all the new announcements. There is also just the sheer volume of knowledge that is being shared, and I know what you’re thinking… “You’ll go back and catch the videos later.” After all it all per-recorded content.

Let’s talk about both going back to watch later and content being per-recorded. We both know that you’re not going to find the time to go back and watch conference content later. I still have conference content from VMworld 2013 that I haven’t caught up on yet. You probably won’t go back and catch up on them either. So what I do, is block that time off in my calendar, set my IM status to do not disturb, and plan to avoid answering calls or emails. I explain to folks this is my (and their) opportunity to keep up to date and relevant in the field of virtualization.

Now let’s talk about per-recorded sessions. It’s true that some sessions are being per-recorded this year, like vBrownbag Tech Talks, others aren’t. I’ve only seen a few tech talks where there has been time for questions and where anyone has questions to ask. Most of the time you watch the session and then catch the presenter when they walk off stage. Having sessions live versus recorded is really minor to me. I plan on watching even if I know they are per-recorded. Won’t you join me?

In fact a few weeks ago I per-recorded session VMTN2835, it’s a vBrownbag session where I talk about new updates to my VDI by day compute by night script. (I’ll link to my update blog once VMworld is under way.) If you’re interested in working with vGPUs in PowerCLI it’s definitely something to catch.

There are several advancements that have been made that I talk about in the session. For example I talk about changes in 7.0 U2 and their impact to the scripts as well as how those have been addressed in these latest set of scripts. If your organization is even sort of interested in getting more use out of your VDI environment, you probably want to catch this session. Besides you already know where to find me afterwords to ask questions.

I’m guessing those updates aren’t the VMworld updates you were expecting… I wouldn’t want to spill the beans on anything cool in the works for VMworld. Regardless, there are going to be some really good updates coming out of VMworld.

Along those lines, something you may want to start brushing up on is AI/ML in virtual environments. Yeah you can run AI/ML workloads as VMs, it works, I’ve been evangelizing it since 2017… As a mater of fact NVIDIA had a big announcement about NVIDIA AI Enterprise platform for running AI in a virtual environment a few days ago. (BTW, just in case you missed it and in the interest of full disclosure, I work for Dell.)

If you’re really into running AI workloads in a virtual environment (and who isn’t?) Join me for my live VMworld {Code} session, CODE2778, where I’ll talk nerdy about using python to automate the creation of AI/ML VMs with vGPUs. We’re going to construct python code that will allow admins to create VMs with vGPUs. One of the things that is common with AI VMs is the need to have multiple vGPUs in a single VM. Not only will we delve into how to add multiple vGPUs, we’re going to talk about the other things you need to be aware of for multiple vGPUs to work. Sounds like a VMworld session you don’t want to miss.

That said, if you code, and I’m sure you do, you don’t want to miss VMware {code} at VMworld. Which is an entire program track geared towards programmers. Last years VMware {code} conference was stellar and from talking with the {code} team, this year is going to be just as good. If you want to see all of the {Code} sessions in the VMworld Content Catalog expand the “session type” option and then select “VMware {code} .

You maybe curious what are my picks for sessions to catch at VMworld. You probably guessed VMware {code} session and here are some of my other picks that I don’t want to miss.

Just in case you can’t guess, there’s a lot of stuff happening around AI at VMworld this year. My list is evidence of that. Searching the catalog there are, at the time of this writing, 23 sessions that have NVIDIA in their abstract or title. I think this is the most number of sessions I’ve seen around NVIDIA and GPUs.

Hopefully all of this is a pretty good reason to attend VMworld this year. It looks like there are going to be a lot of top quality sessions and a chance to learn a lot of new information. Hopefully you will see me in some of the social areas and are able to say hi. I look forward to seeing you there. Now go register if you haven’t!

May your servers keep running and your data center always be chilled.

Permanent link to this article: https://www.wondernerd.net/talk-nerdy-to-me-updates-at-vmworld/

Harnessing the Power of Python to Control vGPU Management in VMware vSphere – GTC 2021 Session E32023

In this blog I provide some insights on managing vGPUs in vSphere with Python. It sounds like a simple task to control vGPUs in vSphere, but its not as easy as it appears. I got deep into this as Johan and I were working on content for this session. I’ll cover all that and more in this post.

Just Here for the Slides

If you are here for the session slides, you’re in luck. Below you’ll find a copy of the slide deck. This is the same deck you’ll get through the GTC site. For the video of the session you’ll need to log in to the GTC web site. If you have questions about the session be sure to use the Contact Me page or leave a message in the comments.

https://www.wondernerd.net/wp-content/uploads/2021/04/E32023Tony-Foster-_-Johan-Van-AmersfoortHarnessing-the-Power-of-Python-to-Control-NVIDIA-vGPU-Management-in-VMware-vSphereFINAL.pdf

For those just getting started with vGPUs or wondering what they are. They are Virtual GPUs. What that means is VMware, in this case, is abstracting the physical GPU so that multiple VMs can use the physical hardware at the same time. That means you can have multiple VMs all running graphics applications or maybe even running an AI workload, because the GPU has been “sliced up.” You can also add up to 4 vGPUs to a single VM, making the VM a vGPU power house. It’s really fun stuff to work with in my opinion.

Pythoning it up

That gets to the Python side of things. We aren’t talking about how you can program vGPUs as part of a CUDA or PyTorch operation, for the most part that is done the same as if it were a physical host. I actually delved into this in a GTC 2018 session, S8483 – Empowering CUDA Developers with Virtual Desktops. Instead the real focus of this session is to look at how you manage the back end virtual hardware through a programmatic method. In other words it’s great to manually add a vGPU to a VM through the vCenter, but that isn’t all that helpful when you want to automate the process.

After all, most IT admins would rather write some code to do a common repeatable task than be that monkey trained to do the same thing over and over again. You can do all the stuff we talked about in this session through PowerShell and PowerCLI, and I’ve done several blogs on how to automate that, and that’s all well and good, unless you are looking for a different type of control, Python.

Python, is a modern programming language that’s widely used and can easily be ported from one OS to another. Plus compared to other languages it doesn’t have nearly as steep of a learning curve. There are also a lot of great plugins and modules for Python including PyVmomi. All of these are reasons why many programmers who are developing software around vSphere are using Python.

Earlier I mentioned that programming may not be as easy as it first appears. Here’s why, GPUs and vGPUs don’t have a lot of documentation about them as programming objects. If you do a google search for adding a vGPU to a VM with Python you’re not going to get a lot of results. (My Google search returned 0 meaningful results in the first two pages.) Why because people haven’t needed to do this all that much… until now.

AI/ML/DL/HPC run it virtually

Why is it needed now? Much of it has to do with the raise of AI/ML/DL/HPC on virtual platforms. (I discussed this in a 2018 VMworld Session, VAP2340BU – Driving Organizational Value by Virtualizing AI/ML/DL and HPC Workloads.) And some of it with VDI. Up until late 2020 many thought it was absurd to put these “special workloads” on a virtual environment, because “they require bare metal performance.” Only a handful of folks understood what power virtualizing them held for the enterprise. No longer is AI the stuff of science experiments, at has a real business value and needs to be treated like any other business IT stack. And what do businesses do with IT stacks? They automate.

So how do we crack open the vault and start programmatically controlling our vGPU infrastructure. Where I started was with the VMware vHPC toolkit on GitHub. It has a lot of good samples and examples. The best thing to do is to do a ctrl+f and search for “GPU.” The content is fantastic. But the code in there is really chunked up so you have to bounce all over to figure out which objects you are working with. This is great once you understand the infrastructure and what you’re trying to code against, not so much when you are learning it.

The Secret Decoder Ring

That’s where the vSphere MOB comes into play. Don’t worry there’s no offer to refuse. MOB stands for Managed Object Browser. You can get to it by appending /mob to the end of your vSphere URL. The MOB allows you to browse all the objects managed by vSphere. So not just GPUs. The problem is finding them. For the GTC session we put together a little MOB Cheat Sheet slide to help you figure out where things are in your environment and the type of objects they are. This will help you as you code figure out what object you need to access and when.

In the session we talk about two different ways of calling objects. You can navigate to them directly or access them through the use of a container view. Calling them with a container view looks like this:

TempVMlist = HostContent.viewManager.CreateContainerView(HostContent.rootFolder,[vim.VirtualMachine], True)

The container view takes a content type of vim.VirtualMachine in this case, the MOB provides these object types so you can easily specify what sort of object you are looking for. You can navigate to object directly as well.

DataCenterContent = HostContent.rootFolder.childEntity[0] #Assume single DC       
VMs = DataCenterContent.vmFolder.childEntity

These two lines of code navigate directly to the VMs in a vSphere environment instead of creating a container view. This path can be found using the MOB as well. Having a context of both of these helps to make it easier to understand what you are doing.

The main areas for objects are:

  • managed_object_ref.config.sharedPassthruGpuTypes #Shared Passthrough GPUs
  • ChildVM.config.hardware.device #VM child hardware device listing
  • isinstance(VMVirtDevice, vim.VirtualPCIPassthrough) #Has a virtual PCI passthrough device
  • hasattr(VMVirtDevice.backing, “vgpu”) #Has a backing attribute of vgpu
  • VMVirtDevice.backing.vgpu #Device Backing
  • VMVirtDevice.deviceInfo.label #Device label eg. grid_p4-8q
  • VMVirtDevice.deviceInfo.summary #Device summary

All of the code we discussed in the session is available on GitHub so you can try it out for yourself. It’s important to note there is very little error checking in these scripts, and that is intentional because we don’t know how you intend to use them. So if you intend to use them in production be sure to add the appropriate error handling.

In the repository we provided details on how you can find what host have GPUs, which VMs have vGPUs, how to add a vGPU, to a VM and remove it. You probably want to know, as I did, how do you get to the stats and all the details you get with the nvidia-smi command.

Digging Deeper With NVML

That’s something I was hoping to share in the session. NVIDIA provides a tool called the NVIDIA Management Library or NVML which can provide an insane amount of information about your GPUs and vGPUs. The only problem is VMware doesn’t allow this to be exposed through the vSphere API. That means the only way to get to the information provided by the NVML is through a terminal session (SSH).

It took several emails back and forth to make sure I wasn’t missing anything and that the only way to get the NVML goodness was through SSH. And I can confirm as of this writing that this is the case. And unfortunately that programming is a bit beyond the scope of both the GTC session and this blog.

Hopefully this has helped unlock the secrets needed to programmatically mange you vGPUs with Python.

May your servers keep running and your data center always be chilled.

Permanent link to this article: https://www.wondernerd.net/harnessing-the-power-of-python-to-control-vgpu-management-in-vmware-vsphere-gtc-2021-session-e32023/

Sneak Peak at the Brand New Jetson Nano 2GB

How would you like a sneak peak at the brand new NVIDIA Jetson Nano 2GB Developer Kit? I have the hook up for you. NVIDIA sent one out to me as part of their NGCA social media program prior to today’s (October 5th) launch.

Let’s get right to the details…

We’ll start with the price… you can order a Nano 2GB Developer Kit for $59. This is designed for developers, STEM opportunities, and IOT applications. All of these are price sensitive areas that also need GPU power for AI based opportunities.

So what do you get for $59? You get a lot. This has many of the same features that its big brother the Jetson Nano has.

There are 4 big differences between the the Nano and the Nano 2GB. They are:

  • The Nano 2GB ships with 2GB of RAM, hence the name
  • It comes with a wireless adapter! (More on this later)
  • There are fewer ports on the Nano 2GB
  • It has a USB-C connector to provide a larger power draw

There are also so minor changes, we’ll dig into both the major enhancements and some of the minor changes with the Jetson Nanon 2GB.

Let’s start with the memory in the Nano 2GB. This isn’t as much as it’s older brother. In my opinion this is actually is better, especially for STEM and IOT applications. It’s the ideal size for getting started with AI where you don’t have large data sets and are probably using a pre-trained model. All of this really reduces the need for the extra memory and keeps the price reasonable.

Speaking of reasonable… The Nano 2GB comes with a wireless adapter, which is awesome. For those who do development or are doing STEM really need wireless capabilities. In some IOT instances wireless is also a requirement. In my mind this is a god send.

Now it should be noted that in some regions the Nano 2GB won’t come with a wireless adapter. For those regions the price is reduced to reflect the difference of the wireless adapter. Talking with the program team they are working on an adapter that will work for these other regions that don’t currently have one.

The Nano 2GB Developer Kit, does not have a display port. And for this I am thrilled!!! I no longer need to worry about youth who are using them for STEM projects trying to force HDMI cables into the display port. This is one of my favorite physical enhancements to the Nano 2GB.

Additionally there is only a single USB3 port on the Nano 2GB. This makes good sense to me. With my development and STEM work (and I assume for others) I very rarely connect a single device that needs USB3 speeds, much less 3 or 4. Wifi, keyboard, mouse, and maybe external storage are my typical USB connections.

The last exciting physical aspect that stands out for me is, with the Nano 2GB you don’t need a special barrel style power supply when you need full power. The Nano 2GB uses a USB-C connector for power. For me this is an ideal enhancement to the Developer Kit.

With a USB-C connector it makes it so much easier to find power to run the Jetson Nano 2GB, especially when working with youth on STEM projects. Think about it… if you have an Android cell phone, what is the power connector? If your phone is newer than 2 years old its probably a USB-C charger… That means you’ve got a power supply for the Nano 2GB.

There are also some other physical attributes that are worth mentioning with the Nano 2GB. According to the documentation, in some regions there are not a set of pins for a cooling fan. The Nano 2GB I received did not have pins for a fan. I don’t expect I will get the Nano 2GB that warm and I probably will not put it in a case.

NVIDIA has also moved the control pins, like power, reset, etc. to under the processor on the developer kit board. They are in a single row which. You can see this in the photo along with what each pin is for.

The GPIO pins are identical to the Jetson Nano. You can see the pin out in the photo.

You can find details on the Jetson Nano 2GB on the Nano 2GB product page.

It’s time to wrap up this post. Today NVIDIA announced the Jetson Nano 2GB Developer Kit. This is awesome for developers, STEM learners, and IOT applications. It has amazing power in a small package with an equally small price tag. It only costs $59, and can be pre-ordered today from the NVIDIA store.

May your servers keep running and your data center always be chilled.

Permanent link to this article: https://www.wondernerd.net/sneak-peak-at-the-brand-new-jetson-nano-2gb/

Trove of VMware Project Monterey Resources

You may have heard that on Tuesday at VMworld 2020, VMware announced a partnership with NVIDIA called project Monterey. One of the central parts of this is using a SmartNIC’s (NVIDIA Mellanox BlueField-2 DPU) for services and boot images. This post details a lot of the materials that were released as part of the VMworld announcement as well as some other blogs from VMware on it.

Here is a great picture from Kit Colbert’s blog post providing an overview of the components of a SmartNIC which is a central core to Monterey.

https://blogs.vmware.com/vsphere/files/2020/09/Project-Monterey-What-is-a-smartNIC.png
https://blogs.vmware.com/vsphere/2020/09/announcing-project-monterey-redefining-hybrid-cloud-architecture.html

Most VMworld content can be found at VMworld.com and is on demand. Some content though was live and so may not be available yet from the site.

Monterey was first introduced as part of the VMworld general session, you can watch it on demand as session GEN2859. You can start to get an idea of what project Monterey is all about.

To dig deeper into the announcement be sure to watch session VI3178 with Pat Gelsinger (VMware) and Jensen Huang (NVIDIA). This gives a good overview of it for those not deep into the technology.

Now lets cover the press releases on project Monterey:

The partnership press release: https://www.vmware.com/company/news/releases/vmw-newsfeed.VMware-and-NVIDIA-to-Enable-Next-Gen-Hybrid-Cloud-Architecture-and-Bring-AI-to-Every-Enterprise.801b9b92-97a9-4a75-9074-116733900cb5.html

Project Monterey press release: https://www.vmware.com/company/news/releases/vmw-newsfeed.VMware-Unveils-Project-Monterey-Re-Imagining-Hybrid-Cloud-Architecture-to-Support-Next-Generation-Applications.89238c82-cabf-4136-b66e-642617f10d40.html

NVIDIA’s partnership announcement: https://blogs.nvidia.com/blog/2020/09/29/vmware-gelsinger-nvidia-huang/?ncid=so-twit-95535#cid=_so-twit_en-us

There are several good blogs that relate to project Monterey that should be part of your review:

NVIDIA Blog on what is a DPU: https://blogs.nvidia.com/blog/2020/05/20/whats-a-dpu-data-processing-unit/ <– READ THIS IT’S IMPORTANT The DPU is a at the heart of project Monterey, it’s important to understand what a DPU and SmartNIC is.

Kit Colbert’s blog post announcing project Monterey: https://blogs.vmware.com/vsphere/2020/09/announcing-project-monterey-redefining-hybrid-cloud-architecture.html

               Note that the breakout session (HCI3351) mentioned in Kit’s blog is not yet available in the content catalog. The same is true for the round tables HCP3047S and OCTO3150S. These 3 sessions are really good at getting deeper into the technology of Monterey.

               OCTO3150S is a really good session outlining much of the content around project Monterey with Kit Colbert (VMware), Paul Perez (Dell), and Chris Lamb (NVIDIA). When it’s posted, it’s well worth the time to watch and really helps demystify Monterey.

Thursday, Kit was the day 1 keynote speaker at VMware’s Code Connect conference. He dug deeper into project Monterey today providing more technical detail than the sessions listed above or his blog. It’s worth the watch if you’re interested in how Monterey helps automate the data center at the hardware level. http://vmwarecodeconnect.github.io/CodeConnect2020/

Here are some screen grabs from Kit’s Code Connect keynote that I had tweeted out during the keynote:

Image
Image

That gets us to the current state of content. Next week, October 5, is the fall GPU Tech Conference (GTC). In my personal opinion the keynote is definitely worth watching, if you have a chance be sure to watch it live.

Update Oct 5: One of the things that is free to take in from GTC is the keynote, specifically part 5 of the GTC keynote where BlueField-2 DPU is discussed.

As part of GTC there are a whole lot of great sessions worth watching that may relate to Monterey, provided you have a GTC pass ($100).

The GTC sessions on DPUs I recommend catching are:

  • The Next Generation of Fully-Integrated Data Centers [A21223]
  • How to Secure Modern Data Centers [A21238] <– Important
  • Securing and Accelerating the Enterprise Data Center with Data Processing Units (DPUs) [A21193]
  • (On demand) DPUs, K8s, and ML: the Future of Compute (Presented by Canoical) [A22573]
  • Dinner with Strangers – NVIDIA Spectrum Ethernet Switch based Interconnects for AI clusters and VMware Based Virtualized Infrastructure [DWS0CT74]

All that said realize that Monterey is a larger program than just SmartNICs/DPUs (NVIDIA BlueField-2 DPUs to be exact). So I expect we will probably see much more announced as Monterey progresses.

I hope this helps expand your knowledge of VMware’s project Monterey.

May your servers keep running and your data center always be chilled.

Permanent link to this article: https://www.wondernerd.net/trove-of-vmware-project-monterey-resources/