Vmware on BeyondVM

How To: ThinApp Firefox 29 and Plugins for vCloud Director 5.1.x

Mon, 04 Aug 2014 00:00:00 +0000

In response to this article about Firefox 30 and vCloud 5.1.x and this article about Java updates breaking everything I decided to throw together a quick How-to on using ThinApp to create a sandboxed version of Firefox and Java that solves both of these problems pretty well.

This ThinApp setup includes a legacy version of Java (7u25) which is super old but it should help with accessing the following (not exhaustive list, just things I have run into, please help expand list):

UCS Manager 2.1.x
vCloud Director 5.1.x Uploads
HP iLO 2.x
Legacy DRAC
vCloud VPN
EMC Unisphere

Onward, but first an important caveat:

This process creates an insecure browser installation, DO NOT browse the internet with this configuration…ever.

You have been warned.

Note: I am not a ThinApp expert (and I usually avoid windows, hah!) so there may be a more elegant way to do this, if anyone has tips let me know!

First, collect the correct tools, I attached the versions that I used at the end of the post:

Firefox 29.0.1 Link
Java 7u25 (32 bit) Link
Flash Installer (for correct OS, I used Win8.1) Link
VMRC Installer for 5.1.x from your instance (or mine from 5.1.x below)
VMware ThinApp 5.x Trial
Clean Windows 7 or 8 Capture VM (Base install without security software is best)

After Windows is installed, the following are steps to take to create the package:

Take snapshot of base VM
Install ThinApp 5.x
Take snapshot (this is a theme, I have found a successful ThinApp capture is snapshot heavy)
Start “ThinApp Setup Capture” utility, Click Next

Click Prescan
Install Firefox
1. Choose Custom
2. De-select “Maintenance Service”
Install Flash (Latest version is fine)
Install Java
1. Choose “Change Destination Location”
2. Install to “c:\java”
Install VMRC Plugin
Launch Firefox, perform the following tasks
1. Navigate to about:config in Firefox, Click “I’ll be careful, I promise!”
2. Change the following settings
  1. app.update.auto – false
  2. app.update.enabled – false
  3. app.update.silent – false
  4. app.update.mode – 2
  5. extensions.update.autoUpdateDefault – false
  6. extensions.update.enabled – false
  7. (optional, disables login remembering) signon.rememberSignons – false
  8. (optional, enables pop-ups since vCD uses these) dom.disable_open_during_load – false
3. Verify plugin updating is disabled:
  1. Navigate to Menu -> Addons
  2. Click Plugins
  3. Click the gear icon and make sure this option is not selected
1. Perform the following tasks to verify that Java is installed
  1. Navigate to this Link
  2. Click “Activate”
```
3. **Click** to “Allow and Remember”






4. **Check** the “Don’t Ask Again…” Checkbox and **Click** Later






5. **Click** the Run button at the prompt to verify the Java applet loads
```
Take Snapshot (just in case)
Back to the ThinApp Capture Utility, click Postscan

Click OK

This will take some time, so grab some coffee.
De-select all entry points other than Firefox, click Next

Click Next

Click Next

Select “Restricted write access”, click Next.

Select “Same Directory…”, click Next.

Select No (unless you want to share), click next

Click next (I don’t use the ThinDirect feature because it only works with IE)

Update inventory name to “Firefox 29.0.1″ to differentiate it.

Select “Use one of the entry points” then pick “Mozilla Firefox.exe”, Check “Compress virtual package”, Click:

Click OK

Ignore warnings (like a boss) and click Next

Click “Edit Package.ini”

In Package.ini, Locate the block “[Mozilla Firefox.exe]” and perform the following changes to the block
1. Add “StatusbarDisplayName=BeyondVM Firefox 29.0.1 Build “
2. Add “CommandLine=%ProgramFilesDir%\Mozilla Firefox\firefox.exe -no-remote”
3. Rename block from [Mozilla Firefox.exe] to [Mozilla Firefox 29.0.1.exe]
Save Package.ini
Click Build

