[API’s] Getting session counts (incl performance comparison)

One of my customers asked the question if it is possible to get a quick sessioncount for a script that they can run very often for a correct logging of license usage. While this could easily be done by grabbing all the sessions I thought this could be a slow process. I remembered though that the first release of the vmware.hv.helper module had a function called get-podsessions that only returned a sessioncount. I decided to see what was used for this. By going back in time at github I found that the GlobalSessionQueryService was still used but with the GlobalSessionQueryService_GetCountWithSpec method. It needs the service and a spec of the type VMware.Hv.GlobalSessionQueryServiceCountSpec.

the spec itself can hold one of the many options to get a count for

As you can see there is a globalentitlement property that needs to be set using the id so let’s grab that one first.

$queryService = New-Object VMware.Hv.QueryServiceService
$defn = New-Object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'GlobalEntitlementSummaryView'
$globalentitlements = ($queryService.QueryService_Create($Services1, $defn)).results

I will use the first globalentitlement to grab the sessioncount

$globalentitlement=$globalentitlements | select -first 1
$globalsessionqueryservice_helper = New-Object VMware.Hv.GlobalSessionQueryServiceService  
$count_spec = New-Object VMware.Hv.GlobalSessionQueryServiceCountSpec  
$count_spec.globalentitlement=$globalentitlement.id
$sessioncountperglobalentitlements=$globalsessionqueryservice_helper.GlobalSessionQueryService_GetCountWithSpec($services1,$count_spec)

As you can see we actually get a count per pod so to get all the counts from all pods from all globalentitlements I have created a script with a couple foreach’s.

$hvserver1=connect-hvserver SERVERNAME
$services1=$hvserver1.extensiondata
$queryService = New-Object VMware.Hv.QueryServiceService
$defn = New-Object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'GlobalEntitlementSummaryView'
$globalentitlements = ($queryService.QueryService_Create($Services1, $defn)).results
$queryservice.QueryService_DeleteAll($services1)
$sessioncount=@()


foreach ($globalentitlement in $globalentitlements){
  $globalsessionqueryservice_helper = New-Object VMware.Hv.GlobalSessionQueryServiceService  
  $count_spec = New-Object VMware.Hv.GlobalSessionQueryServiceCountSpec  
  $count_spec.globalentitlement=$globalentitlement.id
  $sessioncountperglobalentitlements=$globalsessionqueryservice_helper.GlobalSessionQueryService_GetCountWithSpec($services1,$count_spec)
  foreach ($sessioncountperglobalentitlement in $sessioncountperglobalentitlements){
    $pod=$services1.pod.pod_get($sessioncountperglobalentitlement.id)
    $sessioncount+= New-Object PSObject -Property @{
      "Global_Entitlement_Name" = $globalentitlement.base.displayname;
      "Pod_Name"=$pod.displayname
      "Pod_Sessioncount" = ($sessioncountperglobalentitlement | select-object -expandproperty count);
      "Site_Name"= ($services1.site.site_get($pod.site)).base.Displayname;
    }
  }
}
 return $sessioncount | select-object Global_Entitlement_Name,Pod_Name,Site_Name,Pod_Sessioncount

The W10_MGMT global entitlement only has a pool in pod1 so even though the pod doesn’t have a pool inside the global entitlement it will still return a sessioncount.

Performance

I also decided to time it but in my small environment it took 3 seconds and 3 of those where for connecting to the connection server. If I removed the connecting part it was 0.7 seconds.

Measure-Command {D:\scripts\dev\session_count.ps1}

Back at the customer I decided to compare this against dumping all global sessions, this will give some better data since it has a couple more sessions in it (around 3500 at the moment of testing)

The script I used for getting all global sessions is the code that I used for the get-hvglobalsession in the vmware.hv.helper module

$query_service_helper = New-Object VMware.Hv.GlobalSessionQueryServiceService
$query=new-object vmware.hv.GlobalSessionQueryServiceQuerySpec

