Showing posts with label vmware. Show all posts
Showing posts with label vmware. Show all posts

Tuesday, 26 March 2013

Join Domain Workflow for Orchestrator

Hi There

Well finally getting to the pointy end here. VMware broke the sysprep process in version 5.1 such that a guest would not join the domain. So for my environment I needed to create a workflow that did this process for me.

The workflow shown here can be used within a larger workflow to provision a Windows guest.

So you need to have prepared your Template as stated in here.

You need to have created a similar script as stated here to join the guest to the domain.

Then you need to configure your workflow like this:

joinDomain workflow
So the first section highlighted in yellow basically checks for the existence of powershell directories on your guest. It first checks for c:\windows\system32\windowspowershell\v2.0 if found, sets the path for version 2 of powershell. If the check fails, it checks for c:\windows\system32\windowspowershell\v1.0 if found, sets the path for version 1 of powershell. If the check fails, it sets the error status and exits.

The second section highlighted in green checks the workingDirectory (c:\bin) exists. If not found Exits (probably should set the error state). If it is found, it then copies the script joinDomain.ps1 to the workingDirectory. If the copy fails, Exits (probably should set the error state on this too). If the copy is successful, then continue.

The third section highlighted in light blue, gets the environment variables from the server, then executes the joinDomain.ps1 script on the guest. It then wait until there is a return code for that process to finish. It then checks to see if the process exited successfully. If it did not exit with return code 0 then the script Exits (hmmm need to set the error state here). If it did exit with return code 0 then waits for the fully qualified name of the server to show up in vmtools. Sets the error code to success and exits.

I have included the documentation for this workflow here. All sub workflows are default library workflows found in Orchestrator.

Hope this helps.

Setting Power Shell Execute Modes in VM Guest Templates

Hi

Well I am slightly restructuring my posts into smaller bite sized chunks. Why? well because I wanted to re-use bits and well the easiest way to make sense was to post about smaller bits of information.

So today I am going to talk about Power Shell Execute Modes. Well not so much about them but how I have set mine up in my VMware environment to enable easy execution of scripts in my environment.

Okay so I am sure most people who use VMware know about templates so will reference this as assumed knowledge.

In my environment I currently have 3 Templates, SUSE Linux Enterprise Server 11 Service Pack 1, Windows Server 2008 R2 and Windows Server 2012.

For the Windows Servers, I set the execution policy as unrestricted both in the 64Bit and 32Bit shells.

Why? So that I don't have to sign all my scripts. Is this an issue, from my experience only if you are operating in a highly secure environment.

So how is this done? Simple:

Open each console on the Template and type:

set-executionpolicy Unrestricted
You should see something like the following


Once your done, shutdown the machine and convert back to a template and we are ready.

Well I am off now, see you in the next snippet.


Tuesday, 4 October 2011

VCP5

Ok, so I haven't made a single post since January. Nice! What a waste of a blog, yeah? Probably. Never the less, here we are again, with more VMware certification related happiness; I just sat and passed the VCP5 certification exam. I wouldn't say there was a comfortable margin involved, not as compared with my VCAP-DCD attempt, but a pass is a pass, and now I know where the gaps in my knowledge are so I can stuff them full of new knowledge.

My experience with the VCP510 exam is as follows:

It's a good exam. To my mind, a harder exam than the VCP410 that proceeded it. As VMware add new features and new complimentary products (like the vCenter Server Appliance (vCSA), VMware Storage Appliance (VSA), and the Auto Deploy magic) it stands to reason that the exam is going to cover more bases and a broader, yet just as deep, understanding is needed to look after the VMware farms of today, let alone to pass the exam.

If you ask me, and you implicitly have, the VCP510 blueprint doesn't tell the whole story. If you knew exactly, and only, the knowledge points on the blueprint you'd fail. Of course, in the real world, if you know the knowledge points on the blueprint, chances are you know the detail that fills the spaces in between too.

Me? I needed to know more about SIOC and NIOC.

Spend some quality time in esxtop. Know the PowerCLI, vCLI and the ESXi shell. Storage DRS was a big one, and vDR showed up more than I expected. Know your constraints for HA, DRS, FT, SDRS, etc. etc.

But everyone's exam will probably be different.

I got a 367, and I'm not happy about it.

Of course it'll help if you've been living and breathing vSphere 5 for a while. My clusters are still 4.1 :)

Wednesday, 12 January 2011

I passed!

Against all odds (well, not really, but certainly against expectation), I passed the VCAP-DCD beta exam with a score in the low 400s.

This is good news! It also means I have to get my act together and start studying up for the VCAP-DCA, which was supposed to be the point of this blog in the first place.

Friday, 12 November 2010

VCAP recap

Yesterday was the big day. I spent more of my day on the train into central London than I did in the exam suite, but only just! The beta exam clocked in at just under 4 hours as they threw more questions at us than you're likely to get in the shipping version of the exam.

