The plug-in allows interaction between and Windows . The plug-in workflow library contains workflows that allow you to manage hosts and run custom operations.
You use the plug-in to call scripts and cmdlets from actions and workflows, and to work with the result. In addition to the standard workflows that come with the plug-in, you can also create custom workflows that implement the plug-in API.
You can use the view in the Client to manage the available resources. You can use the scripting API of the plug-in to develop custom workflows.
plug-in components
The plug-in relies on a number of components to function properly.
and Windows provide the platform for the plug-in, and the plug-in provides interaction between those products. The plug-in can also interact with other components, such as and vSphere PowerCLI.
The plug-in communicates with Windows through the WinRM communication protocol. See Configuring WinRM.
Optionally, you can integrate the plug-in with vSphere PowerCLI and . See PowerCLI Integration with the PowerShell Plug-In.
You can install all components on a local host. The usage, functionality, and communication protocol requirements of the plug-in do not change if and Windows are installed on the same machine.
Access the plug-in API
To access the API Explorer from the Client, click in the Client navigation pane.
To access the API Explorer from the tabs of the workflow, policy, and action editors, click on the left.
The plug-in exposes all objects in the connected hosts in the view.
Within the inventory of the plug-in, you can monitor hosts and their snap-ins and cmdlets. Each remote host can contain snap-ins and each snap-in can contain cmdlets.
Regular expression, commonly referred to as regex, is a powerful tool if you know how to use it. In terms of PowerShell regular expressions, you can find and alter text strings, identify text strings that match, and much more. For example, regex can help you read and analyze a log file — a process that’s horrifying to think about doing manually.
Let’s dive into how regex can help you be l̶a̶z̶i̶e̶r̶ more efficient in your role.
What is regular expression (regex)?
Regular expression is a series of characters that define a search pattern. You can use regex to identify matching text strings. It’s like a really fancy find-and-replace feature that helps you sift through large amounts of data (or text strings) at once. Regular expressions can consist of a single character or a complex combination of characters designed to return broad or very concise results. In other words, it’s built for you to fine tune to meet your needs.
Regular expression works with many text editors and scripting languages, including Notepad++, Visual Studio Code, SQL, Python, Perl, Java, PowerShell, and many more. While some systems include their own flavor of regex, others use standard regex libraries. PowerShell uses .NET regular expressions.
The information in this article focuses solely on the .NET regex engine. While there are many similarities between regex implementations, there can also be several differences between syntax, features, and behavior.
PowerShell regular expression reference sheet
If you’re new to regex and come across a complex regex statement, then you know what true confusion feels like.
Regex is a somewhat standardized shorthand language model that uses special characters, sometimes called metacharacters, to define pattern parameters. I say “somewhat” because different applications and languages use different regex models, which can vary slightly.
To the untrained eye, a regex statement may appear as though a cat walked across a keyboard. However, even those familiar with regex may struggle to read patterns, especially if they don’t work with regex consistently. That’s why it’s nice to keep a cheat sheet handy.
Matches any single character except newline. | |
Matches the beginning of a line. | |
Matches the end of a line. | |
Escapes a trailing special character. | |
Matches zero or more times, matching as many times as possible. | |
Matches 1 or more times, matching as many times as possible. | |
Repeat 0 or 1 time, as many times as possible. | |
Repeat 0 or 1 time, 0 if possible. | |
Repeat 0 or more times, as few as possible. | |
Repeat 1 or more times, as few as possible. | |
Matches a non-alphanumeric character. | |
Matches any non-number character. | |
Matches a whitespace character. | |
Matches any non-whitespace character. | |
Matches a newline. | |
Matches a tab. | |
Matches a carriage return. | |
Matches a word boundary between word and nonword characters. | |
Matches a location that is not a word boundary. | |
Matches must occur at the beginning of a string. | |
Matches must occur at the end of a string or before a newline. | |
Matches must occur at the end of a string. | |
Matches must occur at the point the previous match ended. | |
Matches any character in brackets. | |
Matches any character not in brackets. | |
Matches any character in the range of characters. | |
Matches exactly n times. | |
Matches at least n times. | |
Matches at least n times, up to m times. | |
Matches either a or b. | |
Specifies the pattern as a group. |
Using regex in PowerShell
If you’ve spent any significant amount of time with PowerShell, there’s a good chance you’ve already used regex. If you’ve matched or replaced a string, you’ve definitely used regex.
switch statements with the -regex option
Let’s look at a few basic examples of regex usage in PowerShell. Remember, if you’re wondering what a regex special character does, refer to the table above or any of the other resources linked below.
Matching patterns in PowerShell with regex
The -match operator identifies input that matches the provided regex pattern. It returns a Boolean value of true if a match is found and false if no match is found. Here is an example of how the -match operator works.
'Elden Ring is an amazing game!' -match 'amazing'
This command returns true because the pattern ‘amazing’ is found in the string ‘Elden Ring is an amazing game!’
Be careful not to confuse -match with -like. While -match uses regex, -like uses simplified wildcard pattern matching. If we replace -match with -like in the previous example, the command returns false.
The -like operator attempts to match the pattern ‘amazing’ exactly. It fails because the sentence contains much more than just ‘amazing.’ If we wanted the above command to work with the -like operator, we would need to add an asterisk before and after ‘amazing’ for the command to return true.
Here’s a slightly more complex example of utilizing the -match operator.
Replacing strings in PowerShell with regex
The -replace operator in PowerShell works much like the -match operator, except when a matching pattern is found, it calls for that pattern to be replaced with a substitute. Here’s the basic format of a -replace command:
<input> -replace <regex pattern>, <replacement>
Here’s a simple example of a -replace command that uses variables to store the input.
$halo = 'Halo infinite was great.'
$halo -replace 'was great', 'could have been better'
It’s important to note that the -replace operator doesn’t overwrite the value stored in the variable. You would need to recast the value of the variable to replace it.
Splitting strings in PowerShell with regex
The -split operator in PowerShell can split strings into substrings. By default, whitespace is used as the delimiter. However, the delimiter can be set to specific characters, strings, or patterns.
Here are some examples of the -split operator in use.
-split 'Red Dead Redemption'
'Red,Dead,Redemption' -split ','
'RedzDeadzRedemption' -split 'z'
'Red1Dead2Redemption' -split '\d'
The first example is formatted a bit differently but uses the default whitespace as the delimiter. The second and third examples use ‘,’ and ‘z’ characters as the designated delimiters. The last example uses the ‘\d’ regex special character, meaning any number character is treated as a delimiter.
Using Select-String in PowerShell
The Select-String cmdlet uses regex to match input from strings and files. If you have data that needs to be cleaned up and formatted, the Select-String cmdlet is the right tool for the job.
In this example, we piped the contents of the $text variable to the Select-String cmdlet. Using the -Pattern parameter, we set the regex pattern as ‘Mass\sEffect\s\d’ and set the pattern to be case sensitive with the -CaseSensitive parameter. We also included the -AllMatches parameter because only the first match in each line returns by default. The -AllMatches parameter returns all matches found. We’ve assigned the results of the command to the $games variable, then called the variable with the .Matches.Value property to return just the matched values. Notice that ‘mass effect 4’ was not returned because it did not match the case sensitivity requirement.
Here is what our original source file looks like.
Here is the resulting CSV file.
Using switch statements with the -Regex parameter
The switch statement in PowerShell uses exact matching by default, but we can employ the -Regex option to force it to use regex instead. Switch statements are great for evaluating multiple conditions.
Here’s what the syntax of a simple switch statement that uses the -Regex parameter looks like.
While this example is certainly effective, it doesn’t rely on complex regex patterns because it doesn’t have to. Your regex patterns need to meet only your requirements. In this example, the requirements were simple, and the patterns could match the information contained in the CSV file almost exactly.
Other regex resources
Regex is not for the faint of heart, but there are tons of great resources available when you need help. Here are some terrific resources that can help both regex beginners and pros.
Regex is powerful but complex
There is so much you can do with regex. You can parse files, scrape websites, validate input, and so much more. However, it’s complex. If you don’t regularly use it, you’ll soon forget much of what you learned. That’s why there’s no shame in frequently using the resources above.
If you’re looking for powerful tools that aren’t complex, check out PDQ Deploy & Inventory. This powerful combination can help you manage your endpoints and automate deployments with minimal effort. Try PDQ Deploy & Inventory for free for 14 days.
Born in the ’80s and raised by his NES, Brock quickly fell in love with everything tech. With over 15 years of IT experience, Brock now enjoys the life of luxury as a renowned tech blogger and receiver of many Dundie Awards. In his free time, Brock enjoys adventuring with his wife, kids, and dogs, while dreaming of retirement.
Comments and using statements are allowed to precede param() declarations, and since a shebang line is technically a comment, it works just fine; for example:
#!/usr/bin/env -S pwsh -noprofile
param( [string] $Foo
)
# Print all arguments that were passed
$PSBoundParametersIf you save the above to, say, sample.ps1, make it executable with chmod a+x sample.ps1, then invoke with ./sample.ps1 -Foo bar, you’ll see:
Key Value
--- -----
Foo BarThe use of
/usr/bin/envto launchpwshassumes that the latter is in one of the directories listed in thePATHenvironment variable.-noprofilesuppresses loading of PowerShell’s profile files, which – unfortunately – are loaded by default.To support passing this extra argument via the shebang line,
-Smust be passed toenv, for technical reasons (the system passes everything after the executable path as a single argument to that executable;-Smakesenvsplit that string into individual arguments).There is no technical need to use filename extension
.ps1in naming your script; in fact, if you want your script to simply function as a general purpose CLI that can be called from any shell, you may choose to use no filename extension, e.g. to simply name your scriptsample.Conversely, however, if you want to retain the ability to execute your script in-process from inside a PowerShell session, extension
.ps1is a must.A caveat is that calling shebang line-based scripts from outside PowerShell or – also from inside PowerShell – a shebang line-based script without extension
.ps1invariably has syntax and data-type limitations (the latter also invariably run in a child process), due to the fact that given a shebang line results in invocation via the-Fileparameter ofpwsh, the PowerShell (Core) CLI; notably:You can not pass array arguments (
foo, bar).
- The relatively high startup cost of the
pwshCLI. - The aforementioned syntax and data-type limitations.
- Various long-standing bugs that haven’t been addressed; see this GitHub query; note that you’ll have to click on the
Closedlink to also see still-relevant issues that have simply been closed due to inactivity.
- The relatively high startup cost of the
Guidance re if and when to use shebang line-based PowerShell scripts:
PowerShell runs
.ps1scripts in-process, which not only means faster execution, but also enables rich (non-serialized) data type-support based on .NET types.PowerShell permits invocation of
.ps1scripts even without their filename extension, so that you can call./sample.ps1as just./sample, for instance.
In either case:
The script needs to be designed with the syntax and data-type limitations of a
-File-based PowerShell CLI invocation in mind.Callers must be aware of PowerShell’s parameter syntax, which generally differs from that of POSIX (single-letter option names such as
-f) and GNU utilities (with multi-letter option names requiring--, e.g.--color).That said, even though PowerShell-idiomatically parameters are multi-letter but only require
-(e.g.-Path) in-File-based invocations (only), which includes shebang line-based invocations,--is accepted too (e.g,--Path).However, an important difference is that in PowerShell
-?rather than--hor--helpmust be used to invoke command-line help.
 | |
 Screenshot of a PowerShell 7 session in Windows Terminal | |