$SessionList = @()
foreach ($pod in $services1.Pod.Pod_List()) {
  $query.pod=$pod.id
  $queryResults = $query_service_helper.GlobalSessionQueryService_QueryWithSpec($services1, $query)
  $GetNext = $false
  do {
    if ($GetNext) { $queryResults = $query_service_helper.GlobalSessionQueryService_GetNext($services1, $queryResults.id) }
    $SessionList += $queryResults.results
    $GetNext = $true
  } while ($queryResults.remainingCount -gt 0)
    $query_service_helper.GlobalSessionQueryService_Delete($services1, $queryresults.id)

}
return $sessionlist

Screenshots from the timing:

so the getcountwithspec method is about 2.5 seconds faster but the data in the globalsession is way more extensive and usable for all kinds of management overviews.

The VMware Labs flings monthly for December 2018

Happy New Year everyone! Hope you all had a great (and safe!) end of the year. I just need to close the year up with one thing: an overview of flings that have been released or updated in December. No less than four new flings have arrived: VMware Workspace ONE Provisioning ToolDispatch-SoloAndroid Device Pre-Verification Suite and PowerCLI for VMware Cloud on AWS. Two flings have received an update: PowerCLI Extensions and the HCIBench.

New

[sta_anchor id=”wsoneprovtool” /]

VMware Workspace ONE Provisioning Tool

The VMware Workspace ONE Provisioning Tool gives you an gui to provision and test WS One Applications.

The VMware Workspace ONE Provisioning Tool helps you test and validate your applications (exported as a .ppkg file) and the special-purpose unattend.xml configuration file as part of the Dell Provisioning for Workspace ONE offer. This tool simplifies the testing and validation of this process in your own environment before these files are sent and applied in the Dell factory.

Highlights

  • Simple UI to easily enable the IT admin to validate their ppkg and unattend.xml files in their own environment, mimicking what Dell is doing in the factory.
  • Supports PPKGs and unattend.xmls generated with Workspace ONE UEM Console 1811 or newer.
  • Highly flexible. Allows IT admins to specify the configurations for tool in a text based config file in order to change things like tool timeout and report location, to name a few.
  • Generates a detailed final summary report with client details and app installation results. This file is saved in C:\ProgramData\Airwatch\UnifiedAgent\Logs\PPKGFinalSummary.log after the “Full Process” button is clicked.
  • Halts the process if any steps fails for the given operation, giving the ability to IT admins to view & debug the state of the machine and the apps.

Supported Operations

  • Apply Apps Only – Given a ppkg, this tool deploys the applications on a test windows machine
  • Apply Full process – Given a ppkg and xml file, this tool deploys the applications on a test windows machine followed by Workspace ONE enrollment and Sysprep.

[sta_anchor id=”dispatchsolo” /]

Dispatch-Solo

The Dispatch-Solo fling actually is a prepackaged VM to get you started with dispatch as easily as possible.

Dispatch-Solo is lean version of Dispatch which has been packaged as VM appliance. The goals of Dispatch-Solo are simple:

  • Lower the barrier to entry – get started with Dispatch in a matter of minutes
  • Support nearly the full Dispatch feature set – API compatibility
  • Explore use-cases – get user feedback and iterate

Because Dispatch and serverless is still in its infancy, understanding use cases is the highest priority. It therefore makes sense to continue to focus on getting Dispatch in as many hands as possible and making it as easy as possible to get started exploring its usage. By packaging Dispatch-Solo as a VM appliance, getting started is quick and predictable.

For full documentation and examples see the Dispatch project page.

[sta_anchor id=”androidpreversuite” /]

Android Device Pre-Verification Suite

This Android Device Pre-Verification Suite Fling reduces the time to perform a preliminary test on any Android device from any OEM. Pre-verification result decides whether the device is eligible for a full device verification program or not. This eliminates the TAT (turnaround time) for basic test failures during the initial phase of verification from VMware. Customers/Partners can run this tool at their premise and check whether the device passes the device verification program entry criteria.

