Posts Tagged ‘HOWTO’

PowerCLI Mastery, Volume 3

February 9, 2009

Phew, Volume 1 and Volume 2 down, lets wrap this monster up. See, I told you I wasn’t going to leave you hanging for weeks to nail through all this.

So, picking up right from where we left off. We need to perform a configuration operation on an ESX host. Of the available properties we’re looking at now, which is most likely to tell us what we can configure? That’s right, the configManager property! If you guessed “config”, you were close – the config property tells us _what_ the current configuration values are. The configManager object tells _how_ we can do the configuring (is that even a word?). Lets click on that.

Now we’re cookin! AS you can see at the top of the page, the configManager object is a Data Object of Type ‘HostConfigManager’, the properties of which contain a whole bunch of Managed Objects. (more…)


PowerCLI Mastery, Volume 2

February 9, 2009

Thought I was going to drag this out in some scandalous attempt to keep the viewers coming back week after week? Actually, wish I had thought of that before just now. Anyways, let’s continue. If you haven’t read Volume 1 in the series, go do so now. I’ll wait for you.

So continuing on, let’s use the MOB to find a portgroup, and see if that helps us to know what we need to do. The MOB displays the internal object names for things rather than the display name you see in the VI client (the display name is still in there, but it’s usually a property of an object rather than the name of the object itself). If it makes navigation easier, open up the VI Client as well so you can see what internal object names map to which display names. (more…)

PowerCLI Mastery, Volume 1

February 9, 2009

OK, this one has been a looooooooooong time coming. I’ve been meaning to take a shot at conveying the advanced features of the VI SDK as applied to PowerShell for quite some time now. When Carter corrected me some months ago with regards to what is and isn’t possible with PowerCLI (in the first statelesx video, about 1 minute in I mistakenly suggested there was something it _couldn’t_ do :-), I’ve thought I really should get this info out there. Whether I will succeed in this post and the ones that follow is of course for you to decide (this is way to long for a single post), but I’m going to take you through what I think is the fastest way to get your head around the _entire_ SDK. That’s right, the whole fucking thing. For as you will see, when you conquer a small piece of the SDK, the rest falls like dominoes. (more…)

Statelesx Initiator Script

August 10, 2008

In all our anxiousness to get the statelesx 1.0.0 appliance out, we totally forgot to post up the client initiator script! So here it is:

import socket
import sys
import re
#Open esx.conf, read only
esxconf = open(“/etc/vmware/esx.conf”, “r”)
#Define regular expressions
getUUID = re.compile (“/system/uuid.=.(.*)”)
#Search esx.conf for matches
for line in esxconf.readlines():
        UUID = getUUID.findall(line)
        for uuid in UUID:
                uuid = uuid.strip(‘”‘)
#Close esx.conf
#Define statelesx server address (from argument), port and msg
host = sys.argv[1]
port = 1974
msg = uuid
#Open socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
#Connect socket
#Send msg
print “Sending ” + msg
# Close socket

Just drop that onto your fat ESX 3.5 box and run it as one of the last startup scripts.

PowerShell – Create X Number of VM's per Datastore

July 23, 2008

We all love the ‘shell, and the VI Toolkit for Windows even more. When i finish up with some other stuff, I’ll surely be pointing my C# skills at some cmdlets for that.

Anyway, there are a load of “create VM” scripts out there, I thought I’d show you one with a useful twist – create a certain number of sequentially numbered VM’s per datastore. For those new to the way of the ‘Shell, # is a comment (unlike batch or vbscript)

$esx = Get-VMHost -Name
$template = Get-Template -name TEMPLATE-NAME
$x = 1

#loop through all datastores on host
foreach ($d in Get-Datastore -vmhost $esx)

#check that it’s not a local datastore
if (!($ -match “:”))
#loop to create 10 VM’s per datastore
for ($i=$x; $i -lt ($x + 10); $i++)
#append a number to VM name
$vmname = “VM” + “$i”;
#create the VM from template
New-VM -Name $vmname -Template $template -Datastore $d -Host $esx
#set $x to the next number in sequence for the next datastore
$x = $i

There you have it. The only caveat is that the datastores don’t get returned by name so if you have sequentially numbered datatstores and want the VM numbers to match (ie VM1 – VM10 on ‘datastore 1’, VM11 – VM20 on ‘datastore 2’), you’ll need to pump the datastores into an array and -sort it first or something. I’ll leave the intrepid reader to handle that if required πŸ™‚

