Jay's Blog

Nexus 1000v SNMP

Jay — Wed, 20 Apr 2011 02:12:24 +0000

I had a few of folks ask me about snmp configuration on 1000v last so am reusing the content I sent them for this post. This is basically a 5 minute configuration of Nexus 1000v SNMP monitoring with SolarWinds NPM.

Software Versions used:

Nexus 1000v version 4.0(4)SV1(3b)

Nexus 1000v version 4.0(4)SV1(4)

SolarWinds Orion NPM 10.2

Network Topology:
SolarWinds NPM was running in a VM on the same cluster as the VSM. Basically they were connected to the same physical Nexus 5020 and on the same vlan. So a very flat backend network topology and no firewall in between. before you begin make sure you can ping from Nexus 1000v to the NMS.

Configuration Steps:

Step 1.
Configure Nexus 1000v SNMP to send traps to the NMS.

Here we are using user xxxxxx to send traps to the NMS using management interface.

snmp-server contact xxxxxx@cisco.com
snmp-server location SJSV-iLAB
snmp-server user admin network-admin auth md5 Cisco123 priv aes-128 Cisco123
snmp-server user admin enforcePriv
snmp-server user xxxxxx network-admin auth md5 Cisco123 priv aes-128 Cisco123
snmp-server user xxxxxx enforcePriv
snmp-server host 172.16.165.134 traps version 3 priv xxxxxx
snmp-server host 172.16.165.134 use-vrf management

Step 2. Configuration On SolarWinds
Step 2(a).
Select Add Node and Type in the Nexus 1000v VSM IP Address

Step 2(b).
Type in the user authorized to send snmp trap on the VSM

The SNMPv3 Password can be either just the password you configured (“Cisco123”)or its localized key (“0x81558f44c057276fca90f3b757465c7c”) from show run snmp. If you are using the localized key make sure you check “Password is a key”, as shown in the following screen shot.
For example:snmp-server user xxxxxx network-admin auth md5 Cisco123 priv aes-128 Cisco123
Becomes:
snmp-server user xxxxxx network-admin auth md5 0x81558f44c057276fca90f3b757465
c7c priv aes-128 0x81558f44c057276fca90f3b757465c7c localizedkey

Step 2(c).
Repeat the same steps, same username and password.

Step 2(d).

Now Click “Test” and it should be successful.

Step 2(e).Now go through the steps and add the interfaces to monitors, I went with all

Step 2(f).
Select what pollers to add to the node, here some like power supply, temp are not relevant for a VSM running on a ESX host, so pick and choose the ones you want to poll.

Click Next.

Step 2(g).

Now Click on “OK, ADD NODE” and voila “Node was successfully added”.

Cisco Nexus 1000v manual VEM upgrade to Release 4.2(1) SV1(4)

Jay — Thu, 17 Mar 2011 23:53:39 +0000

Note 1: Even though Cisco fully supports VUM based upgrades we generally recommend the CLI for VEM upgrades as it provides more granular control on what gets upgraded when.

Note 2: If you plan on manually upgrading the VEM modules make sure you have disabled VMware Update Manager (VUM) service so that it does not automatically roll back changes we make. Once the vem upgrade is complete we can start it back up.

Step 0 Run a “show mod” to check the status of the modules

switch#  show mod
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok

Mod  Sw               Hw
---  ---------------  ------
1    4.0(4)SV1(3b)     0.0
3    4.0(4)SV1(3b)     1.11
4    4.0(4)SV1(3b)     1.11
5    4.0(4)SV1(3b)     1.11
6    4.0(4)SV1(3b)     1.11 

Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA
6    02-00-0c-00-06-00 to 02-00-0c-00-06-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    172.16.165.55    NA                                    NA
3    172.16.165.91    dcedbaac-1dc0-11df-0000-00000000000e  172.16.165.91
4    172.16.165.92    dcedbaac-1dc0-11df-0000-00000000000d  172.16.165.92
5    172.16.165.93    dcedbaac-1dc0-11df-0000-00000000000c  172.16.165.93
6    172.16.165.94    dcedbaac-1dc0-11df-0000-00000000000b  172.16.165.94
* this terminal session

This is looking good, with one active VSM and multiple VEM modules and all running the same version.