[sta_anchor id=”powerclivmc” /]

PowerCLI for VMware Cloud on AWS

If you are using VMware Cloud on AWS the PowerCLI for VMware Cloud on AWS fling will give you an preview on what to expect from PowerCLI to automate VMC.

This Fling provides a community preview of the upcoming PowerCLI commands for managing VMware Cloud on AWS. It comes in the form of a single PowerCLI module and integrates with existing PowerCLI modules.

All commands have been automatically generated. They are still in development, contain known issues, and will change in the future.

Updated

[sta_anchor id=”powercliextensions” /]

PowerCLI Extensions

The PowerCLI extensions fling gives you a preview on what to expect in the official PowerCLI releases.

Changelog

Version 3.0.0.11173018

  • Updated PowerCLI.Extensions Module to be compatible with VMware PowerCLI 11.0.0

[sta_anchor id=”hcibench” /]

HCIBench

This one should be known by now, the HCIBench is made for benchmarking your hyperconverged infrastucture. Ideal for things like vSAN but please be aware that it could also possibly be tuned for that.

Changelog

Version 1.6.8.7

  • Enhanced easy-run, put original 4k,70% read as the first test case, then 4k, 100% read and 256k, 100% write
  • Enhanced tvm deployment validation
  • Added Checksum into easy-run consideration
  • Updated guest VM template with increased ring_pages and disk scheduler
  • Added DNS configuration guidance into welcome message

Version 1.6.8.5

  • Added 2 more test cases into easy-run, 4k 100% random read and 256k 100% sequential write
  • Batch deployment will be involved if deploying more than 8 VMs to speed up deployment process
  • Allow user to choose IP prefix when using static IP
  • Optimized UI to allow user to review the results by single click
  • Fixed regression issue when placing Datacenter/Cluster in the folder

 

[Update 15-10] VMware PowerCLI 11.0.0 release with new Horizon (7.6!) API calls

UPDATE 12-10: The new API explorer page also has been published, it just needs to be added to the main page. Check this link: https://code.vmware.com/apis/445

Update 15-10: I have received an overview from VMware about the other changes:

New API Endpoints:
ConnectionServer_GetTags
GlobalSettings_GetEnvironmentSettings
QueryService_DeleteByIds
Datastore_GetDatastoreRequirements
Datastore_ListDatastoresByDesktopOrFarm
RemoteApplication_EndApplication

There also have been some changes to some objects (MachineBase,AccessGroup etc) to include more properties

Original Article:

Today the latest version of PowerCLI was released with version 11.0.0. When you look at the release notes it’s obvious that some extra things have been added for the Horizon VIew API’s.

PowerCLI has been moving at quite the rapid pace over the last 2 years. In 2018, we’ve been releasing roughly every other month to make sure we get the latest features, performance improvements, and updates available as quickly as possible. Well, it’s been two months and we’re not going to break this trend. Today, we are releasing PowerCLI 11.0.0!

PowerCLI 11.0.0 comes with the following updates:

  • Added a new Security module
  • Added new cmdlets for Host Profiles
  • Added a new cmdlet to interact with NSX-T in VMware Cloud on AWS
  • Support for vSphere 6.7 Update 1
  • Support for NSX-T 2.3
  • Support for Horizon View 7.6
  • Support for vCloud Director 9.5
  • Multiplatform support for the Cloud module
  • Updated the Get-ErrorReport cmdlet
  • Removed the PCloud module
  • Removed the HA module

Even though Jake Robinson already gave me a heads up that this version was coming it’s always the question what has been added for Horizon View. According to the API explorer page no new querydefinitions have been added. Like last time I decided to compare the services against the old list and there are two new additions:

  • CategoryFolder
  • ResourceSettings

I have tried both against a Horizon 7.5 setup and they failed so these are only exposed from Horizon View 7.6 and up.