Wait, this will also take some time, more coffee!

Click Finish

At this point you will have a functioning ThinApp package file all bundled up in the single exe file in the bin directory. You might notice that this package is quite large, I performed the following additional steps to my package to get it down to about 350MB from over 800.

Edit Package.ini and perform the following modifications
1. Add the following section below the compression type
```
[FileList]
ExcludePattern=.bak,.msi,.mst,.cab,*.msp
```
2. Delete all entry points other than [Mozilla Firefox 29.0.1.exe]
3. Delete the following directories from the package (note: I have not exhaustively tested this, some of these may be required but it worked for me)
  - %drive_C%\Users\All Users\Microsoft\Windows Defender
  - %ProgramFilesDir(x64)%
  - %SystemRoot%\WinSxS
  - %SystemRoot%\assembly
  - %SystemRoot%\Installer
  - %SystemRoot%\Logs
4. Run build.bat as an Administrator

After that the package is pretty snappy and should be good to go. It will create a profile directory next to the EXE to save settings in, this will include popup allowing and certificate exceptions. The first time I logged into my vCloud instance I had to tell it to run the JRE again, I was unable to figure out how to get it to never ask during the build process but it wasn’t that bad to just do it the first time.

These are all of the files required to do this as well as the package I created following these directions. My pre-built package will expire in about 60d unless I can get VMware to give me a community license (hint hint).

Please leave a comment if there is anything I can improve!

Lastly, the caveat we started with:

This process creates an insecure browser installation, DO NOT browse the internet with this configuration…ever.

You have been warned.

Goodnight and Good Luck.

UCS Networking Adventure: A tale of CoS and The Vanishing Frames

Mon, 14 Jul 2014 00:00:00 +0000

The Problem

This week I had to connect an additional NetApp Storage System to my existing UCS environment through a different path than a similar shared storage platform that we utilize here. This shouldn’t be a big deal but there were a few caveats:

The Storage System was attached to a dedicated Nexus 5k for this customer
The VLAN configured on the customer switch collided with one configured in UCS so VLAN translation was necessary through access ports.
The traffic takes a different switching path from normal NFS traffic in this environment

I configured everything as one normally does when connecting to IP storage, jumbo frames and all. There was only one problem:

Standard Frames


~ # vmkping -s 1400 -d 10.0.0.253
PING 10.0.0.253 (10.0.0.253): 1400 data bytes
2508 bytes from 10.0.0.253: icmp_seq=0 ttl=255 time=0.232 ms
2508 bytes from 10.0.0.253: icmp_seq=1 ttl=255 time=0.198 ms
2508 bytes from 10.0.0.253: icmp_seq=2 ttl=255 time=0.265 ms

--- 10.0.0.253 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.198/0.232/0.265 ms
~ #

Jumbo Frames


~ # vmkping -s 2500 -d 10.0.0.253
PING 10.0.0.253 (10.0.0.253): 2500 data bytes

--- 10.0.0.253 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
~ #

DOH!

Now, normally this is just a simple issue of the MTU being set incorrectly somewhere along the traffic path but as I dug deeper into this issue that turned out to not be the case, it was something much stranger and more interesting. The IPs, VLANs and hostnames have been changed or obscured to protect the innocent. Onward!

Note: To test pinging with Jumbo Frames in ESXi use the following command:

vmkping -s 2500 -d

Background

I checked to make sure jumbo frames where configured correctly all along the traffic path (ESX, UCS vif and customer switch) but I was still not able to ping the Storage System from the ESXi host using jumbo frames.

For reference the configurations were as follows:

The Network

A little about the relevant network topology now, this is a basic diagram of how the network is laid out. There is quite a bit more going on in this network but this diagram shows the relevant parts to this story.

Interface Configurations

Interface facing Customer NetApp (A)


interface Ethernet1/30
  description netapp01:E0B
  switchport mode trunk
  switchport trunk allowed vlan 60,177
  spanning-tree port type edge trunk

Customer side of uplink (B)