How a stateless ESXi infrastructure might work

May 18, 2008

Yep, it’s Sunday afternoon, and thus time for another installment of Sunday Afternoon Architecture and Philosophy! Advance Warning: Get your reading specs, this post is a big ‘un.

I’ve mused several times on the whole stateless thing, especially with regards to ESXi, today I’m going to take it a bit further in the hope that someone out there from VMware may actually be reading (besides JT from Communities :-).

Previously I’ve showed how you can PXE boot ESXi. While completely unsupported, it at least lends itself to some interesting possibilities, as with ESXi, VMware are uniquely positioned to offer such a capability. The Xen hypervisor may be 50,000 lines of code but it’s useless without that bloated Dom0 sitting on top of it. Check out the video (if you can be bothered to register, are they so desparate for sales leads that you need to register to watch a video???) of the XenServer “embedded” product – it still requires going though what is essentially a full Linux install, except instead of reading from a CD and installing to a hard drive it’s all on a flash device attached the mainboard. But i digress…

So lets start at the top, and take a stroll through how you might string this ESXi stateless infrastructure together in your everyday enterprise. And I’ll say upfront, I’m a Microsoft guy so a lot of the options in here are Microsoft centric. In my defense however, every enterprise runs Active Directory and it’s easy to leverage some peripheral Windows technologies for what we want to achieve.

First up, the TFTP server. RIS (or WDS) is not entirely necessary for what we want to do – a simple ol TFTP server will do, even the one you can freely install from a Windows CD. In this example we’ll use good ol’ pxelinux, so our bootfilename will be ‘pxelinux.0’ and that file will be in the root of the TFTP server. The directory structure TFTP root could be something as follows:

In the TFTP root pictured above I have 3 directories named after the ESXi build. The ‘default’ file in the pxelinx.cfg directory presents a menu so I can select which kernel to boot. I could also have a file in the pxelinux.cfg directory named after the GUID of the client, which would allow me to specify which kernel to boot for a particular client.

If you already have RIS / WDS in your environment, things are a little less clunky… can simply create a machine account in AD, enter the GUID of the box when prompted and then set the ‘netbootMachineFilePath’ attribute on computer object to the file on the RIS box that you want to boot.

Onto DHCP. Options 66 (TFTP server hostname) and 67 (bootfile name) need to be configured for the relevant scope. DHCP reservations for the ESXi boxen could also be considered a pre-requisite. The ESXi startup scripts do a nice job of picking that up and handling it accordingly.

So all this stuff is possible today (albeit unsupported). If ESXi doesn’t have a filesystem for scratch space, it simply uses an additional 512MB of RAM for it’s scratch – hardly a big overhead in comparison to the flexibility PXE gives you. Booting of an embedded USB device is cool, but having a single centralised image is way cooler. As you can see, there’s nothing stopping you from keeping multiple build versions on the TFTP server, making rollbacks a snap. With this in place, you are halfway to a stateless infrastructure. New ESXi boxes can be provisioned almost as fast as they can be booted.

After booting, they need to be configured though… and that’s where we move onto theory…

The biggest roadblock by far in making this truly stateless, is the lack of state management. There’s no reason why VirtualCenter couldn’t perform this function. But there’s other stuff that would need to change too in order to support it. For example, something like the following might enable a fully functioning stateless infrastructure:

1) Move the VirtualCenter configuration store to Lightweight Directory Services (what used to be called ADAM), allowing VirtualCenter to become a federated, mutli-master application like Active Directory. The VMware Desktop Manager team are already aware that lightweght directory services make a _much_ better configuration store than SQL Server does. SQL Server would still be needed for performance data, but the recommendation for enterprises these days is to have SQL Server on a separate host anyway.

2) Enhance VirtualCenter so that you can define configurations on a cluster-wide basis. VirtualCenter would then just have to track which hosts belonged to what cluster. XenServer kind of works this way currently – as soon as you join a XenServer host to a cluster, the configurations from the other hosts are replicated to it so you don’t have to do anything further on the host in order to start moving workloads onto it. This is probably the only thing XenServer does _way_ better than VI3 currently. Let’s be honest – in the enterprise, the atomic unit of computing resource is the cluster these days, not the individual host. Additionally, configuration information could be further defined at a resource pool or vmfolder level.