The first one called Categoryfolder is linked to the possibility to put rdsh applications into folders.

It currently has only one function:

I have also investigated if there was a way to change things using the helper function but sadly it has no .update api call so that’s a no-go. I currently have no rdsh on my lab so I can do the list but it doesn’t show anything.

The other new service is the .ResourceSettings just like categoryfolder it also only has one function:

For this one I can actually show what it’s used for:

It shows the general settings for forced logoffs.

Sadly this service also doesn’t show a way to change things.

Sadly I have no found no way yet to see what queryservice entity’s have been added so hopefully we will have a new API explorer soon (maybe with release notes this time, pretty please VMware?) that shows us all the new goods.

New View API query services in PowerCLI 10.1.1: pulling event information without the sql password.

A while back I already posted about new services that where available for the View API’s in PowerCLI 10.1.1. Recently the api explorer for this version was published and can be found here. Two things that I didn’t find back then was the addition of two services for the query service. The first is GlobalApplicationEntitlementInfo this one can be compared to the previously already available GlobalEntitlementSummaryView and will return information about global entitlements.

The second added services is extremely useful: you can now query the event database. This means you don’t need the actual sql password anymore to query the events. According to the api explorer at least Horizon 7.3 is required and only events from the Event and Event_Data database tables. A simple query will show all events.

$queryservice=new-object VMware.Hv.QueryServiceservice
$defn=new-object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'EventSummaryView'
$results=($queryservice.QueryService_Query($services1,$defn)).results
$results

As you can see the data is divided in data and namesdata properties, these contain the same data as what is returned with get-hvevent. I added some selections to show only one event.

$results | where {$_.data.eventtype -like "*BROKER_USERLOGGEDIN*"}  | select -last 1 | select -expandproperty data

and

$results | where {$_.data.eventtype -like "*BROKER_USERLOGGEDIN*"}  | select -last 1 | select -expandproperty namesdata

Offcourse it;s better to use filtering from the query directly. The full lust for that is available from the api explorer but I will give a couple of examples. (be aware that membername and the value are case sensitive)

$queryservice=new-object VMware.Hv.QueryServiceservice
$defn=new-object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'EventSummaryView'
$equalsFilter = New-Object VMware.Hv.QueryFilterEquals
$equalsFilter.membername='data.eventType'
$equalsFilter.value="BROKER_USERLOGGEDIN"
$defn.filter=$equalsFilter
($queryservice.QueryService_Query($services1,$defn)).results.data | select -last 1

Or by severity

$queryservice=new-object VMware.Hv.QueryServiceservice
$defn=new-object VMware.Hv.QueryDefinition
$defn.queryEntityType = 'EventSummaryView'
$equalsFilter = New-Object VMware.Hv.QueryFilterEquals
$equalsFilter.membername='data.severity'
$equalsFilter.value="WARNING"
$defn.filter=$equalsFilter
($queryservice.QueryService_Query($services1,$defn)).results.data | select -last 1

As said it can be filtered on other properties as well but that might require some more logic to get the userid or desktopid for example. This is a very useful addition in my opinion to the Horizon View api’s.

My presentation at the vEUCtechcon 2018

Yesterday it was clear for me that more people are interested in what Dutch secret agents have to do with airwatch/workspace one uem then with PowerCLi for Horizon View. Nonetheless there where some people listening to my presentation and watching the ginormous slide deck filled with gif’s that I created. My personal experience was that it went ok but nothing more than that. Sadly using the vga cable didn’t help against the connection bugs all presenters where having during the entire day. Also I would have preferred to have a monitor in front of me so I could actually hear myself talking in that big room. Personal points for next time: I had a good storyline in my head in advance, that didn’t come out at all. Also I need to channel my personal energy onto stage, I have the feeling that wasn’t really visible. Aka I need to do some more energetic storytelling.

