PowerCLI Copy-VMGuestFile Cmd-let

Hi all,

 

This is one of my most used, and favourite cmdlets in PowerCLI.  It allows you to copy a file to a guest VM from where ever you’re running your PowerCLI session and vice-versa. 

 

What’s the benefit of that I hear you ask?

What if you have a template that you haven’t assigned an IP address to, and that you don’t want to assign an IP to due to stringent policies in place by your company, but you still really need to get that file up to the VM?

Basically any restriction on network access and this command can help you out.

It uses TCP port 902 to transfer the file, so you must have that port open for this to work!  You can test this just by trying to open a console session to the VM in vCenter.

So to utilise this cmdlet:

Copy-VMGuestFile -Source *Source path from your local machine*  -Destination *Path to required destination in the VM*  –VM *vmname*  -HostUser *Admin account for the ESX\ESXi host the VM is resident on* -HostPassword **** -GuestUser “Domain or Computername\Username for the VM OS”  -GuestPassword ****** -LocalToGuest (or -GuestToLocal) **Defines the direction of the file copy**

 

You can also use credential store xml files to authenticate using the –guestcredentials and –hostcredentials parameters.

There are some pre-requisites to be met before you use this cmdlet however:

·         You must have VMTools installed in the guest
·         You must run this cmdlet from the 32-bit version of PowerCLI
·         It only runs on the following OSs:

XP 32-bit SP3

2003 32-bit SP2

2003 64-bit SP2

Windows 7 64-Bit

Windows Server 2008 R2 64-Bit

RHEL 5

 

·         For vCenter Server/ESX/ESXi versions earlier than 4.1, you need the VirtualMachine.Interact.ConsoleInteract privilege. For vCenter Server/ESX/ESXi 4.1 and later, you need the VirtualMachine.Interact.GuestControl privilege.
To run this cmdlet against vCenter Server/ESXi 5.0 and later, you need VirtualMachine.GuestOperations.Modify privilege.

Hopefully you’ll get as much use out of this as I do!

 

Chris.

The Case of the Really Slow vCenter Logons

My latest client had implemented vSphere 5.1 by themselves.  They had done a good job, following some in depth architectural processes. 
All was working well and the infrastructure was hosting a relatively small amount of production VMs successfully.
The only thing was, that authentication to vCenter was taking an incredible amount of time.  They were using SSO (as it was vSphere 5.1) to authenticate against a large, multi-domain AD forest.

Using the:

Measure-command {Connect-viserver –server *****} command I got a decent benchmark:

Days              : 0

Hours             : 0
Minutes           : 0
Seconds           : 238

238 seconds!?!?

My initial thought was that the slowness was solely due to the fact that the Domain Controller used to authenticate against was located in a different country, accessed across a WAN link.  Changing the identity source to a local DC would surely make a huge improvement?  I made the relevant changes in SSO to point locally and ran the command again:

 

Days              : 0

Hours             : 0
Minutes           : 0
Seconds           : 36

 

Better! But not good enough..
I scratched my head for a few more days, until I began thinking about the level in AD SSO was searching at.

If SSO had to wade through hundreds of thousands of AD objects to find the User Group Membership, of course it would take a while.  So I checked the Base DN for Users and Base DN for Groups fields in SSO Administration and sure enough they had both been set at the very top level of the domain.

I queried AD to find which OU the groups and vCenter users were located in and entered this DN (Distinguished Name) in to the Edit Identity Source form.

I ran the measure-command again and got:

Days              : 0

Hours             : 0
Minutes           : 0
Seconds           : 6

That’s was more like it! 

 

NB: If you decide to make this change, make sure you put some thought into where the OU is within AD.  You don’t want to end up specifying an OU that’s too deep within the AD structure meaning that you exclude some of the people who should be logging on!

 

Chris.