interface Ethernet1/29
  description cloud_access_a:eth1/17
  switchport access vlan 60

My side of uplink (C)


interface Ethernet1/17
  description customer_switch_a:1/29
  switchport access vlan 224

Port Channel Facing UCS (D)


interface port-channel2
  description fi01:po1
  switchport mode trunk
  switchport trunk allowed vlan 
  speed 10000

That is it as far as relevant networking goes, onto the VMware side.

ESXi Configuration


~ # esxcfg-vswitch -l
...
Switch Name      Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch1        5632        6           128               9000    vmnic2,vmnic3

  PortGroup Name        VLAN ID  Used Ports  Uplinks
  ipStorage-vmk             2244     1           vmnic2,vmnic3

~ #

Pretty simple configuration here, standard operating for the most part. When this problem began this host had a standard switch but the configuration was just the same. On to UCS.

UCS Configuration

The interesting thing that we did for troubleshooting was to use a pin group to force the traffic down one set of uplinks through the fabric so we could predict where the traffic was going to go. These snippets don’t reflect the pin group as I removed it after troubleshooting but information on pin groups can be found here.

This is the running configuration of the vETH adapter:

vETH Running Configuration


fi01-A(nxos)# sh run interface vethernet 1841

interface Vethernet1841
  description server 1/3, VNIC stgA
  switchport mode trunk
  untagged cos 4
  no pinning server sticky
  pinning server pinning-failure link-down
  no cdp enable
  switchport trunk allowed vlan
  bind interface port-channel1378 channel 1841
  service-policy type queuing input org-root/ep-qos-Storage
  no shutdown

This is the configuration for the CoS class of 4

CoS Gold Class Config


fi01-A /eth-server/qos # show eth-classified gold

Ethernet Classified Class:
    Priority: Gold
    CoS: 4
    Weight: 9
    BW Percent: 47
    Drop: Drop
    MTU: 9000
    Multicast Optimize: No
    Admin State: Enabled
ucpd01-A /eth-server/qos #

Now, onto the other end, the NetApp.

Storage System Configuration

Not too much to see here, but we can verify that the MTU is actually 9000.

NetApp Config


filerA> ifconfig svif1-60
svif1-60: flags=0x2b4c863 mtu 9000
        inet 10.128.160.253 netmask 0xffffff00 broadcast 10.0.0.255
        partner svif2-60 (not in use)
        ether 02:a0:98:1b:6c:18 (Enabled interface groups)
filberB> ifconfig svif2-60
svif2-60: flags=0x2b4c863
        mtu 9000
        inet 10.0.0.254 netmask 0xffffff00 broadcast 10.0.0.255
        partner svif1-60 (not in use)
        ether 02:a0:98:1b:67:98 (Enabled interface groups)

Despite all of that configuration I was still not able to get ping traffic to traverse the network when forcing jumbo frames.

Troubleshooting

The first thing that I did to try to see what was going on was to set up a simple packet capture on another host with jumbo frames enabled on the same switch as the Customer NetApp Storage System.

tcpdump capture


~ # vmkping 10.0.0.10 -s 2400 -d
PING 10.0.0.10 (10.0.0.10): 2400 data bytes

--- 10.0.0.10 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
~ #

#Source:
21:00:39.790337 IP truncated-ip - 2346 bytes missing! (tos 0x0, ttl 64, id 34311, offset 0, flags [DF], proto ICMP (1), length 2428)
    10.0.0.121 > 10.0.0.10: ICMP echo request, id 7342, seq 0, length 2408
21:00:40.792509 IP truncated-ip - 2346 bytes missing! (tos 0x0, ttl 64, id 34314, offset 0, flags [DF], proto ICMP (1), length 2428)
    10.0.0.121 > 10.0.0.10: ICMP echo request, id 7342, seq 1, length 2408
21:00:41.794613 IP truncated-ip - 2346 bytes missing! (tos 0x0, ttl 64, id 34320, offset 0, flags [DF], proto ICMP (1), length 2428)
    10.0.0.121 > 10.0.0.10: ICMP echo request, id 7342, seq 2, length 2408