And it was tough, too. Two weeks of cramming isn't enough time to get it all down. They're testing knowledge of a lot of subjects across technical, design, and project arenas with a broad mixture of highly conceptual and disturbingly specific questions. Not surprisingly it's all covered in the official exam blueprint, and studying the recommended reading from the blueprint will prepare you for the exam, but in much the same way that reading the entire unabridged edition of the Encyclopaedia Britannica will prepare you for the local pub quiz. There's no substitute for experience here, and my lack of experience with large design projects was a handicap. But I was expecting that.

The beta exam allowed for less than 2 minutes per question which put the pressure on, especially when there were certain classes of interactive question that demanded 5-10 minutes each. Since you have no idea what types of questions are coming, time management is very difficult, particularly towards the end. Do I rush through these multiple choice questions just in case there's a big one coming up, or take a more considered approach and risk running out of time? I went for the former and actually ended up with 8 minutes in hand at the end. It made me feel like I'd chosen wrong.

Frequently I found there wasn't enough space on the screen for the question. It was frustrating to have to answer questions against a scenario when the scenario ran off the right-hand edge of the screen. Worse were the interactive questions that didn't leave enough space on the screen to create an answer. I don't know if this is a general problem or if the testing centre I visited were just running too low a screen resolution. There were a lot of basic proof-reading and clarity of meaning issues.

I doubt it will matter though. I fully expect the exam grade will be based on a weighted sum across different subject areas and a fail in, say, the projecty bit won't make up for good performance in, say, a logical designy bit. On balance, I'm expecting a fail because of my performance on a couple of sections that I just don't have enough background in to feel confident in.

The afterward made it sound like only those who passed would be contacted once VMware had had time to collate and review all the beta test scores, so I may never know just how badly I've done :)

Tuesday, 26 October 2010

VCAP DCD Exam Beta

Last week I unexpectedly received, from VMware, an invitation to sit the beta VCAP4 Datacentre Design exam. It comes at a discount rate, but with an obligation to provide feedback on the exam itself.

From the wording of the email it seems anyone with a VCP4 is eligible to sit the beta exam, so I'm not sure if I won a lottery for this or if everyone's had an invitation.

Whatever the cause, I've booked myself in for the 11th of November, and will be spending most nights between now and then with a copy of the exam blueprint and a stern resolve.

Saturday, 7 August 2010

Building an ESXi provisioning environment: Part 1

There are three things I knew I was going to need to build my provisioning environment:
  • A DHCP server
  • A TFTP server
  • An FTP or web server
The DHCP server should be obvious. I need my hosts to auto-configure their network awareness, and they need to know where to pick up the PXE image they're going to use to bootstrap the ESXi install process.

The TFTP server is going to provide the PXE boot image and ESXi bootstrap files.

The FTP or web server is the repository from which the ESXi installable image, kickstart script (ESXi install script), and post-install configure/build scripts are going to come from.

As far as I'm concerned, the quickest and least resource intensive way to achieve all three is to knock up a small Linux box. I chose Debian.

The DHCP server is of the ISC variety and is provided by the dhcp3-server package.

I went with the tftpd-hpa package, but any TFTP server will work for this - I'm not using any interesting features.

I opted for a web server over an FTP repository for my install media as it lends itself to a configuration script repository better than FTP. Apache's httpd server is my weapon of choice and Debian puts it in the apache2 package.

The PXE boot environment files we need come from the syslinux-common package. You'll need that too.

Install with:

vm-sys-cfg:~# apt-get install dhcp3-server tftpd-hpa apache2 syslinux-common

I've configured my host with the IP address of 10.0.0.1/24, which sets the scene for my DHCP server configuration.

My basic dhcpd configuration is:

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.201 10.0.0.210;
}


I'm not expecting to be building more than ten hosts at once, but it's easy to extend anyway.

The next part is the PXE, or in this case gPXE configuration. Now I used the ESXi 4.1 setup guide to, er, guide me on the next part as I'd never heard of gPXE before now. Unfortunately, the VMware setup guide's gPXE example is poorly explained. They spend a lot of time talking about how great gPXE is because you can boot from HTTP or FTP (or iSCSI, or ATA-over-Ethernet, or whatever) but their guide will set you up to boot from TFTP, just like a regular PXE stack, so what's the point?

The VMware guide includes:

option space gpxe;
option gpxe-encap-opts code 175 = encapsulate gpxe;
option gpxe.bus-id code 177 = string;

class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
next-server 10.0.0.1;
if not exists gpxe.bus-id {
filename "/srv/tftp/gpxelinux.0";
}
}


In a nutshell this defines a DHCP user class called "pxeclients" based on whether or not the vendor-class-identifier client identifier option contains the string "PXEClient" in its first nine characters. Not surprisingly, the PXE ROM in your network card does announce this.

So inside this class we can specify options and configuration that only apply to PXE clients. I've given the IP address of my Linux host as the next-server option. That's where the PXE client looks for its boot files. The next bit:

if not exists gpxe.bus-id {
filename "/gpxelinux.0";
}


basically says: if you've not identified yourself as a gPXE client, retrieve and load the /gpxelinux.0 image.

tftpd-hpa uses /var/lib/tftpboot as its root directory. Put /usr/lib/syslinux/gpxelinux.0 in there. i.e.