For the people interesting in the presentation it can be found HERE. There’s a video recorded that I will add to this post when it gets published. Luckily there where also a couple of tweets about my sessions so we do already have some pictures.

https://twitter.com/HuibDijkstra/status/1012317207261601792

New Horizon API calls in PowerCLI 10.1.1

VMware quietly released a new version of PowerCLI last week: 10.1.1. This release is mainly an update for the Horizon View API’s. This to bring it back on level with the current Horizon release at 7.5. The release notes are not very extensive but it has a fix for some people getting time-outs when connecting to a Connection server  plus a bunch of new api calls.

I have dumped the output from the available api calls into two text files and made a comparison:

Since there’s no update yet in the API explorer I will have to make an educated guess on what the functions do:

DesktopTask

When looking at the available method’s for this call it looks like it has everything to do with Desktop task. But it also can’t do a damn thing without an vmware.hv.desktoptaskid. This will most probably bu retrievable using a query. This is something I will further investigate in the future.

DiagOperation

To be honest I have no idea yet what this one does. I have tried created a VMware.Hv.DiagOperationRequest and tried to send it but got an error that no message queue handler was found. This might be something from Horizon 7.5 since I haven’t updated my lab yet.

GatewayAccessUserOrGroup

This one is easy, it creates, deletes, gets and lists remote access users. You can expect a function for this in the near future since it looks easy to build.

JwtToken

According to my sources this is a SSO token between the flex and html5 clients.

LogonTiming

This obviously is created to pull logon timing as the name suggests. I have put a session ID in a variable but sadly the data is not usable from PowerCLI. WHat it seems to be is the api call the Helpdesk client uses to pull the logon time. I didn’t have the timing profiler turned on initially and neither the helpdesk tool or this call gave my any information. Disconnected sessions also don’t give any information and when reconnected it gives the reconnection time not the initial logontime for when the session started. This is the same behaviour as the helpdesk tool.

Apparently the output is in a json format and for now I doubt if it will be usable in a function.

While the session itself has this information.

NetworkProxyConfiguration

No idea yet why there is a networkproxy configuration in here.

Performance

This gets some performance data using a session id as also visible in the helpdesk tool.

RemoteApplication

Gives per session information on the Skype 4 Business pairing mode.

RemoteAssistantTicket

100% sure related to the remote assistance function in the helpdesk tool.

RemoteProcess

Looks like this one gets some information from a query and then kills the process, will have to dig into it some further later on. This for sure is a function in the helpdesk tool.

ViewClient

Again from the helpdesktool, this gives the client version of a session.

Conclusion

For now I only see the DesktopTask and GatewayAccessUserOrGroup ending up in a function in the vmware.hv.helper. The first one will need some digging on how it exactly works but it has the looks of a usable call. The latter on can be in there pretty fast if I find the time to do so. The other ones

 

Update

Already received some extra information about some calls.

Registering an Instantclone administrator using PowerCLI

Another question Sean Massey asked me if it is possible to register an instant clone domain administrator. This is possible using the instantcloneenginedomainadministrator service with the InstantCloneEngineDomainAdministrator_create method. This needs a spec with the following content:

  • spec (vmware.hv.InstantCloneEngineDomainAdministratorSpec)
    • base (vmware.hv.InstantCloneEngineDomainAdministratorBase)
      • username (string)
      • domain (domainid)
      • password(vmware.hv.securestring)

The password can be created using the same scriptlet I used to register a new vCenter server. The domain ID can actually be gotten by listing all domains using

$services1.ADDomain.addomain_list()

For now I have created a scripts that requires you to give some details so it can register the instant clone domain administrator. It can also be found on Github but I will also definitively add it to the vmware.hv.helper module.

