In Part 1 we installed Vmware Player and installed Windows 2008 R2 Enterprise into a virtual machine. In this second part, we’ll look at setting up another virtual machine and deploying our first domain controller for the testing environment.

We could definitely go back and setup another virtual machine using the the same process as before. However, this takes too long; the least of which we have to wait for Windows 2008 R2 to re-install.

An easier option is to copy the existing virtual machine files to a new directory and paste it as a new virtual machine.

1. Right click on our perviously built virtual machine (inv-dc01), select Copy and then right click and Paste into the same directory. This will create two copies of the virtual machine, inv-dc01 (the original) and inv-dc01 – Copy. This process can be repeated as many times as we like until the local drive is full.

   

   For the moment, all that is required is the two copies of the virtual machine.

2. Rename inv-dc01 – Copy to _TMPL-inv-dc01. Now we have a TEMPLATE version of a virtual machine with Windows 2008 R2 installed and can continue to take copies of it as needed.

Onto setting up our domain controller.

1. Open the Vmware virtual machine configuration file by double clicking or right click and open the Vmware virtual machine configuration file with Vmware Player.
   
2. Once the operating system has started, use CTRL+ALT+INSERT to get to the login screen.
   
   At this point login as the user we created or login as Administrator. If you login as Administrator, Windows will prompt you to change the password. The Administrator password will also have to meet complexity requirements ie. uppercase, lowercase, letter, number and special characters.
3. Next up is the all important Vmware Tools. VMware Tools package adds drivers and utilities to improve the graphical performance for different guest operating systems, including mouse tracking. The package also enables some integration between the guest and host systems, including shared folders, plug-and-play devices, clock synchronisation, and cutting-and-pasting across environments.
   
   Click “Install Tools” in the bottom bar of the window to start the install process.
4. You may want to close this window for the moment to allow the Vmware Tools installer to run.
5. If this dialog fails to appear, open Windows Explorer, browse to the CD drive of the virtual machine and run setup.exe manually.
   
   Install Vmware Tools using the default settings; there is no real benefit to be gained from changing the default options in our scenario.
   
   Once the installer has completed, reboot the virtual machine and then log back in when it has restarted.

Once the desktop is initialised, there are a couple of configurations required before we can create the domain controller. Primarily, the IP address and the Windows machine name.

1. The domain controller ABSOLUTLEY has to have a statically assigned IP address, and the easiest (and most fun!) way to do this is set it via the command line:

   netsh interface ip show config

   
   This will show all the adapters currently available to the virtual machine. The interface that we are interested in is Local Area Connection. Once we have establised that it is available and has an IP address allocated from DHCP, it needs to be changed to a static IP address.

   netsh interface ip set address name="Local Area Connection" static 192.168.0.10 255.255.255.0 192.168.0.1 1

   This set the static IP of 192.168.0.10, subnet mask of 255.255.255.0 and default gateway (which we don’t need for the moment) of 192.168.0.1. For the purposes of completeness, it’s best to put the gateway in.
   DNS is still required, but configuring the domain controller will automatically install this service on the domain controller.
   Running ipconfig from the command line should verify the configuration has been applied.

2. Finally we’re at the point of installing the domain controller! From the command prompt, run dcpromo to start the install.
   
3. From here it is a simple matter of following the prompts.
   • At the Active Directory Domain Services Installation Wizard make sure Use advanced mode installation is NOT selected and press Next.
   • The next window is a warning about incompatibilites with Windows NT 4.0. Just press Next.
   • Choose a Deployment Configuration – Check the Create a new domain in a new forest and press Next.
   • Name the Forest Root Domain – In the FQDN of the forest root domain enter the name of your network. For our purposes, any name will do. invurted.local is acceptable. Press Next.
   • Set forest functional level – Select Windows 2008 R2 from the drop down list. This will mean that all domain controllers have to have at least Windows 2008 R2 as their operating systems. Press Next.
   • Additional Domain Controllers – Make sure the DNS Server option is ticked and press Next. Select Yes for any dialog boxes that appear.
   • Location for Database, Log Files and SYSLOG – Accept the default locations and press Next.
   • Directory Services Restore Mode Password – Enter the password of P@ssw0rd in both fields and press Next.
   • Summary – Verify your settings and press Next.
   • Active Directory Domain Services Installation WizardActive Directory will now start installing. At the completion, reboot the virtual machine. If everything is successful, upon reboot, your domain controller setup is complete.