vm-sys-cfg:~# find /var/lib/tftpboot/
/var/lib/tftpboot/
/var/lib/tftpboot/gpxelinux.0


Cool. But what about if you are a gPXE client? Then you'll try and pull down your configuration file based on where you came from: TFTP. I want to use HTTP as my boot protocol from this point. So I've changed that stanza to read:

if not exists gpxe.bus-id {
filename "/gpxelinux.0";
} else {
filename "http://10.0.0.1/";
}


Now everything that gPXE does from this point will be relative to http://10.0.0.1/, which means I've got to set up my web server file tree.

My apache document root contains this file structure:

vm-sys-cfg:~# cd /var/www
vm-sys-cfg:/var/www# find
.
./index.html
./cfg
./cfg/cfg-00:0c:29:f2:55:a7.sh
./dist
./dist/imagedd.md5
./dist/imagedd.bz2
./ks
./ks/ks.cfg
./boot
./boot/vmkboot.gz
./boot/vmkernel.gz
./boot/ienviron.vgz
./boot/cim.vgz
./boot/sys.vgz
./boot/install.vgz
./boot/mboot.c32
./boot/menu.c32
./pxelinux.cfg
./pxelinux.cfg/default
./gpxelinux.0


The ./pxelinux.cfg/default file will be pulled down by the gPXE image. Mine's been ripped pretty much straight out of the VMware manual:

default 1
prompt 1
menu title VMware VMvisor Boot Menu
timeout 50

label 1
kernel boot/mboot.c32
append boot/vmkboot.gz ks=http://10.0.0.1/ks/ks.cfg --- boot/vmkernel.gz 
--- boot/sys.vgz --- boot/cim.vgz --- boot/ienviron.vgz --- boot/install.vgz

label 0
localboot 0x80


(Keep the append directive on a single line)

It gives me two options. I can either boot into the ESXi installer (label 1), or boot from the local disk (label 0). The default is the ESXi installer which will be invoked automatically after 50 seconds. Cool.

Everything in my ./boot directory came off the root of the ESXi install CD, as did the ./dist/imagedd.bz2 and ./dist/imagedd.md5 files. I could have just dumped everything in the root of /var/www but this way is neater.

The last part of the magic is the kickstart script referenced by the ks=http://10.0.0.1/ks/ks.cfg part of my PXE boot line.

For now, I've used:

# Accept the VMware End User License Agreement
vmaccepteula

# Set the root password for the DCUI and Tech Support Mode
rootpw p4ssw0rd

# Erase partition table on first local disk
clearpart --firstdisk=local --overwritevmfs

# Choose the first discovered disk to install onto
autopart --firstdisk --overwritevmfs

# The installation media is in the CD-ROM drive
install url http://10.0.0.1/dist/

# Set the network to DHCP on the first network adapater
network --bootproto=dhcp --device=vmnic0 --addvmportgroup=0


The install url http://10.0.0.1/dist/ directive says to perform the install from my website.

And there we go. Everything you need to automatically build an army of basic ESXi servers. The resulting ESXi servers will use DHCP for their default vmkernel adapter.

Next time I'll cover my lab DNS setup and automatically deploying a basic per-host configuration on my freshly built ESXi systems using the %firstboot kickstart section.

VCAP and building an ESXi provisioning environment

So I'm starting down the VMware VCAP road, and I want to be thorough about it, because I've read the first hand reports of people who've sat the VCAP Datacenter Administration beta exam and it sounds tough.

Being thorough means a painstaking walk through the exam blueprint. And there's going to be lots to learn as the VCAP isn't just about basic vCenter and the vSphere hypervisor any more, and that means spending time with Orchestrator, vShield Zones, the PowerCLI and much more besides; stuff which I haven't had a need to explore up to now.

But the best place for me to start is with ESXi 4.1, or as it now seems to be called (according to the download), VMvisor. Partly this is because up to now all of my VMware hypervisor work has been with ESX, console operating system and all, and that's for historical reasons (I've been doing this since before ESXi existed). But mostly it's because vSphere 4.1 is the last time we'll see the ESX service console as all future versions will be ESXi only.

Now, in the interests of making life easy for myself, I've built a simple provisioning environment to take advantage of the new scripted install mode in ESXi 4.1. This means I can have a central repository of build and configure scripts and spin up an arbitrarily complex ESXi test lab at the push of a couple of PXE-capable network-card buttons. This is a Good Thing™ because each task/step in the exam blueprint isn't necessarily going to be feature-compatible with the preceding or subsequent steps so being able to tear down and rebuild a lab repeatably and consistently is going to prove essential.

I'm building my ESXi lab on top of ESXi itself. Each 4GB physical host will house at least two 2GB ESXi systems. I'm doing that because it lets me take advantage of memory over-provisioning since I don't have the budget for more than 4GB per host, and I can have as many virtual network cards per virtual-ESXi as I need. Throw in a few Linux VMs as routers and I've got a WAN in a box as well. There'll be more about the lab architecture later.

The test lab doesn't have to be fast, it just has to work - so I don't mind so much if I end up swapping with the virtual-ESXi guests.

Anyway, that's the precis. The build environment comes next.