$icausername=read-host "What username to use for instantclone administrator?"
$icadomain=read-host "please give the dns name for the domain to user (i.e. domain.com)"
$icapassword=read-host "vCenter User password?" -assecurestring
$temppw = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($icaPassword)
$PlainicaPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($temppw)
$icadminPassword = New-Object VMware.Hv.SecureString
$enc = [system.Text.Encoding]::UTF8
$icadminPassword.Utf8String = $enc.GetBytes($PlainicaPassword)
$spec=new-object vmware.hv.InstantCloneEngineDomainAdministratorSpec
$spec.base=new-object vmware.hv.InstantCloneEngineDomainAdministratorBase
$spec.base.domain=(($services1.ADDomain.addomain_list() | where {$_.DnsName -eq $icadomain} | select-object -first 1).id)
$spec.base.username=$icausername
$spec.base.password=$icadminpassword
$services1.InstantCloneEngineDomainAdministrator.InstantCloneEngineDomainAdministrator_Create($spec)

Pulling horizon session information using PowerCLI

I should’ve already posted a blog about this but better late then never. At the end of february I posted about several new functions being added to the vmware.hv.helper and two out of three where about pulling session information. Recently I received some questions about using those since it’s the raw data being returned. For my Dutch vmug presentation I used several gif’s that showed what you can do with that data. I might need to update the cmdlets so all information will be shown at once but that’s for another time since it might slow down the cmdlet a lot and I don’t like that.

Usage

Since get-hvglobalsession and get-hvlocalsession show almost similar data I will only show the latter one.

get-hvglocalsession

As you see this only shows the methods contained inside the session. We can show the content by pipelining it to  select-object -expandproperty but I prefer the bracket method since these might go several layers deep.

(get-hvlocalsession).namesdata

Some of the returned values are logical like the username, machineorrdsservername. The desktop name though is the actual desktop pool the user is connected to. Desktoptype can be Automated, Manual or RDS depending on the type of desktop and Desktopsource can be Virtual_Center (VM’s hosted on vCenter but not managed by Horizon or Full Clone desktops), View_Composer(when using Linked Clones), Instant_Clone_engine (when using Instant Clones), Unmanaged (physical machines, non-vCenter vm’s) or RDS (Terminal Servers). Farmname will be used when it’s an RDS session. The Securitygateway will show the Connection Server the user connected to or the UAG/Security server used.

the same can be done with referencedata and sessiondata

(get-hvlocalsession).referencedata
(get-hvlocalsession).sessiondata

Not a lot of directly usefull information but a bunch of id’s that you might be able to use with the api’s if needed.

A lot of information about the session itself.

The actual code

The get-hvglobalsession actually is a query repeated for all pods. First it connects to the query service and then creates a query to run against each pod and add that to a sessionlist.

$query_service_helper = New-Object VMware.Hv.GlobalSessionQueryServiceService
$query=new-object vmware.hv.GlobalSessionQueryServiceQuerySpec

$SessionList = @()
foreach ($pod in $services.Pod.Pod_List()) {
  $query.pod=$pod.id
  $queryResults = $query_service_helper.GlobalSessionQueryService_QueryWithSpec($services, $query)
  $GetNext = $false
  do {
    if ($GetNext) { $queryResults = $query_service_helper.GlobalSessionQueryService_GetNext($services, $queryResults.id) }
    $SessionList += $queryResults.results
    $GetNext = $true
  } while ($queryResults.remainingCount -gt 0)
    $query_service_helper.GlobalSessionQueryService_Delete($services, $queryresults.id)

}
return $sessionlist
} 

The get-hvlocalsession is almost the same, it just doesn’t need to foreach since it doesn’t have multiple pods to query.

 $query_service_helper = New-Object VMware.Hv.QueryServiceService
  $query = New-Object VMware.Hv.QueryDefinition

  $query.queryEntityType = 'SessionLocalSummaryView'
  $SessionList = @()
  $GetNext = $false
  $queryResults = $query_service_helper.QueryService_Create($services, $query)
  do {
    if ($GetNext) { $queryResults = $query_service_helper.QueryService_GetNext($services, $queryResults.id) }
    $SessionList += $queryResults.results
    $GetNext = $true
  } 
  while ($queryResults.remainingCount -gt 0)
    $query_service_helper.QueryService_Delete($services, $queryResults.id)
  

  return $sessionlist
  [System.gc]::collect()
} 