#Destination:
21:01:34.825518 IP truncated-ip - 2346 bytes missing! 10.0.0.121 > 10.0.0.10: ICMP echo request, id 7342, seq 0, length 2408
21:01:34.825614 IP truncated-ip - 2346 bytes missing! 10.0.0.10 > 10.0.0.121: ICMP echo reply, id 7342, seq 0, length 2408
21:01:35.827732 IP truncated-ip - 2346 bytes missing! 10.0.0.121 > 10.0.0.10: ICMP echo request, id 7342, seq 1, length 2408
21:01:35.827825 IP truncated-ip - 2346 bytes missing! 10.0.0.10 > 10.0.0.121: ICMP echo reply, id 7342, seq 1, length 2408
21:01:36.829821 IP truncated-ip - 2346 bytes missing! 10.0.0.121 > 10.0.0.10: ICMP echo request, id 7342, seq 2, length 2408
21:01:36.829935 IP truncated-ip - 2346 bytes missing! 10.0.0.10 > 10.0.0.121: ICMP echo reply, id 7342, seq 2, length 2408

Note: The truncated-ip just means that tcpdump is only capturing headers, using ‘-s0′ switch turns this off.

What we see here is that on the source machine (Another ESXi Host) I can see the ICMP Echo Requests leave the machine and on the destination machine I see the ICMP Echo Requests AND ICMP Echo Replies.

WHAT.

Back to the network diagram:

I was doing this capture on a host located at point A, my next step was to check the other end of the path before UCS. I set up a span port at point D to check it out. I wired up a server with an available 10Gbit interface and connected it up.

On the CoreSwitch A the following was set up:

Monitor Session


monitor session 1
  description vlan-224-tap
  source vlan 2244
  destination interface Ethernet1/15
  no shutdown

I fired up Wireshark with an ICMP capture filter (no need to crush the disk with 5GB/s of traffic!) and tried the ping again (this time to the filer again). This was the result:

Again:

WHAT.

This was incredibly puzzling. What this meant was that the traffic was correctly making it from the UCS server to the destination and back but was getting lost somewhere inside UCS. I double and triple checked all of the configuration in UCS and ESXi and everything looked right.

One more test, add a known working VLAN to the vIF/vmnic. This is where the shared array on the diagram comes in. I set up a dummy vmkernel port on that VLAN and pinged the shared Storage System and guess what; IT WORKED. So, what did this mean. This means that by any logic we had ruled out both the transit network AND UCS. That was impossible though since it clearly frames were still getting dropped somewhere.

My feeling at that moment can only be described by this meme:

There had to be something strange going on, something we had over-looked. To save anyone else the 20 hours of rage I think it is best if I just skip to the end.

The Solution

This is the part of our story where its time to talk about Ethernet frames and VLAN tags briefly. First, this is an great diagram of an ethernet frame (from this awesome NetApp article):

The important part about this frame is the VLAN tag, a 4 byte section added to the frame when using tagged VLANs, which we are in this environment. Diving into that 4 bytes there are two parts, the first 2 bytes are the Tag Protocol Identifier (TPID) which is always set to 0x8100 for 802.1q frames. The second two bytes are the Tag Control Information (TCI). The TCI bytes are divided into two parts, the first three bits are to hold the 802.1p identification information and the remaining bits hold the VLAN ID.

This diagram (that I lifted from here) illustrates this a little bit better:

Now, at this point it probably isn’t apparent why I bring this up, but here it goes. So back on UCS we have the definition of the storage vNIC as such, this time with the important lines marked:

vETH Running Configuration


fi01-A(nxos)# sh run interface vethernet 1841

interface Vethernet1841
  description server 1/3, VNIC stgA
  switchport mode trunk
  untagged cos 4
  no pinning server sticky
  pinning server pinning-failure link-down
  no cdp enable
  switchport trunk allowed vlan
  bind interface port-channel1378 channel 1841
  service-policy type queuing input org-root/ep-qos-Storage
  no shutdown

