Exporting a Hyper-V virtual machine using PowerShell

I know I’m a little VMware-centric when it comes to PowerShell and virtualization. This shouldn’t be too surprising with the features of PowerCLI combined with our PowerVI VMware tool.  

I thought I would venture off that path with a blog post I found by Ben Armstrong that explains how to export a Hyper-V virtual machine using PowerShell -

I need to automate the process of exporting a virtual machine recently – and when I checked around I found that while there are a number of sample scripts out there that show you how to do this (some even on this blog) they are all written in VBScript.  As I am now to the stage where PowerShell is my preferred scripting language – I sat down and wrote up this short script:

(read more and get script)

• #powershell
• #powercli
• #hyperV
• #vmware
• #powervi
• #powerwf
• #PowerSE

Disabling a View Pool with PowerCLI

Rob Daniels at ClearPath Solutions Group has an interesting post on disabling a view pool for VMware.  He points out that there isn’t currently a PowerCLI command to do it, but came up with a PowerShell solution anyway.

Have you ever wanted to disable a VDI pool from the command line, but couldn’t find the right command for the job? As simple as it may seem to do, VMware has yet to equip the PowerCLI Snap-in with a “disable-pool” commandlet. Some may try to accommodate this by simply removing pool entitlements, but you can be faced with the following error:

Remove-PoolEntitlement : PowershellService::RemovePoolEntitlement FAILED, 

error=User with sid  has an active VDI Session on Pool . Entitlement cannot be 

removed until this session is terminated.
 

This error is the result of an active desktop session attached to the entitlement being removed, or worse, anywhere within the VDI system as this is a global property. What this means is that if a user has an entitlement to more than one pool, this command may fail every time. As a work-around, there is a value within the local ADAM database on the View broker server. It is a Boolean value with the name “pae-Disabled” and can be found in the vdi.vmware.int\Applications\ attribute of the local LDAP. Below is an example of how this value can be toggled from a script:

(read more and get script)

• #PowerShell
• #PowerCLI
• #VMware
• #vsphere
• #PowerWF
• #PowerVI
• #PowerSE

PowerShell Implicit Remoting and VMware

Jason Hofferle has a nice post that discusses using PowerShell implicit remoting to take advantage VMware’s View cmdlets when you aren’t on the connection server.

One of the differences between the VMware View cmdlets and PowerCLI is that the View cmdlets can only be run on the connection server itself. Despite the lack of a Connect-VIServer equivalent, with PowerShell Implicit Remoting it’s still possible to use these cmdlets from a workstation.

First, PowerShell Remoting needs to be enabled on the Connection Server. There are several ways to configure remoting, but in a domain environment I like to turn it on with group policy. Enabling the automatic configuration of listeners is usually all the configuration necessary to enable remoting on a domain server, but lots of information is available for different situations.

(read more and get sample code)

• #PowerSE
• #powershell
• #vmware
• #vsphere
• #PowerWF

Alan Renouf’s Top 5 PowerCLI Scripts

Alan Renouf has posted his top PowerCLI scripts of the week (a couple are from PowerWF friend Luc Dekens).  There are scripts on High Availability, Storage DRS, getting VMware Views, and virtual machine start up scripts.

• #powershell
• #powervi
• #powercli
• #PowerSE
• #powerwf
• #vmware
• #vsphere

How to Change ESX Host Root Password

Did you know that PowerVI includes a PowerShell script that lets you change the root password on multiple ESX host at one time.  This is useful if you have a policy to change the passwords regularly, but want to keep the password the same across all hosts.

To change the password -

1. Make sure PowerVI is installed.
2. Open the vSphere client and connect to your vCenter
3. Select all of the ESX Hosts that need to have their root password changed
4. Right click and select “Set Host Root Password”
   
5. PowerVI will launch a dialog that lets you specify the old password and set the new password.
   
6. PowerVI will show you the progress as it changes the password for each of the selected hosts.

• #powershell
• #powercli
• #powervi
• #vsphere
• #vmware

Cmdlet Name Conflicts

Don Jones has a short article on PowerShell cmdlet name conflicts.  The article discusses what happens if multiple PowerShell modules have cmdlets with the same name, such as Get-VM which could show up in a HyperV and VMware/vSphere/PowerCLI module.  It is a short article, but worth a quick read to understand how PowerShell handles these conflicts.

• #powershell
• #vmware
• #vsphere
• #hyperv
• #PowerSE
• #powerwf
• #powervi

Give Your $.02 on PowerCLI