In both there is a do while because otherwise it will run into some restrictions about maximum amount of data to return.

Added functions in vmware.hv.helper

Last Saturday I created a pull request to add some new functionality to the VMware.hv.helper. Together with an older PR that was still open it received an okay on Sunday. This is a list of the functionality I have added:

  • Get-HVHealth
    • Shows the health information for the following services:
      • ADDomain
      • CertificateSSOConnector
      • ConnectionServer,EventDatabase
      • SAMLAuthenticator
      • SecurityServer
      • ViewComposer
      • VirtualCenter
      • Pod
  • new-hvpodfederation
    • Initiates the Cloud Pod Architecture.
  • remove-hvpodfederation
    • Uninitiates the Cloud Pod Architecture.
  • get-hvpodfederation
    • Shows information about the Cloud Pod Architecture.
  • register-hvpod
    • Registers a new pod in the Cloud Pod Architecture.
  • unregister-hvpod
    • Removes a pod from the Cloud Pod Architecture. This can either be gracefully or forced.
  • set-hvpodfederation
    • Sets the name of the Cloud Pod Architecture.
  • get-hvsite
    • Retrieves information about all sites in the Cloud Pod Architecture.
  • new-hvsite
    • Creates a new site in the Cloud Pod Architecture.
  • set-hvsite
    • Sets site properties within the Cloud Pod Architecture.
  • remove-hvsite
    • Removes a site from the Cloud Pod Architecture.

The next functionality on my list is to put the pod service methods from this previous post into functions.

Managing Pods in a Horizon View Cloud Pod Environment using PowerCLI & Api’s

After Pod Federations and Sites it is time to manage the actual pods. Let’s take a look at what we can do.

$services1.pod | gm

Looks like a short post to me since there’s onl Get, List and Update

[sta_anchor id=”get” unsan=”Get” /]

Pod_Get

Just like with site’s the get can be used in conjunction with a podid that might be gotten from somewhere else

$services1.pod.pod_get((($services1.site.site_list()).pods | select -first 1))

This selects the first podid listed when pulling all the pods from all sites and gets the information about that pod. We’ll see the same information when doing a list but just with all pod’s listed.

[sta_anchor id=”list” unsan=”List” /]

Pod_List

$services1.pod.pod_list()

Those endpoints are the connection servers in the pod. Let’s take a short detour and get the listing for one of those (the podendpoint service only has list and get so you will not see them separately anyway).

$services1.PodEndpoint.PodEndpoint_Get((($services1.pod.pod_list() | select -first 1).endpoints | select -first 1))

It might look lazy to use the select -first one and yes it is a bit but doing  a foreach to explain things also doesn’t really work in my opinion.

[sta_anchor id=”update” unsan=”Update” /]

Pod_Update

Standard by now, first we need to connect to the podservice.

$podservice=new-object vmware.hv.podservice
$podhelper=$podservice.read($services1, ($services1.pod.pod_list() | select -first 1).id)

Under $podhelper we can already see how to set things.

$podhelper | gm

Let’s update  the easy things.

$podhelper.setdescription("This is a new description")
$podhelper.setDisplayName("This is a new name")
$podservice.update($services1, $podhelper)
$services1.pod.pod_list()

As a result we have updated the name and description of the pod. The other thing we can do is assign the pod to another site. Thankfully I already have two of those created.

$services1.site.site_list()
$siteid=$services1.site.site_list() | select -first 1

$podhelper.setsite($siteid.id)
$podservice.update($services1, $podhelper)
($services1.pod.pod_list()).site
$services1.site.site_list()

Both the lists aren’t required but I added them to show that the pods are spread over both pods now.