Upon successful restart and login using the Administrator username and password, we want to look at our new domain. From the start menu, select Administrative Tools and launch the Active Directory Users and Computer program. This will allow us to create any users, groups and Organisation Units that are required.

I almost forgot! We need to rename our domain controller. In previous versions of Windows this was painful, especially as the virtual machine is a domain controller. In Windows 2008 there is more tolerance to name changes. It’s not the sort of thing that I would want to do regularly, but is possible.
In the start menu, right click on Computer and select Properties.

Chose Change settings and accept any warnings that appear on screen.

In the Sytem Properties, select Change and, again, accept any warning that appear.

In the computer name field enter the new name for the computer. For our purposes, inv-dc01 will do fine. Press OK twice and then close the system properties. At this point, it is a good idea to restart the machine again.

That’s Part 2 complete. In Part 3 we’ll look at configuring the virtual machine as a domain member server.

As ever, if you have any questions, please email me (contactme [at] invurted dot com).

Following a number of requests, I have written a tutorial on setting up a Windows 2008 testing environment. Part 1 looks at installing Vmware Player and setting up the first virtual machine
ASSUMPTIONS:

• A supported operating system is used. Vmware Player supports most Microsoft operating systems as well as a number of Linux distributions. For the purposes of this tutorial, Windows 7 is the operating system used as the base.
• The account on the Windows 7 base operating system is either a member of the Local Administrators group or can elevate priveledges as required.
• At least 50 – 100 GB of storage space is available for all the virtual machines. It’s better to err on the side of caution.
• Vmware Player is the chosen hypervisor. Vmware Workstation could as easily be used if available. We use Vmware Player as the hypervisor due to it’s cross platform compatibility and its free licensing.
• We are only doing the setup of the first virtual machine. Further configuration will be done in subsequent tutorials.

On to the fun bits! As with most hypervisor technologies, the result of what we are doing here is allowing me to run two (or more) instances of operating systems on the one hardware platform. Vmware Player is our chosen hypervisor because it removes a lot of the guess work from deploying virtual machines. Vmware Workstation definitely gives us more granular control over the final conifguration. For our purposes, the default RAM, CPU and storage configurations are more than acceptable.

1. Install Vmware player following all the default configuration options. There is little need to change the installation path etc. unless absolutley necessary.
2. Once installed, run the program and select “Create new Virtual Machines”.
   
   This will start the wizard driven configuration of the new virtual machine that we will use as the basis for the testing environment.
3. One of the first configuration options is the installation media. We’re focussing on the first two options; providing either a CDROM or an ISO file to install from. It’s possible to network boot a virtual machine, but that’s something for later.
   If we load a CDROM into the drive, Vmware Player should recognise the operating system. Similarly with an ISO file.
   
4. Next up, the all important licence key. Windows 2008 R2, Enterprise will install without a key being provided. It will install in Evaluation Mode giving us sixty days to activate with a valid licence. Again, for purely testing purposes, we can ignore the licence key and come back to it later if we need to. The only configuration to be aware of is the version of Windows 2008 to install. The CDROM (or ISO file, in this case) has a number of different versions available. Make sure Windows 2008 R2 Enterprise is the selected option.
   
   The only other piece of information needed is the first user who is installed. The username can be Administrator, but Vmware Player will throw back a warning. Windows 2008 doesn’t treat the Administrator account the same as previous operating systems. To perform most administrative functions, we still have to elevate the credentials. The user name is invurted and a password of P@ssw0rd to meet complexity requirements.
5. Now we apply the name and location of the virtual machine. This is where the space requirement comes in. By default, Vmware Player saves the virtual machine files to the current user’s directory. Both the name and the save location can be changed at this point. A recommendation would be make sure the volume that you are saving the virtual machines to has enough space for all the hard disks that will be created.
   
