Thursday, December 13, 2012

ESXi 3.5 build 207095 to 5.0 current build steps

A client has the free version of ESXi 3.5 using local storage and wanted to move up to a current version of ESXi. I wasn't able to find a one-stop shop that said how to get from A -> E and for a while there I thought I could at least skip 4.0...nope. If you're not using local storage, please do yourself a favor and just do a fresh install.

It's possible that there's a slightly more efficient way to do this, but this was the way I was guaranteed not to loose the local datastore data. was giving me some grief when I was trying to finish this post so I don't have links up to some of the packages. You should be able to search around and find them.

Things you'll need:
- vMA (current version is fine)
- vSphere Client 4.0 with Host Update Utility (here VMware-viclient-all-4.0.0-208111.exe)
- vSphere 4.0 update 1 upgrade package (here
- vSphere 4.0 to 4.1 upgrade package (here
- vSphere 5.0 iso (standard one here VMware-VMvisor-Installer-5.0.0.update02-914586.x86_64.iso)
- vSphere 5.0 current build (here) if needed

Things you might want:
- vSphere 4.0 upgrade guide (here)
- vSphere 4.1 upgrade guide (here)

- SCP the 4.1 patch to your vMA
- SCP the 5.0 patch to the ESXi datastore * 
- Login to vMA
- Make a backup copy of your host config via vMA
vicfg-cfgbackup --server <ESXi-host-ip> --portnumber <port_number> --protocol
<protocol_type> --username username --password <password> -s <backup-filename>
- Check that there's a scratch partition setup on your host via vMA
vicfg-advcfg --server <ESXi-host-ip> --username root -g ScratchConfig.ConfiguredScratchLocation
if not found:
vifs --server <ESXi-host-ip> --username root --mkdir "[datastore1] .locker-esxtest"
vicfg-advcfg --server <> --username root -s /vmfs/volumes/datastore1/.locker-esxtest ScratchConfig.ConfiguredScratchLocation
- Shutdown VMs and put into maintenance mode
vicfg-hostops --server <ESXi-host-ip> --operation enter
- Start up the Host Update Utility, add your host and patch with the 4.0u1 upgrade package.
-- Yeah. 4.0u1. Not current version of 4.0, that gave back an error that it wasn't compatible.
- Wait a bit. I'm not sure what files are created when, but there was a directory called /vmupgrade that was created and then deleted while the HUU stayed at 3%
- One or two reboots. My test ESXi system rebooted at 3% and 34%, prod ESXi only did the reboot at 34%.
- ESXi reboots to 4.0, HUU eventually will say that the upgrade failed when installing packages after the initial base reboot. Do not fret...keep moving.
- You can login via the vSphere Client & test that everything still looks good.
- Log into vMA and run vihostupdate with the 4.1 upgrade against the host.
 vihostupdate --server <ESXi-host-ip> -i -b <zip bundle>
- Reboot again.
- Test again after starting up into 4.1.
- Reboot system and boot to the 5.0 CD.
- The installer will see your current install and happily upgrade.
- And another reboot. I hope your server doesn't have too much memory that it's set to check upon each reboot..
- Back to vMA and run the esxcli command to patch
esxcli software profile update -d <depot url or offline bundle zip file> -p <profile_name>
- Reboot
- Yes, you are done. Luckily, ESXi patches are cumulative so once you're at a major revision you only need to grab the most recent patch.

* If, like me, you've drawn a blank on how to get ssh enabled on ESXi 3.5:
From console: 
- Alt-F1 unsupported
- enter root pw
- vi /etc/inetd.conf -> unhash #ssh
- ps | grep inetd
- kill -HUP <processID>

Tuesday, November 20, 2012

vCSA SSO Secret Active Directory Handshake

The test connection button was working for me with "reuse session" but I was getting "LDAP: error code 8 - 00002028: LdapErr: DSID-0C0901FC, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection" and "Failed to serialize response" when I actually said to use that configuration.

Error messages were in /var/log/vmware/sso/ssoAdminServer.log 

vCSA and working for me:

Primary server URL:
Base DN for users:
<Only the domain, no other DN/OUs> DC=ad,DC=company,DC=com
Domain name:
Base DN for groups:
<same as users>

cert (*.cer) created for me from the FQDN AD/GC server listed in Primary server URL.
(VMware KB pointing to MS KB)

Auth type:
Created a "service account" user to connect.

The client needs the full\user, not shorthand domain to get in.

Saturday, November 10, 2012

vCSA upgrade from 5.0u1b to 5.1a Part II

First time running VMware's vCenter Server Appliance upgrade, it failed miserably because my vCSA was a rsyslog location (initial failure here).

So I waited a bit to try again, and hey look, there's an "a" update to vCenter 5.1 for upgrade bugs!

Here's my basic steps so that I didn't fail again in the upgrade:
  • Stop rsyslog from hosts
  • rm -rf on the contents of /opt/vmware/var/log/remote 
    • Obviously you could copy them to another system if you needed to keep them around, lucky for me this is a dev environment.
  • Export your permission set unless you just let anyone get into your vCSA..
  • Grab new appliance ova, install and set for another IP in the same subnet as the 5.0 appliance 
  • Start up and go through the key exchange under the "upgrade" choice on the 5.1 appliance
  • Because of my previous dumping of tasks/events/history the upgrade took just a few minutes
  • The source 5.0 appliance is powered down and the 5.1 appliance takes over the IP of the original (the root password was duplicated as well, that was nice). I think it rebooted as well. 
  • I needed to reauth to the AD domain (removed old computer account, add this one)
  • My AD permissions were not copied over in the transfer, blank slate with only root access to anything. 
  • I needed to poke Active Directory LDAP settings  to be able to get SSO working and then I could import the custom permission sets and AD groups back into the appliance. 
Whew. Better than last time? Maybe. The fact that the vCSA is *still* a linux VM without NTP running but connected to AD is a big miff for me. I'll save that for the other post I'm dreaming up..

root ssh on vCSA (whoops!)

I'm going to make a post with some hardening and vmware-linux-best-practices-that-vmware-has-not-done of VMware's vCenter Server Appliance (5.1), but only after I stop locking myself out...

If you turn off root ssh before creating another real user in the appliance, do not be alarmed. You can head into the admin web interface and change the setting on the Admin tab (Toggle SSH setting). The Administrator SSH logon enabled will change from no to yes (assuming you haven't locked yourself out of the web admin as well). :)

Oh, and the new skitch sucks.

Friday, November 9, 2012

Export / Import vCenter permissions.

These scripts, written by Alan and LucD, have been invaluable to me. I now have them set to run weekly as backups for production and I can do a manual export for my dev environment if needed (and that's where I've used the import, twice now, with vCSA upgrade issues).
Thank you, Darren for posting them up, and yes! they still work for vSphere 5.1!

I did need to change the domain from the shorthand to longhand version in the xml file importing into 5.1 from 5.0, but this might have been the way I put the domain in SSO.

Drink Up!

vCSA 5.1 SSO LDAP issues

Working with the vSphere vCenter Server Appliance 5.1 (build 880472, the "a" edition) I could not get straight LDAP (not LDAPS) to work for Single Sign On. Was not happening. Not with Anonymous, not with username, not with reuse session. Anonymous was just broken, but it looks like this is by design with current AD and is not recommended (by anyone, anywhere, but if you search for it you can find out how to do it).
Error message is [LDAP: error code 8 - 00002028: LdapErr: DSID-0C0901FC, comment: The server requires binds to turn on integrity checking if SSL\TSL are not already active on the connection, data 0, v1db1].
VMware says "Hey crazy! Get your SSL certs in order!" (Drink the kb here).
I said "That's great VMware, what are my other options?" Turns out I answered my own question year(s) ago!  (Old Koolaid here)

That's right, just turn off the cert requirement:
Computer configuration - Policies - Windows Settings - Security Settings - Local Policies/Security Options - Domain Controller: LDAP server signing requirements (None/Require signing/Undefined[which is the same as None])  -- Change to None

Not as secure, but I could import my users/groups into the new appliance (luckily had a backup) without making other changes (create cert template, export, blah blah) that my local domain admins didn't want to do on a Friday afternoon. 

See updated secret sso cert handshake post for secure settings that worked for me

Pic to show straight (insecure) LDAP settings.
ldap://<fqdn of an active directory server>:389
full domain name
reuse session

The default "Users" OU is listed as a CN. If you point to another root OU in your domain, you would use OU=<blah> instead of CN. You can also screw the CN/OU and pull everything from the domain as well by putting in just the DC parts.

Wednesday, September 26, 2012

powershell security warning

Microsoft being helpful again...

Security Warning
Run only scripts that you trust. While scripts from the Internet can be useful, this script can potentially harm your computer. Do you want to run <script>?
[D] Do not run [R] Run once [S] Suspend (default is "D"):

I thought this was related to the file path that was in the script so I started going down the path of disabling UNC Paths... this wasn't the issue.

  • Right-click the ps1 file and choose properties
  • Hey, hey! There's this obnoxious Security bit here at the bottom of the General tab:
    • This file came from another computer and might be blocked to help protect this computer. [Unblock]
    • Click Unblock
  • OK
  • Get back to work

Friday, September 21, 2012

Raw LUN maximimums

Just an interesting note that is probably no use to anyone.
Back in ESX 3.5 days, I had a workload request for a fileserver with a 6TB disk. Creating a VM with the OS on a VMFS LUN and then assigning a physical compatibility raw LUN of 6TB worked perfectly.

Later, upgrading to ESX 4.0 in that same environment had no issues with the raw 6T VM. This is where the config maximums stated that 2T-512b was the largest pRaw LUN. Shutting down the VM, storage vMotioning the OS to another datastore, all had no issues.

When I upgraded to ESXi 5.0, then we had issues. I wasn't able to vMotion the VM with the 6TB LUN to a 5.0 host in the cluster. We had to pause the upgrade for a week to find possible solutions and a downtime window for the fileserver.

The fix?

Upgrade one of the existing VMFS3 LUNs to VMFS5. Shut down and power up the VM on ESXi 5.0. The config file for the pRaw disk automatically moved to the VMFS5 LUN and the world started turning again.

So a working but unsupported pRaw disk that went well beyond the maximum supported worked perfectly fine up until it was actually supported (under VMFS5) and needed to be massaged before working in 5.0.

I was reminded of all this when checking out the released 5.1 max guide. As much as a pain it was to memorize the key maximums for a VCP exam, knowing them offhand has been invaluable in conversations with new clients.

So, drink up the 5.1 maximums, you new consultants and VCP wannabes: Cheers

Tuesday, September 18, 2012

vCSA upgrade from 5.0u1b to 5.1

First try on upgrading to the new 5.1 appliance and a big fail with a filled destination 5.1 vCSA root partition. (( Upgrade that worked here ))

If you have configured remote syslog on your source appliance, this routes to a /new directory on the destination appliance during the upgrade (not /storage/log). Unlucky for us, VMware choose not to have this /new directory with it's own mount point.

My work around is to create a new 20G drive and mount to /new before starting.

Oh, and take a snapshot BEFORE importing/swapping keys between source and destination vCSAs..

I'll update if I come across any other gotchas.

I've pinged VMware's kb with this, hopefully they'll get something up quickly. As for last night's backup I go. Good thing this isn't production. 

Thursday, September 6, 2012

vCSA DB2 shenanigans before upgrade

My initial post on upgrading the vCenter appliance to 5.0u1b build 804277 gave some good tips that I found around and figured out myself.
But I'll tell you, dear reader, that the upgrade process kept failing for me. Too much db2 export which I narrowed down to tasks & events.

I had set tasks and events to be kept for 180 days (this might be the default). I bumped this down to 30 days hoping that the rows would be deleted and then my upgrade would work again. This didn't seem to happen. So this post is about clearing your embedded db2 database of history stats, tasks and events before upgrade. Note that it doesn't look like anything in the db2 cli is case sensitive.

I should mention that I am *not* a DBA, that this could hose your installation, it will most definitely hose your stats, events and tasks so this process might not be a good idea in your production environment. The vCSA is a VM: Use snapshots to your advantage here.
  • SSH into the appliance as root. Turn off vcenter services:
# service vmware-vpxd stop
  • Change your login to db2inst1, get into the db2 cli, connect to the vCenter database:
# su - db2inst1
~> db2
db2 => connect to VCDB
  • I couldn't remember if I had bumped the transaction logsize on this appliance, so I did the command anyway: 
db2 => update db configuration FOR VCDB USING logprimary 16 logsecond 112 logfilsiz 8192
  • Delete contents of the history tables:
TRUNCATE TABLE vc.vpx_sample_time1 IMMEDIATE
TRUNCATE TABLE vc.vpx_sample_time2 IMMEDIATE
TRUNCATE TABLE vc.vpx_sample_time3 IMMEDIATE
TRUNCATE TABLE vc.vpx_sample_time4 IMMEDIATE
  •  Deleting the contents of the tasks & events is not as straightforward. There are foreign keys associated with these tables that need to be removed before you can delete the rows and then re-create the foreign keys. 
    • See how many rows of data: 
select count(*) from vc.vpx_event
select count(*) from vc.vpx_event_arg
select count(*) from vc.vpx_task
    • Remove foreign keys: 
alter table vc.VPX_EVENT_ARG drop constraint FK_VPX_EVENT_ARG_REF_EVENT
alter table vc.VPX_EVENT_ARG drop constraint FK_VPX_EVENT_ARG_REF_ENTITY
alter table vc.VPX_ENTITY_LAST_EVENT drop constraint FK_VPX_LAST_EVENT_EVENT
alter table vc.VPX_EVENT drop constraint FK_VPX_CHANGE_TAG
alter table vc.VPX_EVENT drop constraint FK_VPX_EVENT_REF_COMPUTERES
alter table vc.VPX_TASK drop constraint FK_PARENT_TASK_REF
alter table vc.VPX_TASK drop constraint FK_VPX_TASK_CHANGE_TAG
alter table vc.VPX_TASK drop constraint FK_VPX_TASK_REF_ENTITY
    • Delete data: 
truncate table vc.VPX_TASK immediate
truncate table vc.VPX_ENTITY_LAST_EVENT immediate
truncate table vc.VPX_EVENT immediate
truncate table vc.VPX_EVENT_ARG immediate
    • Re-add foreign keys: 
alter table vc.VPX_EVENT_ARG add constraint FK_VPX_EVENT_ARG_REF_EVENT foreign key(EVENT_ID) references vc.VPX_EVENT (EVENT_ID) on delete cascade
alter table vc.VPX_EVENT_ARG add constraint FK_VPX_EVENT_ARG_REF_ENTITY foreign key (OBJ_TYPE) references vc.VPX_OBJECT_TYPE (ID)
alter table vc.VPX_ENTITY_LAST_EVENT add constraint FK_VPX_LAST_EVENT_EVENT foreign key(LAST_EVENT_ID) references vc.VPX_EVENT (EVENT_ID) on delete cascade
alter table vc.VPX_EVENT add constraint FK_VPX_CHANGE_TAG foreign key(CHANGE_TAG_ID) references vc.VPX_CHANGE_TAG(CHANGE_TAG_ID) on delete set null
alter table vc.VPX_EVENT add constraint FK_VPX_EVENT_REF_COMPUTERES foreign key(COMPUTERESOURCE_TYPE) references vc.VPX_OBJECT_TYPE(ID)
alter table vc.VPX_TASK add constraint FK_PARENT_TASK_REF foreign key(PARENT_TASK_ID) references vc.VPX_TASK(TASK_ID)
alter table vc.VPX_TASK add constraint FK_VPX_TASK_CHANGE_TAG foreign key(CHANGE_TAG_ID) references vc.VPX_CHANGE_TAG(CHANGE_TAG_ID) on delete set null
alter table vc.VPX_TASK add constraint FK_VPX_TASK_REF_ENTITY foreign key(ENTITY_TYPE) references vc.VPX_OBJECT_TYPE(ID)
    •  Your tables are now empty:
select count(*) from vc.vpx_event
select count(*) from vc.vpx_event_arg
select count(*) from vc.vpx_task
  •  quit from db2 cli, exit from db2inst1 user, restart vcenter services to see if everything powers back up: 
=> quit
~> exit
# service vmware-vpxd start
  •  Log into the vSphere Client to check that everything looks good. 
  • Try your upgrade again. For me, just truncating the history stats still failed after exporting the data for ~18 hours. Yeah. 18 hours and then I had to revert to snap. Dumping the events/tasks was the only way this was ever going to work. 
Thanks to vfrankjuanma and IBM's db2 documentation.

Tuesday, September 4, 2012


As they are currently available. The website is pulling from aws s3 but I can't easily get to the source links. Hopefully it will go back to the setup that I can script when the videos are available.

Drink Me

md5 checksum a07f4590e121798a4cd9273cce3e7dd6

Session number, full title and speakers: the koolaid is so good

Friday, August 31, 2012


Before taking my VCAP-DCD test at VMworld I got a few tips from Jason Boche who was thankfully in the VMware testing lounge area. It might help you: 
  • Go through the test and mark / flag all design questions for review without spending any time on them. Finish the multiple choice and many to many boxes-of-doom questions and save the design questions for last. 
  • For the long scenario multiple choice questions, see if you can answer the question from just the last line or last short paragraph without reading the whole thing. 
I'll add to those: 
  • Go through the quick demo of how the design questions work. It's not the same as the test but close enough to help you out. 
  • For the design questions, check to see what all your available components are before trying to start the project. 
  • Hammer out the main components and then move things around to start the design. I actually do this with visio as well..get all the main stencils on the page first. 

I met three people who had failed the test. It's a long test. Time management is crucial. Good luck.
I'll be taking the VCAP5-DCA next, thanks to the VMworld discount code from PearsonVue. 

Tuesday, August 28, 2012

Die vRAM Die!

vRAM entitlements gone. Now shops that have intentionally purchased smaller memory servers this past year are grumbling. As are the shops that upgraded to Ent+ just to get the higher vRAM entitlement. 

Hopefully it's not too little too late. vRAM made shops wake up and look around at the rest of the competitors...and they can sing a sweet tune.

The Ent+ vCloud Suite upgrade path is like giving your partner flowers after you screwed up: A good idea, but maybe you shouldn't have had a reason to buy the flowers in the first place. 

How about some more trickle down features to Enterprise? I'm still waiting for my vDS. 

Saturday, July 28, 2012

vCSA upgrade tips & recommendations

Upgrading the vCenter Server Appliance looks simple enough. If you run into problems, maybe these tips can help:

  • Create the 20G (yes 20G) disk in the kb article
  • Take a snapshot first (shut down services)
  • If the upgrade does not go smoothly the first time, do not try again with a half-broken install. Revert to snap.
  • If your upgrade breaks during the export, check your free inodes (df -i)
  • Increase the number of inodes on the /storage/db/export partition (mkfs -t ext2 -i 8192 /dev/sdc1 )
  • Problems mounting /dev/sdc1 (doesn't like ext2)? tune2fs -O has_journal /dev/sdc1
  • tail -f /opt/vmware/var/log/vami/updatecli.log during the upgrade. This file is created a minute or two after you kick off the upgrade. 
  • There will be a long (potentially hours long) pause in the log while the database export is happening. Top will show db2bp kjourneld and db2sync in use. Do not kill any of these processes. 
  • You didn't take my advice and create a snapshot? You needed to use a restored backup? You might need to remove the /etc/udev/rules.d/70-persistent-net.rules mac addresses if the appliance says it can't bring up eth0. 

Monday, July 2, 2012

Real competition now

What was that pooled vRAM licensing? Never mind? Good idea.
Now update the goddamn vCenter Appliance and stop making software that requires MS Windows.

Tuesday, April 3, 2012

vConverter 5 P2V Windows XP "server"

Let's see if I remember all the steps for this P2V.

Source machine was a physical Windows XP "server" on one subnet; destination was a new vSphere 5 environment on a second subnet. No routing between the two subnets, just another physical Windows XP workstation with nics on both subnets that I could install vConverter on.

After fighting with SSL certs with vConverter (an issue with the source machine's external firewall), I opted to turn off ssl in vConverter:
  • Path for XP [and probably Windows 2003] C:\Documents and Settings\All Users\Application Data\VMware\VMware vCenter Converter Standalone\converter-worker.xml (the path for 2008 Server / Windows 7 is hidden folder C:\ProgramData\VMware\VMware vCenter Converter Standalone\converter-worker.xml)
  • Edit the <nfc> <useSsl> statement from true to false
  • Restart the vConverter Worker service 
I've done plenty of cross-network P2Vs before. Your vConverter server is your go between. P2V the source physical machine to a VMware Workstation image on a shared directory on the vConverter host and then V2V the workstation image to your vSphere environment.

For this case, I didn't have a ton of extra space on the vConverter machine, so I needed to shrink the physical 80G IDE partition down to 20G (12G in use). No problems here and the "optimize partition alignment" option gives me plenty of warm fuzzies.

I booted up the final vSphere version, finished vmware tools intstall and got set to extend the C partition back out for future growth.

No dice.

IDE vmdk's can not be extended.

No problem, says Google. Swap the disk adapter in vConverter. So I go back to the workstation image of the source and V2V again with lsilogic parallel.


V2V with Buslogic?


Plan D: Change the IDE disk to SCSI.
  • Clone the IDE version of the XP "server" for backup.
  • Grab the lsilogic drivers from 
    • Your Windows XP 32bit version will be something like 
    • 64bit XP:
    • VMware's KB article mentions the different versions but doesn't specify the 1.28.03 is for 64bit XP only. We'll see if they update the doc with my comment. 
  • I created a virtual floppy on one guest in the environment and copied over these files onto the floppy for future use (I'm sure they'll be needed again).
  • Create a new vHDD with lsilogic parallel on scsi0:1; size doesn't matter, thin. 
  • Attach the vFloppy to the XP VM (note: vFloppies can only be connected to a single VM at a time) and install the correct drivers. Shutdown the XP VM.
  • This process assumes there are no snapshots.
  • Double dream hands time:
    • Open ssh on one of the esxi servers, login, su to root and change directory to the XP VM that we've been screwing with.
    • ls -l to get the byte count of the ide vmdk
    • vmkfstools -c <size in bytes> -d thin -a lsilogic <name of new temp vmdk>
    • Copy a backup of the ide .vmdk disk descriptor file (*not* the large -flat.vmdk)
    • Copy a backup of the vmx file
    • cat <name of new temp vmdk> ; note the following parameters: 
      • ddb.geometry.cylinders = "#"
      • ddb.geometry.heads = "#"
      • ddb.geometry.sectors = "#"
      • ddb.adapterType = "lsilogic"
    • vi <ide vmdk> and change the settings listed above to the values from the <temp vmdk> that you just copied down; save & close. 
    • vi <vmx file> and you'll need to look around and change a few areas: 
      • For ide0:0 that is your virtual hard disk, change all values to start with scsi0:0
      • For ide0:1 that is probably listed as your cdrom; update these values to ide0:0 
      • Look for a value scsi0:0.present = "false" and update this to "true"
      • ide0:1.present should be updated to "false"  (you might be able to delete this line)
      • save & close
    • Try turning on the XP VM. If all has gone according to plan, you should boot without issue. Do a little dance (see link above for inspiration).
    • Delete the temp vmdk and the backup files from within your ssh session
  •  Shut the VM back down and extend the C: partition (while you're at it, delete the scsi0:1 disk)
    • Extend the vHDD from the vSphere Client GUI
    • Boot from your favorite partition changer iso. I'm partial (ha!) to's not let me down yet.
    • Start the XP VM up again and probably go through a disk check. This is normal. 
Even Marquese gets DDH at 1:06

Thursday, March 29, 2012

DB2 to Postgre vCSA change

The vCenter Server Appliance in the not-released-yet 5.0.1 (5u1) version will be switching from embedded DB2 to Postgre. ARG. Drink up
Is this because the transaction log settings and otherwise working with DB2 to truncate existing tables has been an issue? I sure can't find any detailed information online with the inner workings of the DB2 db. Hopefully smoother sailings than I've had so far.

Tuesday, March 27, 2012

vDR email spam

Crazy crazy amounts of email spewing from a vDR 2.0 appliance. VMware says this is a known bug and you could turn off email alerts and/or reboot your appliance on a regular basis. Drink Up.

Come on  guys, really? That's not acceptable. How about I limit the number of outgoing packets per day on port 25? It worked this morning... but long term I hope that VMware is fixing this bug.

iptables -A OUTPUT -p tcp --dport 25 -m limit --limit 10/day -j ACCEPT

Also I was trying to find a config file that would have the settings for the email reports, but perhaps this isn't kept in a config or xml file. find / -mtime -1 after I made changes in the UI didn't seem to point to any text files.

Wednesday, February 22, 2012

The VCP5 can smell fear

For me, it was the fact that I'd never actually gone through an AutoDeploy setup. I mean, Enterprise Plus license level only with large shops that are deploying massive hosts? Not used often. I use the ESX Deployment Appliance. The every-person's version of kickstart for ESXi systems. I love EDA.

Anyway. The test could sense that I had skimmed the AutoDeploy documentation. I'm sure it has sensed fear from others on different subjects. A respectable 400 considering that I probably missed all the autodeploy questions.

And I totally stole and modified the VCP button. VCP#22708 on 3,4&5. VCAP5-DCD next.

Monday, February 13, 2012

hostdatastoresystem.createvmfsdatastore for object datastoresystem error

Well, from the ramblings of other blogs and the community forums, that ^ error string from the vSphere Client could mean just about anything could be wrong with your storage, your LUNs or your storage network.
In my case, after a long call with Dell EqualLogic and VMware, it turned out to be MTU size. In order to make my world right again, the MTU size on the Dell 6224 switches needed to be higher than the MTU size on the surrounding infrastructure. So: vSwitch, VMKernel and EqualLogic mtu: 9000. 6224's: 9126

Previous to that, there were logins and logouts on the iSCSI side, all sorts of errors seen in the vmkernel logs, but nothing...absolutely nothing...pointed in the direction of the MTU.

So, my short story that was actually really long is to show you, dear reader, that the first blog post that you find with this error message might not be your problem, it might not be the third or fifth solution you find. You might need to get help from someone else to check your configuration for something stupid that you've missed because you are less familiar with jumbo frames.

Wednesday, February 1, 2012

ipcop 2.0.2

IPCOP2 still needs buslogic SCSI controller; and in order to use BusLogic, make sure you've chosen Other Linux 32bit.

And E1000 nics (but you should have known that).

Legacy Applications

I got it. I've got a better handle on "cloud" than ever before. Aaron Delp and Brian Gracely helped me there, putting it in perspective of "traditional" hypervisor/cloud stacks. Drink up: Drink Me. Google their names and great things pop up. From here in the trenches, it's good to get a high level overview every once and a while.

Tuesday, January 24, 2012

old linux VM trick..

I was re-deploying a vDR2.0 machine today and could *not* get the console keyboard to stop stuttering. I looked up the old trick for delay, but it doesn't seem to be taking effect. The options->general->config params are not available for this appliance, not sure if the machine is ignoring other options on the vmx file.. I ended up using the Microsoft on-screen keyboard to get in and set the IP. Here's the text of the kb article for future personal reference. I haven't had to use this hack in years.

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

Power off the virtual machine. Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:

keyboard.typematicMinDelay = "2000000"

The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it.

Power on the virtual machine. To make the changes using the vSphere Client: Power off the virtual machine Right click virtual machine select Edit Settings Click Options > General > Configuration Parameters Click Add Row Under Name enter keyboard.typematicMinDelay In the Value field 2000000 Click OK Power on the virtual machine