That QoS policy maps to the system QoS policy of Gold, which is defined as follows, again with the important part bolded:

CoS Gold Class Config


fi01-A /eth-server/qos # show eth-classified gold

Ethernet Classified Class:
    Priority: Gold
    CoS: 4
    Weight: 9
    BW Percent: 47
    Drop: Drop
    MTU: 9000
    Multicast Optimize: No
    Admin State: Enabled
ucpd01-A /eth-server/qos #

So, based on what we have learned about CoS and 802.1q frames, check out the network diagram with some more important information added:

Now, it took us quite some time to realize this and it ended up being an “ah hah!” moment from one of our network engineers but the issue was the fact that we were using an access port to do VLAN translation because CoS information is stored in the 802.1q part of the frame header.

So what was happening was the frames were traveling out and when they hit the first access port © the CoS information was lost when the VLAN tag was stripped. That was all fine until the frame made it back to UcS which dropped the frames on ingress to the Fabric Interconnect because without a CoS tag they were too large (being jumbo frames). This explains why regular frames worked but jumbo frames didn’t, the default CoS class allowed small frames through.

All things considered, the fix is simple, here are the updated access port configurations with the changes marked:

Customer side of uplink (B)


interface Ethernet1/29
  description cloud_access_a:eth1/17
  untagged cos 4
  switchport access vlan 60

My side of uplink (C)


interface Ethernet1/17
  description customer_switch_a:1/29
  untagged cos 4
  switchport access vlan 2244

With those changes in place, success!

Success!


~ # vmkping -s 2500 -d 10.0.0.253
PING 10.128.160.253 (10.0.0.253): 2500 data bytes
2508 bytes from 10.0.0.253: icmp_seq=0 ttl=255 time=0.232 ms
2508 bytes from 10.0.0.253: icmp_seq=1 ttl=255 time=0.198 ms
2508 bytes from 10.0.0.253: icmp_seq=2 ttl=255 time=0.265 ms

--- 10.0.0.253 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.198/0.232/0.265 ms
~ #

This was quite an interesting issue and it caused me to learn quite a bit about how ethernet works in general and as well as how UCS switches.

Another way to solve this is to set the default QoS class to accept jumbo frames but while this would have allowed the traffic to flow it may have caused other performance issues in the future in the event of fabric contention as the traffic would have not been prioritized correctly.

I hope this helps someone else that may run into this in the future!

Alert: Firefox 30 is not a supported browser for vCloud 5.1.x

Thu, 19 Jun 2014 00:00:00 +0000

Update (8/4/2014): I have created a tutorial on how to create a ThinApp package to help get around this, check it out!

If you suddenly start seeing something the following error in vCloud Director 5.1.x:

This is because your Firefox upgraded to Firefox 30 automatically, as it does. This error seems to be due to some sort of change that Mozilla added into Firefox 30, I haven’t tracked it down yet (if anyone has let me know!). Even force enabling the plugin won’t help, Firefox 30 looks to have gone to an whitelist only model, doing so will make this error go away but the console sessions never connect.

That being said, VMware has stated that Firefox 30 will not be a supported browser for vCloud 5.1.x (the VMRC plugin doesn’t actually function so it is not a question of only supportability). Unfortunately it is also not supported in IE 10, 11 or Chrome 35 so the only option is really Firefox 29 (or Firefox 3.6). The only solution is to upgrade to vCloud 5.5.x, which while true isn’t really a solution.

As a note, I have had success using ThinApp to isolate a Firefox 29.0.1 with the VMRC plugin, Flash and Java and Portable Firefox may be an option too. Either way, be sure to disable auto-update (Firefox Options -> Advanced -> Update) if you downgrade to Firefox 29.0.1. There are some tips here on how to do that, the big one being the ‘-no-remote’ option to allow the ThinApp Firefox to launch its own process.

Update: It seems that installing the Firebug plugin and enabling that will allow the console to connect in Firefox 30 after forcing the plugins to activate. While cumbersome, this is another workaround.