6. The next step is to configure the virtual hard disk. In the physical world this would be the hard disk used as an installation target for Windows. It’s exactly the same in the virtual machine. The main difference is that the size represents the maximum size that the “physical” hard drive will be reported as to the Windows operating system.
   
   As this server will only provide domain controller and networking services for the lab environment, it’s been configured as a 20GB hard drive. In the real world, we would attach a second virtual hard drive of larger size that would store all of the application data, leaving the operating system with a volume all to itself.
7. Almost there!
   
   We have our final configuration ready to go. Before powering on the virtual machine for the first time, we need to customise the virtual machine.
   
   The networking configuration is the one major limitation of Vmware Player. Vmware Workstation has a lot more configuration options available.
   The three options are:
   • Bridged – the virtual machine will use an available physical adapter for the virtual machine. This will appear on the network as a separate device from the host operating system. As out virtual machine will be a domain controller, we don’t want to expose it to the real, potentially production, nework.
     DO NOT use a bridged adapter unless you are absolutley certain it is required.
   • NAT – the virtual machine will use the same IP address assigned to a physical adapter. Both the virtual machine and the host OS will appear on the network as the “same” device.
     DO NOT use a bridged adapter unless you are absolutley certain it is required.
   • Host only – This will create a software based virtual switch that virtual machines will be plugged into. The virtual machine will have no network connectivity unless a virutal routing device is created. This is the safest option as it removes the ability for our test lab to interfere with the real, production network.
8. As the machine powers up for the first time, we should see the familiar Windows starting screen. If at this point you don’t see it, check that the CDROM or ISO file is properly mounted.
   
   We need to mount the CDROM or ISO file through this interface.
   
   Once this is done, press CTRL+ALT+INSERT to force a reset of the virtual machine. If you hit CTRL+ALT+DELETE, this will open up the option to get to the task manager of the host operating system.
9. Go and get a cup of tea, sit back and relax because Windows 2008 is installing and there’s very little required at this point.
   
   Once Windows has finished installing, we should be presented with this screen. From this point on, there is no difference between the virual machine and a real version of Windows 2008.
   Power off the virtual machine and move onto Part 2!

That’s Part 1 complete. In Part 2 we’ll look at configuring the virtual machine as a domain controller and deploying additional servers for the rest of the lab.

As ever, if you have any questions, please email me (contactme [at] invurted dot com).

Vmware View is the virtual desktop infrastructure offering from Vmware. The current version is 4.5.

The object of virtualising my desktop include

• Replace outdated unreliable hardware
• Increase overall system performance
• Increase overall system performance
• Reduce ongoing Power consumption and Cooling requirements
• Built a “Green IT” focused IT environment
• Reduce time & costs associated with purchase / management and support Desktop PC’s

Effectively, I am able to achieve many, if not all, of these goals by turning my user workstations into virtual machines! By replacing my client workstation with thin clients, I can extend the life of the hardware or even re-purpose the old hardware I have.

VMware View is well suited to large environments where traditional Desktop imaging such as Ghost, are no longer viable due to numerous restraints. It simplifies management of desktops and enables quick and easy deployment of new applications.

A VMware view “Thin provisioned” virtual machine performance is higher than a standard virtual machine as the snapshot of the master image will remain in the SAN’s cache due to its high utilization. This speed’s up performance as all requests are returned by cache and don’t need to access the physical disk which generates I/O load on the SAN.

The ability to utilize existing desktops and/or thin clients means a migration to VMware View is quick and easy. Once the older desktops are replaced with Thin Clients the lifespan of the equipment dramatically increases as there are no moving parts. The cost saving of a VMware View environment also extends to power savings as a typical Thin Clients uses far less power than a desktop PC.

A VMware capacity planner audit of the existing desktop pc’s will be required to get an accurate number of required ESX hosts for the VMware view environment. As a guide typically you’ll see ~50 medium use virtual desktops per HP DL380 (or equivalent) ESX Host. Depending on the number of concurrent users and applications used this number can vary.

Although additional ESX hosts will be required if VMware View was utilized across the organisation the SAN disks and configuration is designed to support a full VMware View environment.

