How to Find a VM by MAC address with VMware PowerCLI

logo-powershellFinding a VM by its MAC address can be a non-trivial task, especially if you have a vCenter with tons of complicated virtual appliances and several network cards on each one of them. Fortunately, VMware has PowerShell CLI that can help here.

First, you will need to install PowerCLI on a Windows box. Check for PowerCLI version you want to use on its PowerShell Gallery page. PowerCLI versions are backward-compatible (PowerCLI v6.5 worked for me on vCenter 5.5), so just pick the latest stable version. On the way, PowerShell may ask you to update NuGet and/or trust installations from PowerShell Gallery.

PS C:\> Install-Module -Name VMware.PowerCLI -RequiredVersion 6.5.4.7155375

NuGet provider is required to continue
PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based repositories. The NuGet
 provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or
'C:\Users\ankhitre\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet provider by
running 'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to install
and import the NuGet provider now?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): Y

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its
InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from
'PSGallery'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): Y
PS C:\> 

Next step is to import core CLI module. You may need to adjust execution policy to do that – do it on your own risk, and make sure you know what you are doing first! Also, PowerCLI will prompt you to join their data collection program, but you can safely ignore that “warning” for now.

PS C:\> Import-Module VMware.VimAutomation.Core
WARNING: .....
PS C:\> 

Now you can connect to your vCenter:

PS C:\> Connect-VIServer -Server <IP/FQDN> -Protocol https -User <username> -Password <password>

Name                           Port  User
----                           ----  ----
<IP/FQDN>                      443   <user>

PS C:\> 

Note that if you don’t have valid SSL certificate on your vCenter, you will have to configure PowerCLI to deal with that – either prompt you to accept certificate on connection ("Set-PowerCLIConfiguration -InvalidCertificateAction Prompt") or just ignore those warnings altogether ("Set-PowerCLIConfiguration -InvalidCertificateAction Ignore").

Once CLI is connected to vCenter, finding for your VM by MAC address is one step away:

PS C:\> Get-VM | Get-NetworkAdapter | Where {$_.MacAddress -eq “00:50:56:12:34:56”} | Select-Object Parent,Name,MacAddress

Parent              Name                MacAddress
------              ----                  ----------
ubuntu-dev-012      Network adapter 1     00:50:56:12:34:56


PS C:\>

Alternatively, you can “pipe” the result through Format-List instead of Select-Object and get all available properties of this network adapter.

Good luck!

Notes on creation of Windows AMI in EC2

AWSCreating AMI from Windows instance in AWS is simple and easy. The whole process is well-documented, yet here are several notes that I made while experimenting.

Running Sysprep Tool
In the VMware world, you can convert a VM to a template at any moment. Deployment of multiple clones is made possible via Customization Specifications mechanism, where you define how to customize the new VM after cloning. As part of the customization process, vCenter will run Sysprep tool – after the instance was already cloned. In contrary, AWS wants you to run sysprep before the cloning, as preparation to AMI creation. You can do that via EC2ConfigService settings (see below) or manually, but former seems to be the preferred and recommended way.
The unwanted side effect of running sysprep on the original instance is that many of the original instance settings (instance name, Administrator account etc.) are actually reset during the cloning process. There are workarounds that can help you to deal with some consequences, but not all of them.

EC2ConfigService
The EC2ConfigService is Windows service provided and installed by AWS, which takes care about a lot of useful customizations behind the scenes. Examples are generation of Administrator password (one that you retrieve via “Connect” button in EC2 Management Console), setting of computer name, display of system information on the desktop wallpaper and a lot more. But the most important task is to deal with instance cloning – that is, make sure that stuff that is supposed to be unique is really unique and make this cloning process simple and easy.
Note that you cannot install this service on a Windows instance imported from other systems (for example, VMware vCenter). You’ll have to start your original instance from AWS AMI if you want to use EC2ConfigService there.

Instance Name
The name of the original Windows instance will be reset during sysprep process to the default semi-random name provided by AWS (in the form of “WIN-<something>”). The only workaround for that is to use “Set Computer Name” from EC2ConfigService settings. This flag instructs EC2ConfigService to (re)set system name according to the internal IP adrress – which remains constant during the instance lifecycle. The resulting name will not become much more readable, but at least it will not change during the AMI creation process. You’ll have to remove this flag manually on the cloned instances to set more meaningful names there.

Administrative Accounts
The Administrator account from the original instance will not make his way to the cloned instances, so any customizations made there will be lost. The workaround is to create an additional account with administrative permissions and perform the desired customizations there. There are many settings that will go this way too (for example, regional settings or pinned taskbar items), but some will survive – desktop shortcuts, windows explorer options and more.
Another tip is to choose “Keep Existing” in the “Administrator Password” section of EC2ConfigService configuration. While it won’t help you to retain current password in the new instances (because Sysprep tool on Windows 2008 resets it anyway), at least the Administrator password of your original instance will not be changed.

AMI Creation Steps
This is not an ultimate guide on how to create AMI, but rather a note/reminder to myself…

  1. Create a new EC2 instance from AWS AMI
  2. Create new administrative account and start using it instead of the build-in one
  3. (optional) Use “Set Computer Name” option from EC2ConfigService settings
  4. Customize your instance – install software, add desktop shortcuts etc.
  5. Start EC2ConfigService settings utility, go to the “Image” tab and perform the following:
    • (optional) Under “Administrator Password” section, select “Keep Existing” option
    • Click “Shutdown with Sysprep” button and confirm the prompt
  6. Wait while the Sysprep process completed and the instance shuts down
  7. Right-click the instance in the EC2 Management Console, choose “Create Image” and follow the instructions

Tip: Disk Size
When you launch an EC2 instance that you plan to convert to AMI later, pay attention to the disk size. Remember that the disk of the AMI must be at least that big, and the same applies to any instance that will be launched from the new AMI. Provisioning 10GB of spare storage in your AMI will cost you $1 per instance per month, which may be kinda painful in the yearly bill (do the math yourself).

How to convert VM hard drive from Thick to Thin Provisioning

Using Thin Provisioning for virtual disks of your VM can save you a lot of useful space on your datastore and significantly speed up maintenance tasks that involve copying or moving of the VMDK files. Apparently, switching from one provisioning format to another can be done easily via Clone Virtual Machine wizard, where Storage tab allows you to specify the virtual disk format for the cloned VM. There you can select either to keep the same disk format as source VM had or choose another one, including Thin Provision. However, the choice of Thin Provision disk format will be silently ignored when the source format is Thick Provisioned and both source and target are located in the same datastore. This behavior is somehow understandable when you think about the underlying implementation, but not user friendly.

So, how can you change the provisioning type of your VM from Thick to Thin anyway? Here is your algorithm.

  • Do you have more than one datastore available? You can migrate your VM to another datastore, modifying the virtual disk provisioning mode on the way, and then migrate it back if needed. This way is covered in details in the second part of KB2014832 article on VMware Knowledge Base.
  • Do you have only one datastore or all your datastores are under the same Storage DRS? You can create a clone of your VM with the help of vCenter Converter Standalone. This tool runs on your desktop and allows you to convert one VM format into another, changing most of the VM setting on the way. This includes change of disk provisioning type from Thick to Thin even when both source and destination are located on the same datastore.
  • Do you prefer the hard and risky ways? If so, dealing with vmkfstools if for you 🙂

Deployment of New VM from Template Fails with VMDK Locked Error

Some time ago I managed to isolate an ugly vSphere 5 bug that caused me some unpleasant moments. Today I finally reproduced this behavior in a clean lab environment, so I feel confident enough to describe it in public. Don’t worry, the way to recover is described also!

Take a vSphere 5 environment with a template (say, “MyTemplate”) that you want to deploy a virtual machine from. Step through a regular deployment wizard and select “Edit Virtual Hardware” on the last page. In the VM properties, choose the hard disk and change its size. The new VM (say, “MyVM”) will be created successfully, but the next time you’ll go through the deployment process it will fail with a strange message: “Unable to access file ‘MyTemplate/MyTemplate.vmdk’ since it is locked”…

A quick search in VMware KB (or just in Google) will tell you that the vmdk (the virtual disk of the VM) is usually locked when some other VM uses the same disk. Hey, this is a template! No other VMs are supposed to use the template disk, right? Well, the truth is that this disk is now attached to MyVM – yes, that one with different disk size… But let the lock alone. Your lovely template is now gone, since the disk that belonged to the template is now owned by the running virtual machine – with new name, settings and maybe even software!

Well, how do you recover from this situation? The good news are that the original disk from MyTemplate is not gone. In fact, vSphere really cloned a new vmdk file for MyVM and placed it where it should usually reside – in ‘MyVM/MyVM.vmdk’ – but for some reason set the MyVM to use a template file instead. At this moment you can take a deep breath, shut down MyVM, point it to the right virtual disk and physically swap the files in the datastore… Continue reading “Deployment of New VM from Template Fails with VMDK Locked Error”

How to install Admin Pack for Windows 2003 on Virtual Machine

The internet is full of complains that Admin Pack for Windows 2003 cannot be installed due to protected Windows files. I guess that this can happen for various reasons, but I have found a solution for at least one of the cases – when the server where the installation of Windows 2003 Admin Pack fails is virtualized.

So, we have two servers – Windows 2003 Server with Active Directory installed as Domain Controller (server #1) and VM with Windows 2003 Server that is a member of this domain (server #2). The need – administer DNS and DHCP settings of AD remotely, but corresponding MMC snap-ins are not available by default on non-DC machines. The correct way is to install ADMINPACK.MSI, available from Windows 2003 installation CD-ROM or from Microsoft Download Center. (Of course, you can always open an RDP session to a DC – but this does not address the real need.)

However, the installation suddenly shows a message “The Windows Installer service cannot update one or more protected windows files” and rolls back everything that was already installed. The Event Viewer reveals error numbers (“Error 1933. … SPF Error: 1223.”) and the list of protected files – but this does not really help. So, what can we do about that?

In fact, the solution is really simple. Running the same installation via the console RDP session (or in the vSphere console) reveals the real cause for the failure – the Admin Pack install needs Windows 2003 installation CD-ROM, but for some reason does not tell that on non-console sessions. After the requested CD is provided (for VMs, this can be done by mounting the CD image in vSphere or via DaemonTools), the installation was able to complete successfully. Continue reading “How to install Admin Pack for Windows 2003 on Virtual Machine”