VMware is in the process of extending PowerCLI capabilities to automate vCloud Director, and they want your feedback (assuming you currently use PowerCLI).

As announced at VMworld 2011, we are currently in the process of extending the PowerCLI capabilities to automate vCloud Director (vCD) configuration, as part of this we would like to focus the users of PowerCLI and vCloud Director and allow you to have your say.

To do this we have put together 4 simple questions to get your feedback.

Please select the option that best fits your desired user experience for each of the questions.

To thank you for filling in this survey, we will select one of you at random to take the PowerCLI training course online on the TrainSignal website.

(read more)

• #powercli
• #powershell
• #vmware
• #vsphere

Using New-VIProperty to get VM Tools Version

Alan Renouf has a new blog post up that takes advantage of the New-VIProperty cmdlet to add the VMware tools version to the get-vm cmdlet.  you may recall that Luc Dekens had a rather extensive post a while back that talked about many cool things you could do using the New-VIProperty cmdlet.

Here’s Alan’s use case…

If we look at the  object which gets returned back when we use the Get-VM cmdlet you will see […] the returned object doesn’t have a root property for ToolsVersion or ToolsVersionStatus, for this we need to delve into the ExtensionData property and have a look around, once we have found the information it is fairly easy to add these to our object using the New-VIProperty cmdlet as below:

New-VIProperty -Name ToolsVersion -ObjectType VirtualMachine `
    -ValueFromExtensionProperty ‘Config.tools.ToolsVersion’ `
    -Force

New-VIProperty -Name ToolsVersionStatus -ObjectType VirtualMachine `
    -ValueFromExtensionProperty ‘Guest.ToolsVersionStatus’ `
    -Force

Now we have added these as a new property to our object (actually they are PowerShell Code Properties), we can use our old friend Get-VM to retrieve the information easily:

Get-VM | Select Name, Version, ToolsVersion, ToolsVersionStatus

(read more)

It looks like Alan’s use case looks like it may already be covered, but I figured I would post the information anyway.

• #vmware
• #vsphere
• #powercli
• #powervi
• #PowerSE
• #powershell

Blog Shorts: Cool PowerShell Network Tricks

Network stats must be the PowerShell topic of choice this week.  The following all showed up in my RSS feed in the past few days:

• From Jeffery Hicks:
  Turning IPConfig DNSCache into PowerShell - Lately I’ve been writing about techniques to turn command line tools into PowerShell tools. Although I suppose the more accurate description is turning command line output into PowerShell pipelined output. The goal is to run a command line tool and write objects to the PowerShell pipeline so I can do other operations with them. Today I have another example that takes the DNS cache from IPConfig and turns it into a collection of PowerShell objects.
• From Niklas:
  PowerCLI to the rescue, how to check all VMs for Network card type - I got a question what network card some VMs had in a datacenter, as a best practice you should use VMXNET 3 where it is possible because it gives the best performance.  So i wrote this very simple [PowerShell/PowerCLI] script in a few lines that do a csv export of all VMs and what kind of NIC they have, of course one could extend it with OS and stuff but that will have to be next time cause my schedule is kind of tight.
• From Luc Dekens (in answer to vite@1):
  PowerCLI script that lists every IP within vCenter - I found a script that lists all VM’s IPs in vCenter and a command that list vMkernel ports adapter’s IPs.  Is there a way that I can put these two together in a script? LucD - the following will give you the Name ,[IP Address] and the MAC
  
  

• #powershell
• #powercli
• #vmware
• #vsphere
• #network
• #PowerSE
• #powerwf
• #powervi

I’ll Grab A Byte While I’m At The Credential Store

Did you know that you can store default credentials for PowerCLI to use when it connects to a VIServer? Andrey Anastasov has a post on the VMware blogs that shows you how this works.

It just occurred to me that a very useful feature of PowerCLI never got the introduction it deserves. The feature is the Credential Store and as the name suggests its job is to store credentials. As a result:

1. Credentials are kept securely (no need to hard code passwords along with scripts)
2. You type less (no need to specify user and password to Connect-VIServer)

(read more)

Pretty slick, but I’m not sure if I would feel comfortable using it or not. I guess you could add a default user with minimal credentials to the store so you could have read access to data, but not necessarily hurt anything.

It does point out how valuable PowerVI’s shared credential feature is - In PowerVI, your credentials are based on the user that is logged into the vSphere Client, so only people with the proper permissions can execute certain scripts.

• #powercli
• #vsphere
• #powervi
• #PowerSE
• #powerwf
• #vmware
• #powershell