As I mentioned elsewhere, the technology underlying View is remarkably simple. At its core there is my existing virtual infrastructure running Vmware ESX, some shared storage and a few minor network tweaks. After that, all I need are:

• VMware View manager “Connection Server”
  The server used to connect the VMware View Client to the virtual desktops entitled to the user/s
• VMware View manager “Security Server”
  A server to be placed in the DMZ, for remote users to connect to for secure access to the VMware view environment
• Virtual Desktops
  A Virtual machine running a Desktop operating system with VMware View Agent installed to enable all VMware View features.

As you can see below:

It shows the “Fat Client”, “Thin client” and “Diskless PC’s” connected directly to the View manager server while within the Local area network or Private -Area network.

The example also shows a “Mobile / Remote user” connecting securely via a View Manager Security server in the DMZ and through the Connection server to the centralized virtual desktops.

And that’s about it! The security server acts as a front end for my clients from external sources, thereby avoiding potentially dangerous access directly to the Connection Server (or Broker) that controls the connection to the virtual machines.

There is, of course, more to it than this. However, for the moment, the basic structure is a good starting point.

And of course, all the machines required for VDI virtualise brilliantly!

Does Vmware have Microsoft Vista properties? You know, we’ll just chuck it in at the end and pray it works.

Frantic calls to and from on Saturday night lead myself and a friend to the question, “What the hell is up with iSCSI?”

It seems that the initiator works only with a service console. In fact, the observed results showed that iSCSI was being run with the Service Console’s IP address DESPITE have a vmkernel port configured in the same networks as the iSCSI target.

Well, this is not entirely true. Vmware needs a Service Console to do the initial CHAP authentication and establishment and only then does it switch over to the configured vmkernel interface.

Why even bother with an iSCSI “interface” (vmkernel port0 if you’re going to initiate with the Service Console? In fact, more to the point, why does it split the authentication and actual iSCSI traffic across them.

Based on various forum posts, it sounds like iSCSI was a last minute throw in by VMware, and just not done completely right.

Hence, Vmware Vista.

REF: my mobile phone log with the lingfish and http://communities.vmware.com/thread/209361

Templates and their usage are one of the big time savers in ESX. The ability to setup a “perfect” vritual machine and then deploy multiple copies of it allows us to minimise the risk of deployment errors. However, there are a few limits around what can be achieved.

Specifically, in the environment I am in at the moment, there is a requirement for the operating system to be deployed to one LUN and the any application partitons to be deployed to another LUN.

Templates only allow me to deploy the machine’s virtual hard disk to one LUN and not split across two. Hence the problem.

There is no quick fix that I could find; so it was off the scripting land I went.

First things first. The customer required the deployment of twenty seven virtual machines all based off one. The process is prety simple; open my Virtual Infrastructure Client, point it at a Virtual Center (ESX servers by themselves don’t have template functionality), and convert the baseline virtual machine to a template.

I could have chosen to deploy twenty seven virtual machines manually, but, well, I’m lazy. So, the lazy man’s solution? Scripting!

The process was as follows:

1) Remove the 40GB hard drive (cloning and templating doesn’t allow hard drives to be placed in multiple datastores eg. osLUN and appLUN)
2) Create a template of the virtual machine.
3) Install powershell and the Vmware VI Toolkit giving us the powershell for Vmware functionality.
4) Save the following to a .ps1 (Powershell script file):

$array = “Machine1″,”Machine2″,”Machine3″ (and so forth)
$TARGET = “FQDN_OF_TARGET_ESX_SERVER”

Connect-viserver FQDN_OF_VIRTUAL_CENTER

foreach ($vm in $array)
{
$vm=New-VM -Name $vm -Template BASELINE_TEMPLATE -Host $TARGET -Datastore osLUN
}

The above script will connect to the VI Center (it will prompt for username and password) and then create a new machine called “Machine1″ etc. for each machine in the list. It will place the virtual machine on the esx server in $TARGET and build it from the template called BASELINE_TEMPLATE.

Now comes the hard part. There are 27 42GB drives that need to be created for the virtual machines. There is no powershell that will allow this to happen. Therefore, a script is required.