Step 1 Download the Nexus1000v.4.2.1.SV1.4.zip file from Cisco.com and unzip it and you will find the new 4.2(1) SV1(4) vem images bundle vem-release_final.tar.gz under the VEM folder. Copy this file to the VSM bootflash.

switch# copy scp://root@172.16.165.51/srv/Cisco/Nexus1000v.4.2.1.SV1.4/VEM/vem-release_final.tar.gz bootflash:

Step 2 Update the VSM with the latest VEM modules

switch# vmware vem upgrade update-vibs bootflash:vem-release_final.tar.gz

Step 3 Notify vCenter Server/VUM that a latter version of VEM is available for upgrade.

switch# vmware vem upgrade notify

switch# show vmware vem upgrade status

Step 4 Confirm that VMware Update Manager is disabled (note 2) and then Go the vCenter Server, Home -> Inventory -> Networking and Select the Nexus 1000v swtich and Click the DVS Summary tab to check for the availability of a software upgrade and accept it. Now come back to VSM and check the status. And since we are planning to upgrade the VEM modules manually you can ahead and do “vmware vem upgrade proceed” and then complete the process.

switch# show vmware vem upgrade proceed

switch# show vmware vem upgrade status

switch# vmware vem upgrade complete

switch# show vmware vem upgrade staus

So far we let VSM, vCenter Server and by extension VMware update manager know that there is an VEM update available. Now we have to go ahead and actually install the VEM modules on the ESX hosts.

Step 5 Copy the VEM bundle to the ESX hosts /tmp folder or to a shared vmfs volume . Which VEM bundle to copy and install will depend on the build number of your ESX host, see the VEM compatibility table here for more details. Then depending on whether you are using the .vib or .zip files, you run either of the following command to install the VEM modules on the ESX hosts.

esx-host-2# esxupdate -b ./cross_cisco-vem-v130-4.2.1.1.3.9.0-1.9.1.vib update

esx-host-2# esxupdate --bundle VEM410-201101108-BG.zip update

Step 6 Now repeat the same steps on all the ESX hosts until you have, this on show mod.

switch#show mod
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok

Mod  Sw                Hw
---  ----------------  ------------------------------------------------
1    4.0(4)SV1(3b)      0.0
3    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
4    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
5    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
6    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)

Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA
6    02-00-0c-00-06-00 to 02-00-0c-00-06-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    172.16.165.55    NA                                    NA
3    172.16.165.91    dcedbaac-1dc0-11df-0000-00000000000e  172.16.165.91
4    172.16.165.92    dcedbaac-1dc0-11df-0000-00000000000d  172.16.165.92
5    172.16.165.93    dcedbaac-1dc0-11df-0000-00000000000c  172.16.165.93
6    172.16.165.94    dcedbaac-1dc0-11df-0000-00000000000b  172.16.165.94

Step 7 Once you confirm that all your ESX hosts have the latest VEM modules, Go ahead and start your VSM upgrade

Cisco Nexus 1000v Standalone VSM upgrade to Release 4.2(1) SV1(4)

Jay — Thu, 24 Feb 2011 01:35:35 +0000

Cisco Nexus team released the update to the Nexus 1000v product taking it to release 4.2(1) SV1(4). They did a great job of documenting the entire upgrade process both in docs and in a series of screencasts. Check it out it’s really worth your time.

However one obvious thing that they have missed so far is how to upgrade if your VSM is in standalone mode. Part of the problem is the Upgrade application (GUI) does not support standalone mode and the upgrade document does not address the manual upgrade (CLI) method for standalone VSM.

Here is a quick guide on how to upgrade your standalone VSM from 4.0(4) SV1(3, 3a, or 3b) to 4.2(1) SV1(4).

Before you start make sure you have run the pre-upgrade check script against your 1000v configuration to make sure you don’t run into the 7 configurations that are incompatible with Nexus 4.0.x to 4.2.x code.

Now the actual steps:

Step 0 Do a show mod and make sure you have already upgraded all the VEM modules. Remember this has changed from earlier releases. You HAVE to upgrade the VEM first and VSM second to upgrade to release 4.2(1) SV1(4).

show mod
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok

Mod  Sw                Hw
---  ----------------  ------------------------------------------------
1    4.0(4)SV1(3b)      0.0
3    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
4    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
5    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
6    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)

Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA
6    02-00-0c-00-06-00 to 02-00-0c-00-06-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    172.16.165.55    NA                                    NA
3    172.16.165.91    dcedbaac-1dc0-11df-0000-00000000000e  172.16.165.91
4    172.16.165.92    dcedbaac-1dc0-11df-0000-00000000000d  172.16.165.92
5    172.16.165.93    dcedbaac-1dc0-11df-0000-00000000000c  172.16.165.93
6    172.16.165.94    dcedbaac-1dc0-11df-0000-00000000000b  172.16.165.94

Step 1 Copy the new software release system image and kickstart image files to the bootflash file system of the VSM.

switch# copy scp:root@172.16.165.51/srv/n1kv-images/nexus-1000v-mz.4.2.1.SV1.4.bin bootflash:
switch# copy scp:root@172.16.165.51/srv/n1kv-imagess/nexus-1000v-kickstart.mz.4.2.1.SV1.4.bin bootflash:

Step 2 Use the install all command to update the boot variables to release 4.2(1)SV1(4) images.

switch# install all system bootflash: nexus-1000v-mz.4.2.1.SV1.4.bin kickstart bootflash:nexus-1000v-kickstart-mz.4.2.1.SV1.4.bin
Boot variables are updated to running configuration.

Step 3 Save your configuration by copying the running configuration to the startup configuration.

switch# copy running-config startup-config
[########################################] 100%

Step 4 Reload VSM.

switch# reload
This command will reboot the system. (y/n)? [n] y

switch#show mod
Mod  Ports  Module-Type                       Model               Status
---  -----  --------------------------------  ------------------  ------------
1    0      Virtual Supervisor Module         Nexus1000V          active *
3    248    Virtual Ethernet Module           NA                  ok
4    248    Virtual Ethernet Module           NA                  ok
5    248    Virtual Ethernet Module           NA                  ok
6    248    Virtual Ethernet Module           NA                  ok

Mod  Sw                Hw
---  ----------------  ------------------------------------------------
1    4.2(1)SV1(4)      0.0
3    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
4    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
5    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)
6    4.2(1)SV1(4)      VMware ESXi 4.1.0 Releasebuild-320137 (2.0)

Mod  MAC-Address(es)                         Serial-Num
---  --------------------------------------  ----------
1    00-19-07-6c-5a-a8 to 00-19-07-6c-62-a8  NA
3    02-00-0c-00-03-00 to 02-00-0c-00-03-80  NA
4    02-00-0c-00-04-00 to 02-00-0c-00-04-80  NA
5    02-00-0c-00-05-00 to 02-00-0c-00-05-80  NA
6    02-00-0c-00-06-00 to 02-00-0c-00-06-80  NA

Mod  Server-IP        Server-UUID                           Server-Name
---  ---------------  ------------------------------------  --------------------
1    172.16.165.55    NA                                    NA
3    172.16.165.91    dcedbaac-1dc0-11df-0000-00000000000e  172.16.165.91
4    172.16.165.92    dcedbaac-1dc0-11df-0000-00000000000d  172.16.165.92
5    172.16.165.93    dcedbaac-1dc0-11df-0000-00000000000c  172.16.165.93
6    172.16.165.94    dcedbaac-1dc0-11df-0000-00000000000b  172.16.165.94

That’s it the VSM upgrade is complete to 4.2(1)SV1(4).

As an aside. These steps compare extremely well when contrasted with the HA based VSM manual upgrade which is 22+ steps. I actually had the VSMs in a HA pair and deleted the secondary, upgraded the primary as a standalone and deployed a new 4.2(1)SV1(4) VSM VM using the OVF files and powered it up and called it secondary and it happily synced with the primary and the upgrade is complete.

Slackware Virtual Machine v13.1

Jay — Fri, 14 Jan 2011 04:41:38 +0000

I have been meaning to update the linux virtual machine images with newer versions but have been too busy so far, however managed to get a breather at work thanks to the post Holidays slump So here is an vm with the latest version of Slackware 64bit v13.1.

Slackware Linux VM Configuration
Distribution: 13.1
Linux Kernel: 2.6.33
Installation Type: Base+X+XFCE
Desktop Environment: XFCE
Networking: DHCP
Root Password: vmware