3) Use SRV records to allow clients to locate VirtualCenter hosts (ie the Virtual Infrastructure Management service). Modify the startup process of ESXi so that it sends out a query for this SRV record everytime it boots.

4) Regardless of which VirtualCenter the ESXi box hit, since it would be federated it can tell the ESXi box which VirtualCenter host is closest to it. The ESXi box would then connect to this closest VC, and ask for configuration information.

By now all the Windows people reading this are thinking “Hmmm, something about that sounds all too familiar”. And they’d be right – Windows domains work almost exactly in this way.

SRV records are used to allow clients to locate kerberos and LDAP services, ie Domain Controllers. The closest Domain Controller to the client is identified during the logon process (or from cache), and the client authenticates to this Domain Controller and pulls down configuration information (ie user profile and homedrive paths, group membership information for the user and machine accounts, Group Policy, logon scripts etc). This information is then applied during the logon process, resulting in the user receiving a fully configured environment by the time they logon.

I haven’t had enough of a chance to run SCVMM 2008 and Hyper-V through their paces to see if they operate in this manner. If they don’t, VMware can consider themselves lucky and would do well to get this functionality into the managment layer ASAP (even if it means releasing yet another product with “Manager” in the title :-).

If Microsoft have implmented this kind of functionality however, VMware needs to take notice and respond quickly. Given that the management layer will become more and more important as virtualisation moves into hardware, VMware can’t afford to slip on this front.

Congratulations if you made it this far. Hopefully you’ve enjoyed reading and as always for this kind of post, comments are open!

Get rid of that pesky VMware Tools update notification…

May 14, 2008

I have enough issues with the “VMware Tools out of date” notification appearing in the VI client every time an ESX patch is applied… it’s almost useless information, as generally there are no support issues with running the RTM version of Tools regardless of the patch level of the host.

But even more annoying is the default behaviour of the VI 3.5 version of Tools, which enables a visual notification in the systray (on Windows guests) if an update is available, which is controlled by the checkbox below:

Too bad if you happen to certify particular driver (ie Tools) versions with coporate SOE versions, like every large enterprise on this planet does. And say goodbye to your standards when a bleary eyed admin sees this little yellow exclamation in the systray at 2am and gets the idea that upgrading VMware Tools may solve whatever problem they got woken up for. Hopefully they’ll remember to raise a retrospective change request after some sleep. I won’t even begin to imagine what the curious VDI user might do.

Fire up your registry monitoring tool of choice and clear the checkbox, and you will invariably be directed towards a modification in HKCU, meaning if you want to effect a machine wide change you would need to load the default user hive and mod the value in there, as well as the all users hive.

Good news is that you can more easily control the display on a machine wide basis by modifying the (default) value of ‘HKLM\SOFTWARE\VMware, Inc.\VMware Tools’. Setting it to a DWORD value of 0 is the equivalent of clearing the checkbox (yes i know by default it’s a REG_SZ – just turn it into a DWORD).

For anyone out there even half as lazy as me, copy this into your install script after the tools installer has been run:

REG ADD “HKLM\SOFTWARE\VMware, Inc.\VMware Tools” /V “” /T REG_DWORD /D “0x0” /F

Veeam Backup Install with Remote Database

April 17, 2008

Even with VMware Consolidated Backup and the release of VMware Site Recovery Manager around the corner, there is still a (gaping) hole left by these 2 products – the ability to failover a single guest to a regularly sync’ed and otherwise offline DR partner.

In the physical world there were 2 main reasons to invoke DR for a single node – physical hardware failure, or a configuration error that couldnt be recovered from fast enough. Virtual hardware obviously doesn’t fail however (I know, I know, the underlying host could fail but you’ve all got HA enabled clusters to allow quick recovery from that don’t you!), which leaves us pretty much with the configuration error problem. Whether it be due to OS or application patching, a change request gone pear shaped, rogue developers or administrators, whatever… the probability of a configuration error causing an outage is much greater than that of a datacenter outage (one would hope!). There is definitely a need to offer such a capability, as companies like Platespin (or Novell now I guess), Veeam and Vizioncore know all too well.

Veeam Backup is something I’ve been messing around with lately, and it certainly impresses in a number or areas, like being able to manage the inventories of multiple VirtualCenters and backup / replicate VM’s or ESX host files between them from a single interface. I’m still waiting for someone in this space to eliminate the need for direct ESX host access though, but I digress…

NOTE that the following is pure hackery, and should not be used in production environments!