In appLUN is a vmdk called BASELINE_TEMPLATE_VMDK and this is the virtual hard drive (pre partitioned and formatted) that will be used for the virtual machines.

for DESTINATION in machine1 machine2 machine3 machine4 ETC.
do
# Copy
echo “Copying $SOURCE to $DESTINATION”
mkdir $DESTINATION
cp -a $SOURCE/* $DESTINATION/
# Rename vmdk files
cd $DESTINATION
for file in $(ls -1 *.vmdk)
do
echo “Renaming $SOURCE vmdks to $DESTINATION”
DEST=$(echo $file | sed s/$SOURCE/$DESTINATION/g)
mv $file $DEST
done
# Edit .vmdk
for file in $(ls -1 *.vmdk | grep -v flat)
do
echo “Replacing references to $SOURCE in .vmdk file $file”
sed -i s/$SOURCE/$DESTINATION/g $file
done
cd ..
done
echo “Finished”

This will copy the BASELINE_TEMPLATE_VMDK virtual hard drive one time for each virtual machine and make sure it is useable for that machine. It will also go through the .vmdk file and change the reference from BASELINE_TEMPLATE_VMDK to the destination virtual machine name.

Once it is run, we have to manually add the newly created vmdk to the corresponding virtual machine.

Then it is a simple matter of logging into each virtual machine and changing their host names and IP addresses.

There is still a fair bit of manual intervention involved, but at least the boring, tedious bits (deploying the templates and copying the hard drives) has been automated.

If you can offer any other scripts that can complete the picture, let me know!

Whilst researching some storage options for a client, I stumbled across this pretty useful information

1) How often ESX checks for path failure?
==> As soon as an I/O request to a path fails, ESX will initiate a path failover. If there is no I/O outstanding to a path. ESX will probe each physical path every 5 minutes, by default, to proactively detect path failure.

2) How long will ESX wait before trying a different storage path?
==> A different storage path is tried immediately.

3) What happens between the failure detection and the connection recovery?
==> I/O requests will be queued.

4) Under which circumstances will a host initiated target reset or LUN reset occur?
==> Resets are not typically initiated by ESX. Two exceptions to this rule are:
- if a path failure occurs while there is a SCSI-2 reservation outstanding on the failed path
- if the VM or userworld that initiated the I/O request sends a request to abort the outstanding I/O request.

5) Will ESX ever force a LUN trespass in the array?
==> Only in the case of an A/P array when there is no working path on the same SP as the failing path. For example, when using an EMC Clariion (which uses the “trespass” command).

Technically point two needs some work.

ESX SCSI layer has a latency between when the failure occurs and when it will try a different path. This is usually determined by when the device driver returns a failure ie. I/O errors. Supported fibre channel devices will do this inside of thirty seconds. The ESX SCSI layer then has thirty seconds to use another working path. On an active/passive array the activate/trespass/etc command can take a few seconds to complete.

Within a virtual machine, the registry ([HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk]
“TimeoutValue”=dword:000000be) can be configured to wait before issuing an abort for an outstanding I/O. If this key is enabled

ESX states that within this 60 seconds it will:
- detect that a path has failed
- select a new path
- activate the new path
- re-issue the cmd from the guest to the new path
- have the newly issued cmd complete successfully and return to the guest.

Vmware Convertor allows us to P2V (Physical to Virtual) migrations. That is, taking (potentially) a running machine on my network and importing it directly into my virtual infrastructure.

So, whilst vSphere is the new kid on the block, Vmware have also released an updated version to this genuinely brilliant utility!

What’s New
The VMware vCenter Converter Standalone 4.0.1 release is an update to Converter Standalone 4.0, and includes the following new features:

Support for vSphere 4.0 as source and destination targets:
• Support for configuring target disks as thin provisioned disks
• Support creation of IDE disks on vSphere 4.0
• Support for backup products to restore vSphere 4.0 virtual machines backed up using VCB
• Support for creation of virtual hardware version 7.0 virtual machines on vSphere 4.0. targets as well as migration of hardware version 7.0 virtual machines from Workstation and Server platforms to vSphere 4.0
• Support for importing OVF 1.0 single virtual machine images.
• Support for customization of Windows Server 2008 guests.

[email_link]

Vmware’s launch of their new operating system, vSphere (Vmware ESX 4!), is being lauded as the first “cloud operating system”.

The twitter-sphere and the blog-verse is going mad with live reports from Vmware’s announcements.

Specifically, Duncan Epping’s blog has some interesting links: http://www.yellow-bricks.com/2009/04/21/vsphere-linkage/

Also, twitter search for vSphere, or check out Scott Lowe’s blog (http://blog.scottlowe.org/) and also Rick Scherer (http://vmwaretips.com/wp/).

And for an interesting response, Microsoft’s reaction to the announcement: http://darow.wordpress.com/2009/04/21/reactions-to-vmwares-vsphere-4/

It’s a shame I’m stranded here in Australia and can’t attend these events easily!

Greetings, faithful reader,

This one is as much a reminder for me as it is one to you!

When you’re entering Maintenance Mode, the Vmware ESX server will always try to Vmotion all of it’s hosted virtual machines away. Problems can occur when hosts fail to migrate when entering Maintenace Mode. The server will stop at two percent and then time out. Regrettably, there is no notification that an individual Virtual Machine’s Vmotion event fails.

However, there is another cause as well: if your cluster is both HA (High Availability) and DRS (Distributed Resource Scheduling) enabled, when you put an ESX server into Maintenance mode, DRS will generate a five star recommendation. Manual mode, however, requires user interaction and you have to tell the ESX cluster to initiate the Vmotion events. Once I accept the recommendations, Vmotion will start and the target ESX server will be placed in Maintenance Mode.

There is one other case where it will fail. This one falls into the category of “undocumented system feature”. The summary is:

From: http://kb.vmware.com/selfservice/viewContent.do?externalId=1007156&sliceId=1

• An ESX host fails to enter maintenance mode in a VMware High Availability (HA) or DRS cluster
• Hosts fail to migrate when attempting to enter maintenance mode
• The progress indicator remains at 2% indefinitely
• Trying to remediate a host and getting a time out error when trying to enter the maintenance mode

Cause:
This is normal behavior for a VMware HA/DRS cluster that is using strict admission control.

Disabling strict admission control (allowing virtual machines to power on even if they violate constraints) should allow a host to enter maintenance mode in this situation but a bug was discovered whereby it did not.
Resolution:

For a permanent solution, upgrade to VirtualCenter 2.5 Update 3.

To workaround the issue, temporarily disable VMware HA in the cluster settings. You will then be able to put the ESX Server host into Maintence mode and do the work required. You can then re-enable HA on your cluster.

This one is getting filed under “Try it really soon!” However, randomly answering an email, I came across this document on http://www.vminfo.nl detailing the process for making a bootable USB key with ESX 3i installed.

Certainly, the document goes into a lot more detailed instructions, but here’s a bit of a summary:

1. Using an archiving program eg. IZArc, extract the contents of the Vmware ESX 3i ISO image. Given it’s an ISO, you could also mount it using DaemonTools or it’s like.
2. Once the files are extracted, find the INSTALL.TGZ file and open it.
3. Navigate to the \usr\lib\vmware\installer directory.
4. Open the Vmware-VMvisor-big-3.5.0_Update_2-11072.i386.dd.bz2 file. This may take a while, so patience, young padawan! Then extract the un-compressed .dd file
5. Restore the boot image to the USB thumb drive. Effectively, you’re restoring a “virtual hard drive” (in this case the .dd file extracted above.
6. Now that’s done, it’s time to test! Boot the sucker and play with ESX 3i!

The only real “gotcha” in this one is pretty obvious: make sure you have a motherboard that can boot from USB. Thankfully, these days most new motherboards have this ability. If in doubt check your motherboard manual or the manufacturer’s website.

Regrettably, I don’t have a font big enough OR bold enough to stress that this is UNSUPPORTED IN A PRODUCTION ENVIRONMENT!! Try it at your own risk!

ESX 3i on USB