Update 2: (7/29/14): I have found another solution! It is possible to use the Portable Firefox ESR Version (Extended Support Release), this is a Firefox 24 package that will run in a sandbox. It will use the installed plugins on your system so if your Java version is also incompatible that won’t work. One thing to change, perform the following:

Locate FirefoxPortable.ini in your extracted ESR download (might be in Other/Source directory).
Copy to the root of Portable Firefox ESR install directory
Edit file and change the “AllowMultipleInstances” variable to true.
Save

This will allow the Portable Firefox and Installed Firefox to run at the same time.

Alert: Java JRE 7u51 breaks Everything

Mon, 27 Jan 2014 00:00:00 +0000

Update (8/4/2014): I have created a tutorial on how to create a ThinApp package to help get around this, check it out!

This morning it came to my attention that my customers were no longer able to upload any media (OVFs or ISOs) to their vCloud catalogs. This seems to be due to the most recent Java JRE version released by Oracle. The behavior I experienced was that the applet would appear to load but when I would click on the browse button nothing would happen. This happens across all different browsers and browser versions. The reason for this seems to be a change in the requirements for certificates and applet signing in JRE 7uU51.

Luckily, there is a quick workaround for this:

Open Configure Java control widget, navigate to Security then Edit Site List.

Type the URL for your vCloud instance in the blank and Click Add to add (repeat for multiple URLs), click OK

Thats it! This really is a workaround, I am not sure what the final solution will be but this got my customers and I back into business for now. If anyone has more information, let me know!

Update: It seems that this update actually breaks everything from HP iLO to vCenter Orchestrator, I am still searching for a better workaround if anyone knows of one.

Update 2: There are reports of this breaking Cisco UCS, Dell iDRAC, vCloud VPN and EMC Unisphere as well. It might be safe to say that most Java based management tools are going to be effected. VMware has released a KB article about their parts of it, check it out here. One interesting thing in the KB is that the upload portion of this issue does not effect vCloud 5.5 as this uses the Client Integration Plugin.

Update 3: Setting the security level to “Medium” also seems to work for most things.

vOpenData Update – Dashboard v2.0

Wed, 08 May 2013 00:00:00 +0000

A few days ago I pushed live a new update for the vOpenData Dashboard which included a few interesting things from an application perspective, I wanted to highlight some of them here.

###The Code

The first major thing is that the first version of the dashboard was written using a framework called Dashing which is a sweet frame work for developing dashboards from any datasource really quickly but, as it turns out, is not great at efficiently handling hundreds of connections.

Because of this I re-wrote the dashboard from scratch using a simple Sinatra app, it ended up only being about 40 lines of actual logic (not including the HTML part) to get the job done, pretty awesome.

This simplicity also allowed me to throw some memcache caching up infront of it to handle just about any traffic I can throw at it. I actually tested up to 250 hits/second using blitz.io and it functioned flawlessly. Awesome.

I also used a totally sweet framework called isotope to do the layout of the tiles on that page that will allow me to do some even cooler things in the future. One thing I did add though was the ability to filter by category, just click on the buttons in the toolbar to drill down a little, you can get views like this for LUNs:

###The Stats

In this version we wanted to bring to the front a few new stats, most importantly being the storage vendor statistics.

Storage Stats – These stats may be interesting to some folks as NetApp is not among the top storage vendors on this list. My theory on this is because NetApp admins typically (from my experience) provision large NFS volumes versus smaller VMFS volumes. This stat is based on the number of LUNs not the total storage provided by each vendor (which would also be interesting to see, that will come later) so this list did not really surprise me personally. As a little tease for what is to come, I included a screenshot of the top 15 vendors sorted by amount of storage, interesting results as well.
Environment Types – Another thing we decided to add was a breakdown of the environment types that we have gotten so far. We thought this would be a great thing to display as it would give everyone an idea of what kind of data we have so far and who we need to bug as a community to upload. I was happy to see that we had a huge portion of the environments being from production server based infrastructures, awesome work.
Host Hardware – We increased the number of host vendors to 5 (after many asks from all of you!) and this shows basically what I expected as well. I did expect Cisco to have a higher percentage but I suppose those are the larger environments that may not have reported in yet.
Country Standings – One note about these, I was actually not calculating these correctly (dividing submissions by number of users, doh!) so that is why these seem to have changed drastically. The data is the same, I just am mathing correctly now.