| Paradigm | Imperative, pipeline, object-oriented, functional and reflective |
|---|---|
| Designed by | Jeffrey Snover, Bruce Payette, James Truher (et al.) |
| Developer | Microsoft |
| First appeared | November 14, 2006; 17 years ago |
| Stable release | |
| Typing discipline | Strong, safe, implicit and dynamic |
| Implementation language | C# |
| Platform | PowerShell: .NET Windows PowerShell: .NET Framework |
| OS | |
| License | MIT License[2] (but the Windows component remains proprietary) |
| Filename extensions |
|
| Website | |
| Influenced by | |
| Python, Ksh, Perl, C#, CL, DCL, SQL, Tcl, Tk,[3] Chef, Puppet | |
PowerShell includes its own extensive, console-based help (similar to man pages in Unix shells) accessible via the Get-Help cmdlet. Updated local help contents can be retrieved from the Internet via the Update-Help cmdlet. Alternatively, help from the web can be acquired on a case-by-case basis via the -online switch to Get-Help.
- cmdlets (.NET Framework programs designed to interact with PowerShell)
- PowerShell scripts (files suffixed by
.ps1) - PowerShell functions
- Standalone executable programs
Extended Type System
The number of cmdlets included in the base PowerShell install has generally increased with each version:
| Version | Cmdlets | Ref |
|---|---|---|
| Windows PowerShell 1.0 | [38] | |
| Windows PowerShell 2.0 | [39] | |
| Windows PowerShell 3.0 | [40] | |
| Windows PowerShell 4.0 | ? | |
| Windows PowerShell 5.0 | [41] | |
| Windows PowerShell 5.1 | [] | |
| PowerShell Core 6.0 | ? | |
| PowerShell Core 6.1 | ? | |
| PowerShell Core 6.2 | ? | |
| PowerShell 7.0 | [] | |
| PowerShell 7.1 | ? | |
| PowerShell 7.2 | ? | |
| PowerShell 7.4 |
# Definition of static parameters # Definition of dynamic parameters # Set of instruction to run at the start of the pipeline # Main instruction sets, ran for each item in the pipeline # Set of instruction to run at the end of the pipeline
Desired State Configuration
Upon running a configuration, DSC will ensure that the system gets the state described in the configuration. DSC configurations are idempotent. The Local Configuration Manager (LCM) periodically polls the system using the control flow described by resources (imperative pieces of DSC) to make sure that the state of a configuration is maintained.
Initially using the code name “Monad”, PowerShell was first shown publicly at the Professional Developers Conference in October 2003 in Los Angeles. All major releases are still supported, and each major release has featured backwards compatibility with preceding versions.
Windows PowerShell 1.0
Windows PowerShell 2.0
Windows PowerShell 3.0
- Scheduled jobs: Jobs can be scheduled to run on a preset time and date using the Windows Task Scheduler infrastructure.
- Session connectivity: Sessions can be disconnected and reconnected. Remote sessions have become more tolerant of temporary network failures.
- Improved code writing: Code completion (IntelliSense) and snippets are added. PowerShell ISE allows users to use dialog boxes to fill in parameters for PowerShell cmdlets.
- Delegation support: Administrative tasks can be delegated to users who do not have permissions for that type of task, without granting them perpetual additional permissions.
- Help update: Help documentations can be updated via Update-Help command.
- Automatic module detection: Modules are loaded implicitly whenever a command from that module is invoked. Code completion works for unloaded modules as well.
- New commands: Dozens of new modules were added, including functionality to manage disks
get-WmiObject win32_logicaldisk, volumes, firewalls, network connections, and printers, which had previously been performed via WMI.[further explanation needed]
Windows PowerShell 4.0
New features in PowerShell 4.0 include:
- Desired State Configuration:[83][84][85] Declarative language extensions and tools that enable the deployment and management of configuration data for systems using the DMTF management standards and WS-Management Protocol
- New default execution policy: On Windows Servers, the default execution policy is now
RemoteSigned. - Save-Help: Help can now be saved for modules that are installed on remote computers.
- Enhanced debugging: The debugger now supports debugging workflows, remote script execution and preserving debugging sessions across PowerShell session reconnections.
- -PipelineVariable switch: A new ubiquitous parameter to expose the current pipeline object as a variable for programming purposes
- Network diagnostics to manage physical and Hyper-V‘s virtualized network switches
- Where and ForEach method syntax provides an alternate method of filtering and iterating over objects.
Windows PowerShell 5.0
Key features included:
- The new
classkeyword that creates classes for object-oriented programming - The new
enumkeyword that creates enums OneGetcmdlets to support the Chocolatey package manager[87]- Extending support for switch management to layer 2 network switches.[88]
- Debugging for PowerShell background jobs and instances of PowerShell hosted in other processes (each of which is called a “runspace”)
- Desired State Configuration (DSC) Local Configuration Manager (LCM) version 2.0
- DSC partial configurations
- DSC Local Configuration Manager meta-configurations
- Authoring of DSC resources using PowerShell classes
Windows PowerShell 5.1
PowerShell Core 6
- The
-Parallelswitch for theForEach-Objectcmdlet to help handle parallel processing - Near parity with Windows PowerShell in terms of compatibility with built-in Windows modules
- A new error view
- The
Get-Errorcmdlet - Pipeline chaining operators (
&&and||) that allow conditional execution of the next cmdlet in the pipeline - The ?: operator for ternary operation
- The
??operator for null coalescing - The
??=operator for null coalescing assignment - Cross-platform
Invoke-DscResource(experimental) - Return of the
Out-GridViewcmdlet - Return of the
-ShowWindowswitch for theGet-Help
Comparison of cmdlets with similar commands
-
lsandmanaliases are absent in the Linux version of PowerShell Core. - Clear-Host is implemented as a predefined PowerShell function.
- Available in Windows NT 4, Windows 98 Resource Kit, Windows 2000 Support Tools
- Introduced in Windows XP Professional Edition
- Also used in UNIX to send a process any signal, the “Terminate” signal is merely the default
-
curlandwgetaliases are absent from PowerShell Core, so as to not interfere with invoking similarly named native commands.
| Extension | Description |
|---|---|
| .ps1 | Script file[111] |
| .psd1 | Module’s manifest file; usually comes with a script module or binary module[112] |
| .psm1 | Script module file[113] |
| .dll | DLL-compliant[a] binary module file[114] |
| .ps1xml | Format and type definitions file[49][115] |
| .xml | XML-compliant[b] serialized data file[116] |
| .psc1 | Console file[117] |
| .pssc | Session configuration file[118] |
| .psrc | Role Capability file[119] |
| Application | Version | Cmdlets | Provider | Management GUI |
|---|---|---|---|---|
| Exchange Server | 2007 | 402 | Yes | Yes |
| Windows Server | 2008 | Yes | Yes | No |
| Microsoft SQL Server | 2008 | Yes | Yes | No |
| Microsoft SharePoint | 2010 | Yes | Yes | No |
| System Center Configuration Manager | 2012 R2 | 400+ | Yes | No |
| System Center Operations Manager | 2007 | 74 | Yes | No |
| System Center Virtual Machine Manager | 2007 | Yes | Yes | Yes |
| System Center Data Protection Manager | 2007 | Yes | No | No |
| Windows Compute Cluster Server | 2007 | Yes | Yes | No |
| Microsoft Transporter Suite for Lotus Domino[120] | 08.02.0012 | 47 | No | No |
| Microsoft PowerTools for Open XML[121] | 1.0 | 33 | No | No |
| IBM WebSphere MQ[122] | 6.0.2.2 | 44 | No | No |
| IoT Core Add-ons[123] | 74 | Unknown | Unknown | |
| Quest Management Shell for Active Directory[124] | 1.7 | 95 | No | No |
| Special Operations Software Specops Command[125] | 1.0 | Yes | No | Yes |
| VMware vSphere PowerCLI[126] | 6.5 R1 | 500+ | Yes | Yes |
| Internet Information Services[127] | 7.0 | 54 | Yes | No |
| Windows 7 Troubleshooting Center[128] | 6.1 | Yes | No | Yes |
| Microsoft Deployment Toolkit[129] | 2010 | Yes | Yes | Yes |
| NetApp PowerShell Toolkit[130][131] | 4.2 | 2000+ | Yes | Yes |
| JAMS Scheduler – Job Access & Management System[132] | 5.0 | 52 | Yes | Yes |
| UIAutomation[133] | 0.8 | 432 | No | No |
| Dell Equallogic[134] | 3.5 | 55 | No | No |
| LOGINventory[135] | 5.8 | Yes | Yes | Yes |
| SePSX[136] | 0.4.1 | 39 | No | No |
Wikiversity has learning resources about PowerShell
- PowerShell on GitHub
- Windows PowerShell Survival Guide on TechNet Wiki
Getting Started
For information about the system requirements for the PowerShell module and how to download and install it, see Getting Started – PowerShell.
XenServer PowerShell module overview
XenServer sessions
The first cmdlet you will need is Connect-XenServer to open a session to a server:
All XenAPI calls are made in the context of a login session, so all cmdlets
accept the parameter -SessionOpaqueRef which allows you to specify which of the
open XenServer sessions to use:
This parameter is not necessary when only one open session exists or when a
default session has been specified.
Once you have finished interacting with a server, it is good practice to log out
using the cmdlet Disconnect-XenServer:
Managing XenAPI objects
1. Class getters
These retrieve a XenAPI object and have names such as Get-XenT, where T is an
exposed XenAPI class. The object to get can be specified by -Ref or, for those
that have a uuid or name, -Name or -Uuid. If no parameters are specified, all
objects of this type are returned. Example:
2. Constructors
These create a new XenAPI object and have names such as New-XenT, where T is
an exposed XenAPI class. Example:
3. Class removers
These destroy a XenAPI object and have names such as Remove-XenT, where T is
an exposed XenAPI class. To specify the object to remove use the parameter
-T, where T is the exposed XenAPI class, or -Ref or, for those objects that
have a uuid or name, -UUID or -Name. Example:
4. Property setters
These set a field of a XenAPI object and have names such as Set-XenT, where
T is an exposed XenAPI class. To specify the object use the parameter -T, where
T is the exposed XenAPI class, or -Ref or, for those objects that have a uuid
or name, -UUID or -Name. The field to set can be specified as an accordingly
named parameter. Note that more than one fields at a time can be set in a
synchronous call. Example:
5. Property adders
These add an element to a field of a XenAPI object and have names such as
Add-XenT, where T is an exposed XenAPI class. To specify the object use the
parameter -T, where T is the exposed XenAPI class, or -Ref or, for those objects
that have a uuid or name, -UUID or -Name. The field to which the element
will be added can be specified as an accordingly named parameter. Note that
elements can be added to more than one fields at a time in a synchronous call.
Example:
6. Property removers
These remove an element from a field of a XenAPI object and have names such
as Remove-XenTProperty, where T is an exposed XenAPI class. To specify the
object use the parameter -T, where T is the exposed XenAPI class, or -Ref or,
for those objects that have a uuid or name, -UUID or -Name. The field from
which the element will be removed can be specified as an accordingly named
parameter. Note that elements can be removed from more than one fields at a
time in a synchronous call. Example:
7. Property getters
These retrieve the value of a field of a XenAPI object and have names such as
Get-XenTProperty, where T is an exposed XenAPI class. To specify the object
use the parameters -T, where T is the exposed XenAPI class, or -Ref. To specify
the field use the enum parameter -XenProperty. Example:
8. Invokers
These invoke operations on XenAPI objects and have names such as Invoke-XenT,
where T is an exposed XenAPI class. To specify the object use the parameter
-T, where T is the exposed XenAPI class, or -Ref or, for those objects that
have a uuid or name, -UUID or -Name. To specify the call to invoke, use the
enum parameter -XenAction. Example:
Most of the XenAPI calls can be run synchronously or asynchronously. To run a
cmdlet asynchronously use the parameter -Async where available.
Note that, in the case of the setters, only one field can be set asynchronously
at a time, and in the case of the adders and removers, elements can be added or
removed asynchronously to only one field at a time.
Also, note that the cmdlets that are not explicit “getters” but return objects,
do so only when the standard parameter -PassThru is specified. These cmdlets are
Connect-XenServer, the constructors, adders, setters, certain invokers,
the property removers, as well as all the asynchronous calls from any category.
In the latter case, the cmdlet returns a Task object, the progress of which can
be tracked by piping it into the cmdlet Wait-XenTask:
Wait-XenTask, too, can be used with the -PassThru parameter and, where applicable,
it returns the opaque reference of the object that would be returned if the call
were run synchronously.
Finally, as many of the cmdlets handle objects of type XenRef<T>, where T is an
exposed API class, the cmldet ConvertTo-XenRef can be used to aid conversion
between the two. Example:
Complete walk-throughs
How to configure vGPU and GPU pass-through
We start by connecting to the server:
The first thing we probably want to check is which GPU groups exist (these have been created automatically once the graphics hardware is installed):
Now we can list some information about the vGPU types. The vGPU types are pre-sets which can be used to create different kinds of vGPUs.
The vGPU type passthrough is supported for all PCI display devices, and can be used to create pass-through vGPUs.
A vGPU type will show up as supported or enabled in a GPU group if it is supported or enabled respectively on at least one of the pGPUs in the group. We can query the GPU groups to find out which vGPU types are supported or enabled. For example:
We may want to find out how many vGPUs of a certain type can be started on the pGPUs in a group, in addition to the vGPUs which are already running:
At this stage we can boot the VM, install the in-guest NVIDIA drivers, and enable RDP. Then we may want to disable the VNC console as this has a significant performance overhead. To do this we need to shut down the VM, set the flag vgpu_vnc_enabled to false and then boot the VM.
Before finishing we should remember to disconnect from the server:
How to copy or live migrate a VM across pools
This example also displays how to work with multiple sessions and use implicitly
the global variable $XenServer_Default_Session.
We’re starting by connecting to the source server. The session created with the
source server will be more frequently used, so it makes sense to set it as the
default session:
Let’s select the VM we are going to copy or live migrate from the source pool:
Note that in the above call we did not need to specify the -Session parameter
since we have set the source session as the default one.
Then we need to connect to the destination pool and obtain its coordinator. Note
that we will need to specify the -Session parameter in all calls made to the
destination pool since this session is not the default one.
The coordinator of the destination pool has to be prepared to receive the
VM that will be live migrated or copied. For this, we will also need to obtain
the details of the network on the destination pool through which migration
traffic will be received.
Similarly, we proceed to map the VM’s disks to storage repositories on the
destination pool. Let’s consider a simple case where we want to place all VM
disks on the same storage repository with name $destSrName.
Now we are ready to live migrate or copy the VM to the destination pool. Both
operations are performed using the same cmdlet. However, we need to specify
different options in each case. The call is run on the source pool session. Due
to the long duration of the operation, it is recommended to run it asynchronously.
To live migrate a running VM:
Or, to copy a halted VM:
In either case, we can monitor the task progress:
Once the task is finished, we can query it to obtain the new VM on the
destination pool:
"Operation failed: "Finally, we need to disconnect from the source and the destination pools:
