Over the course of my travels, I’ve found that having a quick reference to random Windows commands is helpful. Here are two sets of commands I use often enough to be useful, but not often enough that I’ve committed them to memory:

Managing IP Addresses from the CLI

Netsh! – This one predates PowerShell on Windows boxes, and went a long way to helping the everyday lives of Windows Admins.

Backup IP Address Config

netsh -c interface dump > c:\ip_address.txt

Restore IP Address Config

netsh -f c:\ip_address.txt

Set Interface to DHCP

netsh interface ip set address "Local Area Connection" dhcp
netsh interface ip set address "Local Area Connection" dhcp

Set Static IP Address

netsh interface ip set address name="Local Area Connection" static 192.168.0.100 255.255.255.0 192.168.0.1 1
netsh interface ip set dns "Local Area Connection" dhcp

Reset the TCP/IP Stack

netsh int ip reset all

Finding the Uptime of a Windows Box

Because you can not always plan on the presence of uptime.exe on a box, the following will get the info for you:

SystemInfo

systeminfo | more

Statistics

net statistics workstation

Sources:

• http://www.petri.co.il/configure_tcp_ip_from_cmd.htm
• http://burrowowl.net/wordpress/200606/netsh_int_ip_reset_all/
• http://www.windowsreference.com/general/how-to-find-the-system-uptime-in-windows-vistaserver-2008xp2003/

Today’s post is brought to us by Chris, a member of the VMware community who wields some powerful Louisianan VooDoo magic (and PowerCLI). Chris uses this to show us how to take a csv file in, and use it to attach a VM to a dVS switch as well as adding the VMXNET3 nic to the VM. Getting right on with it:

Story:

Had to bulk create a bunch of VMs. The new server standard has each production server on 2 networks, the normal production network, and an auxiliary network (for backups, updates, management, etc). The issue I ran into was that our switches were created in vSphere as virtual distributed switches (using the Cisco Nexus 1000v). The standard new-vm script wouldn’t allow you to connect the network adapter to that switch, unfortunately. Also, we preferred to use VMXNET3 NICs as opposed to the default e1000, another thing that new-vm doesn’t allow. So I wrote the following script in PowerCLI that does the following:

• Reads in a CSV file (fields: Name,Description,OS,Disk,Memory)
• Connects to the vSphere server (you specify the server and cluster to add VMs to).
• Creates a VM in the specified folder on the ESX host with the least memory utilization and the datastore with the most free space and having at least 30gb free space
• Removes the default e1000 NIC
• Adds 2 VMXNET3 NICs on temporary networks (cannot add directly to vDS)
• Connects the 2 VMXNET3 NICs to the vDS
• Powers on VM

Tried to generalize code as much as possible, works here, but this was a new rollout so there may be differences in how other people have it.

Script:

Ending

Perhaps they’re not new, exactly. They are new to me, however. They’re also good enough that you should be reading them as well! With that said, onto the blogs!

• VMDEV.info – http://www.vmdev.info/
  This is put together by Keshav Attrey, a software dev with VMware. The blog concentrates on the vSphere APIs and automation around virtual desktops. My kinda blog!
• B3rg.nl – http://www.b3rg.nl/index.php
  This was a more than awesome find that came up during the last VCP4 Brown Bag. Not sure how I missed it in fact. Matthijs van den Berg covers esxtop, VCP prep, VCDX Prep and more. Good stuff.
• Double Cloud – http://www.doublecloud.org/
  This is put together by Steve Jin. The author of the vSphere Java SDK, and the book: VMware VI and vSphere SDK: http://bit.ly/5I10nn (Affiliate Link). Basically, if you are going to do vSphere API work, this is the place to start.

When was the last time you found yourself configuring VMware tools on Linux? Did having to incessantly press enter accepting the defaults drive you nuts too? I think I might be the last one to the game on this, but today I was stumbling through configuring VMware tools on a few Linux VMs. Stumbling, over a terminal services session, over VPN, over some rural interwebs carrier.

A less than ideal sort of situation. The solution… other than get better internets, was to execute both “~/vmware-tools-distrib/vmware-install.pl” and “/usr/bin/vmware-config-tools.pl” with the “–default” (two dashes, then default) option. Like this:

What this does, is instead of making you hit enter for each of the options (because, ya know… you change them all that often), and accepts the defaults, making the entire install that much easier.

While all of PowerCLI is remarkable in both it’s power and ease of use, there are some cmdlets that do not get as much airtime as they deserve. One of those, is Invoke-VMScript. From Get-Help InvokeVMScript

NAME
    Invoke-VMScript

SYNOPSIS
    Executes the specified PowerShell script in the guest OS of each of the specified virtual machines.

SYNTAX
    Invoke-VMScript [-ScriptText] <String> [-VM] <VirtualMachine[]> [-HostCredential <PSCredential>] [-HostUser <String>] [-HostPassword <SecureString>] [-GuestCredential <PSCredential>] [-GuestUser <String>] [-GuestPassword <SecureString>] [-ToolsWaitSecs <Int32>] [-Server <VIServer[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

DETAILED DESCRIPTION
    Executes the specified PowerShell script in the guest OS of each of the specified virtual machines. The virtual machines must be powered on and have PowerShell and VM Tools installed. In order to authenticate with the host or the guest OS, one of the HostUser/HostPassword (GuestUser/GuestPassword) pair and HostCredential (GuestCredential) parameters must be provided.

Take a close look at the synopsis line, in fact, read it again. I’ll wait. Done? Good. Invoke-VMScript executes a specified PowerShell script INSIDE the guest OS. Starting to feel the power? No? Fine, how bout a use case? It’s yearly inventory time. You know… that time. Your boss wants a list of all VM Names, build numbers, serials, versions, and some other random things. Now, one of two things happens, either you procrastinate and then need to extend your deadline so you can log into every box, OR you use the following one-liner:

get-vm | select -first 1 | %{ $_.Name; $_ | Invoke-VMScript -GuestUser "adminUser" -GuestPassword "urPass" -ScriptText "get-wmiobjectwin32_operatingsystem" -HostUser "root" -hostpassword "rootPass" }

That one liner (yes it is all one line) works kinda like this: Get a list of all my VMs, select the first one, then give me the name, and the output of get-wmiobjectwin32_operatingsystem. In turn, it produces the following output:

web.professionalvmware.com

SystemDirectory : C:\WINDOWS\system32
Organization    : ProfessionalVMware
BuildNumber     : 3790
RegisteredUser  : ProfessionalVMware
SerialNumber    : Your Serial Number here
Version         : 5.2.3790

Not convinced of Invoke-VMScript’s World Dominatingly Awesome Power? Well, let me know in the comments.

If that title won’t have my mother calling me… Well, at least it someone’s attention. Prior to VMware Player 3.0 I never gave it much time of day. Sure it worked, and sure there was a way to work around the create VM limitation and the like, but it just wasn’t… well, you got what you paid for. Besides, I had a VMware Workstation license from my VCP test, and did not have to worry like some folks. Now… that has all changed.

It has been a little bit since my last “Incident” with my laptop, and at the rate that I’m going, for my daily needs, VMware Player is quite good. Like your Dad’s (or depending on that generation your) Datsun pickup truck. It works. It works well, and consistently. It may be rough around the edges in some areas, but all and all it is a solid package, and likely deserves a second look. Heck, it will even run, and has an easy installer for ESX!

Have you tried Player 3.0? Liked it? Disliked it? Discuss in the comments.

Note: I am not actually having a marital affair… nor do I know who the folks in the picture are, the photo is courtesy of: Patrick Q

Note: This is a brief story where I was forced to sit back and reflect on just how cool this Virtualization stuff really is. Please feel free to disregard however.

Normally I don’t write about the VMware Workstation or hosted products. It just doesn’t happen to be where I spend most of my day. Mind, I use VMware Workstation and VMware Player, but they often “Just Work”. In fact they work well enough that I’ve trusted them to running most of my day to day applications for some time, without much thought.

This weekend presented me an opportunity to reflect on just how awesome desktop virtualization is. I powered my laptop on this Sunday, only to find a bunch of random disk read errors, and other nasty drama on my secondary or “caddy” disk (a secondary disk that sits in a drive caddy where the CD-ROM usually goes).

I pulled the drive out, swapped it into another laptop chassis to do some diagnostics. Well…good news was, the drive was healthy, and the sata controller ate it. Before virtualizaiton, this would have meant spinning up a new laptop, copying files and fiddling settings for hours on end. What it means now however, is I pull down Player 3.0, point it at my disk, and go. Forgetting the fact that the old host was Linux, and the new one Windows. Cool!

This one came at me from left field recently. The task at hand was to cold migrate one of a Virtual Machine’s disks from it’s old LUN, to a new one with some more breathing room. Simple enough, no? We’ve all done it a million times. What happened however, was that I received a “Error: Failed to Connect to Host” message.

To triage this, I first logged into the host, and verified that networking was sane:

cat /etc/sysconfig/network

cat /etc/hosts

ping gateway, ping service console gateway, etc.

After verifying this was all good, I tried to reconfigure the host for VMware HA (to update the FT_HOSTS file, etc). No good, so I turned to Google (who wouldn’t) and came across this post written by Duncan Epping @ Yellow-Bricks. While I didn’t use the solution as posted on the site, some of the comments led me in the right direction, bringing me to:

1. Put the host into maintenance mode
2. Disconnect the host (Right click, disconnect)
3. Remove the host from vCenter (Right click, Remove)
4. Move /etc/opt/vmware/vpxa/vpxa.cfg to vpxa.old
5. Connect the host to vCenter
6. Add to Cluster
7. Exit Maintenance mode

Hope this helps. Let me know in the comments.

Amazon just posted my 3 star review of OnlineFlashCards for the VCP310. You can read the entire thing here. I’ve quoted some bits of it here:

When I received the product, it came in a shrink wrapped box. Odd I thought, considering this is an online product, what is the box for? I shook it up and down. I shook it side to side. I even shook it at a diagonal. All of this trying to see what the box was about. After removing the shrink wrap, and opening the box, I discovered what all of the fuss was about. Packaged within the box was a little bit of magic! It was the key to opening up the flashcards online!

Some explanation about the 3 stars: There were some ‘not right’ answers included in the bundle. While not in and of itself a problem, this may throw new users off the mark some. However, when taken within the context of using the cards to supplement the VMware class and other reading material, the cards will make a good aid for quizzing yourself. My only other complaint is that I was expecting more “Meat”, however, I believe this is because I already hold a VCP certification. All and all I can see where this would be useful in the training arsenal of a budding VCP310.

Remember this? No? Well, go back and read it. I can wait. … Done? Good.

The gist of the last post, was that if you cloned, or copied a Ubuntu VM from one host to another, the UUID changes. That UUID is the basis for part of the generated MAC address, which then changes, causing me a headache. Today I found that SLES (Suse Linux Enterprise Server) is guilty of the same binding, only much to my chagrin it stores the rules file with another name: /etc/udev/rules.d/30-net_persistent_names.rules

The procedure to fix it is the same as listed before:

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0×1022:0×2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:02:51:cf", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

An ugly beast of a file but that last line is the one that needs deleting. Another method of doing this, is to edit the ‘persistent-net-generator.rules’ file to include something similar to:

# ignore VMware virtual interfaces
ATTR{address}=="00:0c:29:*", GOTO="persistent_net_generator_end"

This procedure should work with most distributions that use this method to map the NICs and eth interfaces, and it should only be a matter of finding and editing the corresponding file. If you have any questions or comments, hit me up on twitter, or in the comments.