Anyway, onto the topic of the post. By default, Veeam Backup installs a SQL 2005 Express instance named ‘VEEAM’ on the box. Thankfully, they have built their product with enterprise scalability in mind (rare for a version 1 product from a small relatively new software company), you just need to know how to configure it. Which would be as follows:

1. Extract the files from the Veeam Backup single install binary.

2. Run ‘setuplight.exe’. Make sure you have a generic domain account ready to use for the Veeam Backup service.

3. Go to the install directory, and modify the ‘dbconfig.xml’ file to point to your remote database host and instance.

4. While you’re in the install directory, copy the ‘DBcreate.sql’ file to the remote database host.

5. On the remote database host, create a login for the generic domain account used in step 2.

6. Create a database named ‘VeeamBackup’ and set the owner to be the generic domain account login created in step 5. Dont just grant the login the db_owner role – the login should be directly mapped to the dbo account for the VeeamBackup database.

7. Open up the ‘DBcreate.sql’ file you copied over in step 4, add the following at the start of the file and execute it in Query Analyzer:

USE VeeamBackup

8. Now jump back on the box where Veeam Backup was installed, and fire up the GUI – you’re done!

Video coming soon… in the meantime, go grab the bits and check it out for yourselves!

UPDATE The good folk at Veeam got in touch regarding this post… turns out I inadvertently stumbled upon something they’re planning for a future Enterprise focused release. So don’t deploy this configuration in your production environments just yet, and keep an eye out for the upcoming Enterprise product release. I’ll be sure to run that through its paces too πŸ™‚

VirtualCenter 2.5 Update 1 – Upgrade Process Still Sucks!

April 13, 2008

Well what can I say… the old days, the bad days, the all-or-nothing days – they’re back!

Once again, the VirtualCenter upgrade process is the equivalent of a full uninstall and reinstall. Someone better let the developers of the VMware management tools suite (or at least whoever writes the installers) that VMware are supposed to be an enterprise software company.

I have a video of the process, but until I find that elusive video host that allows resolutions of 800 x 600, I can’t post it up. But the usual caveats apply… here are the main ones:

1. The VirtualCenter service is removed and reinstalled to run under the context of LocalSystem. So for all you ppl who have enterprise class deployments with the database on another host and vpxd running as a domain account in order to use Windows Authentication to the database, you need to reset the service account credentials. I would strongly advise doing this after the VC installer has run but BEFORE proceeding with the database upgrade wizard.

2. The VirtualCenter database user must have sysadmin rights on the entire database server in order for the upgrade the work. Why this is the case is anyone’s guess – a clean install only requires ‘dbo’ rights on the VC database itself. But that isn’t enough for the upgrade.

3. The bug with ADDLOCAL=VPX is still present if you’re doing a clean install. I can’t remember if I logged a bug report for that already, but looks like I need to raise another one. We don’t use WebAccess in my organisation, and given the choice I’d rather not have to install Tomcat on the VC box – it’s just one more bit of software that will require security patches. Might need to log a feature request for an IIS based web console.

The support matrix document still isn’t updated to reflect whether managing ESX 3.5 U1 with VirtualCenter 2.5 GA is a supported configuration. It will be a small consolation if it is, and an absolute disappointment if it is not.

For anyone running VC 2.5 already, it’s not worth upgrading IMHO. The release notes really don’t provide any compelling reason to upgrade unless you’re running a lot of ESXi and want non-experimental HA (which suggests that the HA code has been moved into the VC agent). For anyone doing fresh installs or upgrading from 2.0.x it would be worth going straight to Update 1 though.

Use Passthrough Authentication in VMware SDK Apps

April 8, 2008

It turns out that it was staring me in the face all along… there’s a new method mentioned right inderneath the standard Login() method in the online VMware API reference, called LoginBySSPI().

But using it isn’t quite as straight forward as replacing Login() with LoginBySSPI() on it’s own… you first need to grab a security context via C++ and pass that as an argument to LoginBySSPI(). I can barely read C++, let alone write it, so I need to get my head around the easiest way to use it. When I work that out, I’ll post back a few samples from the VI SDK using LoginBySSPI() instead of Login(). Unless someone like Andrew Kutz happens to read this and expend 0.00001% brain power to provide the answer πŸ™‚

I’ll also be asking VMware when SSPI will be moved out of ‘experimental support’ status… things like VCB could really benefit from it, as could a raft of other 3rd party apps.