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