Virtual Machine Configuration
RAM: 1GB (configurable by editing the Slackware64.13.1.vmx file)
Disk: 8.0 GB
Networking: Bridged
VMware Tools: Not Loaded
Monitor Resolution: 1024×768

Download Information
Available in the Downloads page.

File Size: 458 MB
Compression: RAR
MD5SUM a2b61d506c20a966e7c4d1b84a2794e4 * Slackware64.13.1.rar

Hope ya have fun and find the vm useful. Also if there is a specific Linux/Unix distribution vm that you are looking for let me know in the comments and I will see if I can spin one.

Cheers!

Consolidating my blogs

Jay — Thu, 13 Jan 2011 03:57:59 +0000

After a lot of thinking I have decided to merge my two blogs previously at www.vmwhere.net and jayakumar.co.in into a single site/blog here at www.jayakumar.org.

The reason was simple, am lazy and do not want to maintain two sites. Plus after I moved out of VMware late last year I don’t feel the need maintain a separate blog for VMware so as maintain that thin distinction between work (VMware) and personal (linux/networking) stuff. Also since I have joined Cisco I wanted to blog bout Nexus 1000v and Cisco UCS products, but the mere thought of setting up and maintaining another blog kept that idea far. So theoretically I have merged 3 blogs into one.

Hopefully this will spur me into writing some good content, to make all that multi-re-directs that I have set up worthwhile

Cheers!