###Data Curation

People were asking if we combine DGC (EMC Clariion based storage) and EMC?

It seems like the census is to spend some time curating the data, combining Dell and Dell Inc for example, so I will be working on some code to do that as part of the next update. This will probably be asynchronous (run as a job on the whole dataset as a whole on a schedule) so it won’t necessarily do it instantly on upload, this is to keep the time it takes to insert the data to a minimum.

###The Future

Next up, the future. I have been doing a lot of thinking about where to take this project in the future. I was really astounded by the response that we have gotten from the community, you all have blown me away. I really have some cool ideas for this project that I am not quite ready to talk about but I think everyone will really love.

My goal is to be able to give everyone the ability to mix this data as they want to see what the community can come up with with all of this data, I am sure some of you have some amazing ideas. If you do have anything in particular send me an email and I would love to chat about it.

I also am looking to give some filtering and mashing up of the data on the private dashboards to narrow the scope of some of the averages, I know that is what people are really looking for.

One more thing (channeling The Steve), the Microsoft sized gorilla in the room. I have thought about the ability to gather stats from other vendors environment in a similar manor to compare and I think this would be really amazing. If any one is (or knows of) a rockstar that can work with the Hyper-V, Citrix, or OpenStack APIs get them in touch with me on twitter or by email.

Until then my head is going to be buried in refactoring and improving the main site codebase to get something really great out to the community, stand by.

vOpenData – Crunching Everyone’s Data For Fun And Knowledge

Fri, 12 Apr 2013 00:00:00 +0000

It has been quite some time since I have gotten a chance to write on this blog but recently I was able to work with Willian Lam (@lamw) on a really awesome project so I thought this was a great opportunity to start up again. This project really started from a tweet by Duncan Epping (@duncanyb):

This really got me thinking, I get asked these questions all the time and there really isn’t a good answer to it. Since I am going to need to answer this question more often in the future I decided that I would take on this challenge, thus vOpenData was born.

First a little about vOpenData:

###What is vOpenData?

vOpenData is an open community project that grew from the question “What is the average VMDK size for deployed virtual machines?” We wanted to create an open community database that is purely driven by users submitting their virtual infrastructure configurations. Leveraging the powerful virtualization community and applying simple analytics we are able to provide various trending statistics and data for virtualized environments.

###What information do we collect?

We made an effort to not collect specific information such as hostnames or even display names that could be used to identify a particular organization. Instead, we are using UUIDs which are automatically generated by the virtualization platform to uniquely identify a particular object. This allows us to keep track of changes in the our database when a new data set is uploaded from an existing environment. In addition we are collecting various configuration data and you can find a complete list in the Data FAQs

To see more detail on the project and how to get involved, see the Virtually Ghetto article here: VirtuallyGhetto

I am really excited to see what data everyone is able to provide. The one thing that you will notice is that not all of the statistics are available on the public dashboard; this is to try and get you to get involved by uploading data. There will be a myriad of statistics and reports that we plan on making available to people that upload data into the system.

Now for some gory details, that is why we are here, right? So, to solve this problem in any type of speedy manor I needed to use a tool that was designed for rapid prototyping and development. I recently finished another project using Ruby On Rails so I elected to use that. Going forward I will assume that you have a basic understanding of Ruby On Rails, if not read about it here.

###The Code

With Ruby On Rails I was able to develop the entire application with very little actual code written. In fact there is a built in tool for just this; here are the stats:

From this you can see that I only had to write about 1000 lines of code for this project, which is really awesome. This doesn’t include the rake tasks that actually calculate the stats, these were another 400 lines or so but are nothing overly complicated.