All downloads are gone :(

Jay — Sat, 18 Sep 2010 21:17:49 +0000

Thanks to a catastrophic failure during migration from a private server to a shared server, all the site downloads are gone the blogs posts, comments etc basically everything that was on the database we were able to recover from a db backup, but anything on the filesystem is gone. So all the virtual machine images are gone as well so no more virtual machine downloads

I will try to spin up a few of the latest gentoo and slackware versions that I have skipped earlier on in the next few weeks and hopefully we will have some downloads then.

Sorry for the inconvenience, if you came here looking for quick access to some linux virtual images .

Improve linux raid rebuild/resync speed

Jay — Sat, 14 Aug 2010 19:45:24 +0000

I have a small NAS box with 6 x 1TB HDD in RAID 6 and 4 x 500GB HDD in RAID 5. Recently thanks to the arrival of my baby girl and a HD handy cam, I was running out of space fast on the array and so when when I saw a decent deal for 1TB drives in NewEgg I picked up couple to add to the RAID 6 volume.

Growing a raid array in linux using mdadm is easy. I made sure I used fdisk to create single large partition on the drive and mark the partition type fd (Linux raid autodetect) prior to adding it to the array.

Device Boot Start End Blocks Id System /dev/sdm1 1 121601 976760001 fd Linux raid autodetect

Adding the drives to the raid is straightforward
mdadm --add /dev/md1 /dev/sdl1 mdadm --add /dev/md1 /dev/sdm1

the device gets added as spares in the array, now grow the array to include the spares. Remember earlier I had 6 drives in it, now am increasing it to 8.
mdadm --grow /dev/md1 --raid-devices=8

Now I have to wait for RAID to resync with the new drives. You can watch the progress by running
watch cat /proc/mdstat

Except I was pissed to see when it said
[>......................] reshape = 0.0% (7892/976759936) finish=2804.9min speed=5463K/sec

This meant the array will take about 47hrs to rebuild at 5MBPS speed, I was pissed but did not worried because I had run into this issue before and all I have to do is increase the minimum and maximum speed limits for the raid device from seriously conservative limits to reasonable limits.

So I went ahead and did the following

echo 50000 > /proc/sys/dev/raid/speed_limit_min echo 200000 > /proc/sys/dev/raid/speed_limit_max
See here for some additional details on these commands.

Now I opened /proc/mdstat, imagine my surprise when the speed improved from 5463K/sec to 5863K/sec and settled there. Now I got aggressive and doubled the numbers to 100000 for min and 400000 for max. Now the speed moved from 5863K/sec to 6028K/sec and settled around there. Now am worried if there was some sort of bus contention or other drivers issues am running into.

And after about 30mins for furious googling, I found clues that increasing the strip_cache_size improves the resync build speed as well, mine was set to default 256

cat /sys/block/md1/md/stripe_cache_size 256

Changed that to 1024
echo 1024 > /sys/block/md1/md/stripe_cache_size

Now the speed increased from 6028K/sec to a nice 15763K/sec

Setting the cache size to 4096 brings it up to a cool 22844K/sec. Bumping it up to 8192 takes it a 27169K/sec, at this point am sensing am reaching point diminishing returns. So as any tech guy would do, I plow through to 16384 and the speed increased to 30029K/sec for a few secs, but came down and settled at 29100K/sec. Now on to 32768, now that made it worse it went down to 27970K/sec. Here is quick table of the improvement per cache size

stripe_cache_size -> speed K/sec -> finish min 256 -> 6028 -> 2581.8 1024 -> 15763 -> 1003.3 4096 -> 22844 -> 703.7 8192 -> 27169 -> 604.5 16384 -> 30029 -> 553.5 32768 -> 27970 -> 601.6

In the end it moved back to 16384 and the speed settled into a range between 28000-30000K/sec and a rebuild finish time of just under 570mins.
[>......................] reshape = 0.1% (70372/976759936) finish=569.3min speed=28773K/sec
An improvement from 47hrs to 9.5hrs, I think I can live that

PXE boot VMware ESXi 4.1 and Manual Install

Jay — Tue, 20 Jul 2010 20:11:44 +0000

an awesome new feature in the just released ESXi 4.1 is the ability to do PXE boot and script the install using a kick-start script. If you looking for information on how to do this see here at billhill’s post.

http://communities.vmware.com/blogs/vmwareinsmb/2010/07/13/esxi-41-scripted-installation-via-pxe-and-kickstart

However while adding that feature VMware seems have slightly broken the PXE boot, but manual install ability of ESXi. This is useful if you have lights-out lab and want to use the local pxe server instead of those virtual media options but also want to customize the install options as the lab servers do not have standardized components and hardware and may other issues.

Refer to the above link for overall PXE/dhcp/tftp install steps. I plan only to document what’s different for a manual install.

Here are the steps to do it. By the way, the key is in the weird named file imagedd.bz2 on the ESXi install cd.
-r--r--r-- 5 root root 13320 2010-05-18 16:48 a.z -r--r--r-- 1 root root 2048 2010-05-18 17:21 boot.cat -r--r--r-- 6 root root 1164618 2010-05-18 16:49 cimstg.tgz -r--r--r-- 6 root root 16101197 2010-05-18 16:50 cim.vgz -r--r--r-- 3 root root 7364186 2010-05-18 17:21 ienviron.vgz -r--r--r-- 3 root root 212380054 2010-05-18 17:19 imagedd.bz2 -r--r--r-- 3 root root 74 2010-05-18 17:19 imagedd.md5 -r--r--r-- 2 root root 22887 2010-05-18 17:15 install.vgz -r-xr-xr-x 1 root root 12241 2010-05-18 17:15 isolinux.bin -r--r--r-- 1 root root 298 2010-05-18 17:15 isolinux.cfg -r-xr-xr-x 1 root root 47404 2010-05-18 17:15 mboot.c32 -r-xr-xr-x 1 root root 51020 2010-05-18 17:15 menu.c32 -r--r--r-- 1 root root 1831459 2010-05-18 17:15 open_source_licenses.txt -r--r--r-- 1 root root 2889 2010-05-18 17:15 README.txt -r--r--r-- 5 root root 72206398 2010-05-18 17:15 sys.vgz -r--r--r-- 5 root root 40876 2010-05-18 17:15 tboot.gz -r--r--r-- 6 root root 48285 2010-05-18 17:15 vmkboot.gz -r--r--r-- 5 root root 2469813 2010-05-18 17:15 vmkernel.gz

For the sake for posterity, just go ahead and copy all the above files to your tftp/pxeboot folder.

then rename the imagedd.bz file to VMware-VMvisor-big-260247-x86_64.dd.bz2
mv imagedd.bz2 VMware-VMvisor-big-260247-x86_64.dd.bz2

Create a folder structure that ESXi installer looks for the system file in
mkdir –p usr/lib/vmware/installer/

Move the file to the correct location
mv VMware-VMvisor-big-260247-x86_64.dd.bz2 usr/lib/vmware/installer/

The installer is looking for a tar fgz file named image.tgz, so lets create one.
tar cvzf image.tgz usr/

Now that we have the file in the correct format and folder structure lets add it to the pxe append command.
append vmware/esx4.1/vmkboot.gz ks=http://192.168.163.48/ks.cfg --- vmware/esx4.1/vmkernel.gz --- vmware/esx4.1/sys.vgz --- vmware/esx4.1/cim.vgz --- vmware/esx4.1/ienviron.vgz --- vmware/esx4.1/install.vgz

From the above line remove the ks command and add the image.tgz at the end.
append vmware/esx4.1/vmkboot.gz --- vmware/esx4.1/vmkernel.gz --- vmware/esx4.1/sys.vgz --- vmware/esx4.1/cim.vgz --- vmware/esx4.1/ienviron.vgz --- vmware/esx4.1/install.vgz --- vmware/esx4.1/image.tgz

That’s it. Now bootup your server and enjoy the pxe boot bliss.

Update: Also its safe to delete the usr folder tree you created after creating the image.tgz, it is just sitting there taking up space, thanks raph

setting up http proxy for cli

Jay — Mon, 22 Feb 2010 22:14:46 +0000

Okay, I have to google this information every-time I need it, to so am going to blog it, so that I know exactly where to look for it

Setting up a proxy from the GUI on you browser or system does not always work for command line utilities like apt-get, yum, wget or customer bash scripts etc…

So here is how to setup proxy for CLI from CLI, assuming your proxy server is proxy.example.com (IP 192.168.2.252) and port 3128.
export http_proxy='http://proxy.example.com:port/'

OR
export http_proxy='http://192.168.2.252:3128/'

If you need authentication:
export http_proxy=http://username:password@proxy.example.com:port

If you need to unset it:
echo $http_proxy=''

If need to check if there is already proxy configured:
echo $http_proxy

This change is non-persistent, meaning you will have to redo it after reboot. If you need the configuration to be persistent across reboots. Add the above command to your system /etc/bash.bashrc.
export http_proxy=http://username:password@proxy.example.com:port

You can also add a ftp proxy using a similar entry. Ofcourse check with your admin if the proxy supports ftp.
export ftp_proxy=http://username:password@proxy.example.com:port

Hope this helps someone. Cheers!

Installing Silverlight 3 on Hackintosh

Jay — Fri, 06 Nov 2009 07:27:02 +0000

Okay I have always wanted to own a Mac Pro and that wish only grew more after I bought my Mac Book and the Mini for HTPC duties. I like the OS X interface and recently bought Snow Leopard Family pack to upgrade my laptop and mini and was wondering what to do with my Dell Inspiron 530s (the only windows box in the house, ohh btw I do like Windows 7 and is really the best Windows OS Yet ) and decided to dual boot it with OS X.

The hackintosh installation was a bit round about as I had install Leopard first and then use that install Snow Leopard and then update the boot loader to Chameleon rc3 and fix the boot order from the windows with easybcd 2.0 beta. That story is for latter.

Now coming back to the title of this post after I got the setup up and running, I was trying out all my usual apps and when I tried Instant Watch from Netflix, i trt wanted to install Silverlight 3.0. I download the dmg ran the install it said I was running a Power PC and the install failed. I “googled it” and found that the installer is checking for the PC type and is parsing it wrong. So here is the fix.

1. Download the Silverlight DMG file from Microsoft

2. Mount the DMG file (double click it)

3. Copy the pkg file ( Silverlight.3.0.pkg ) to your desktop.

4. Right-click (or ctrl+click) on the .pkg file on your desktop and choose “Show Package Contents”

5. Browse to: Contents > Resources and then Select the file “InstallationCheck”.

6. Now you can do either of the following steps:

6a. Right-click the file “InstallationCheck” and choose to “Move to Trash” This removes the CPU check that prevents the install. OR

6b. Right-click the file”InstallationCheck” and Open it “Other” and Select “TextEdit” App. Then Find and Replace two places where the installer checks for EXIT_VALUE and change the “96+xx” number to zero “0″. Save the File and Exit TextEdit. This will result the install check always returning success.

7. Now close that Finder window and run the .pkg file we just edited. Silverlight should now install without any problems!

The above steps are originally from this tech recipe modified with my suggestions. Hope this helps.