Another tool that saved me a ton of time was using the Twitter Bootstrap layout framework. (More here) This allowed me to quickly build out a usable and good looking interface in no time, if you have never used it I totally recommend it. Also, there are a few sweet add-ons that allow quick theming of applications; this is a great collection.

Another awesome feature of rails comes from ruby and that is the plug-ability of the gem system. Because of this I was able to use a few select libraries to stand on the shoulders of giants and get this project rolling quickly. My basic stack included the following gems:

I recommend checking all of those projects out, there are some really smart people behind all of them.

###The Platform

The next issue I had to solve was that of hosting all of this data. Due to the fact that I am a lazy sysadmin and have little free time I elected to use a PlatformAsAService (PaaS) for this project so I didn’t have to spend any time building servers, the one I chose was Heroku.

I picked heroku for the following reasons:

Its fast.
It’s quickly scalable, I can add worker and background processes on demand with little effort.
It’s pluggable, I can easily integrate it with many services like RedisToGo (for Resque) and Postgres.
My default avatar was a Ninja (Ok, not really)

The quick and dirty is that heroku allows you to build a rails app locally and push it (using git) to their production stack with no effort. This allowed William and I to rapidly update the code and discuss changes in near real time. The detailed explanation is lengthy and warrants its own article, more on that later.

Once I chose heroku I needed a place to store all of these uploaded CSV files until I could get them processed (a lengthy process which is done in the background). For this I chose the venerable amazon S3, there was a pretty good plugin (Paperclip) that easily handles the amazon process and allows easy local caching of the files on the workers while they were running. The basic data flow is this:

You upload data to vOpenData
The data is copied to S3 for temporary storage
When your infrastructure’s turn comes up in the queue the data is cached on the worker instance
The worker inserts the data into the database

Basically for this project S3 is just acting as scratch space until the data can be chunked into heroku.

The last piece of this project was the public dashboard. For that, William came up with an awesome tool by Shopify called Dashing. Dashing is a basic rack app that runs scheduled jobs to fetch data from an API and push them to a live dashboard.

That is basically it, if there are any specific questions leave them in the comments and I will answer them, I am also interested in writing a few follow-up articles if the demand is there to explain some of the code in depth.

William and I submitted a VMworld session to talk about the data that we have collected so far and get feedback from the community, it is “4976 – vOpenData – Crunching Everyone’s Data For Fun And Knowledge” so be sure to vote for it!

One last thing, we plan on adding lots of incremental changes over the next few months to add more features (like more dashboards and data rollups!) so be sure to follow myself (@wazoo), William (@lamw) and the vOpenData (@vopendata) user on twitter to get updates!

Tutorial: 802.3ad Port Configuration with ESX

Wed, 05 Aug 2009 00:00:00 +0000

Just wanted to post a quick post about how to configure 802.3ad port consolidation with a Cisco switch and VMware ESX (vSphere was used for this example). I was using an HP DL380 with 2 onboard NIC and 2 24 port Cisco 3750G connected with stackwise cables.

Switch Configuration:


…
interface GigabitEthernet1/0/1
description ESX NIC 2
switchport trunk encapsulation dot1q
switchport mode trunk channel-group 1 mode on
end
…
interface GigabitEthernet2/0/14
description ESX NIC 2
switchport trunk encapsulation dot1q
switchport mode trunk channel-group 1 mode on
end
…
interface Port-channel1
description ESX PortChannel
switchport trunk encapsulation dot1q
switchport mode trunk
end
…

What I did was group two gigabit ports (1/0/14 and 2/0/14) into one port channel group (1). Then I applied the trunk settings to the port channel instead of the individual ports. As for the ESX side, I configured the virtual switch with more than one active adapter and set the “load balancing” to “Route based on IP hash.”

If this set up would not have been using a trunk, the following configuration would have been used:


…
interface Port-channel1
description ESX PortChannel
switchport mode access
switchport access vlan 
end
…