Here is what I came up with for challenge #1:

#!/usr/bin/env ruby
x = 0
(1..999).each do |num|
	if (num.fdiv(5).to_i.*5) == num || (num.fdiv(3).to_i.*3) == num
		x = x+num
	end
end
puts x

I am going to work on one problem per week, my progress can be monitored here and the Git repo for my code can be found here.

1. ESXi does not have all of the same features that ESX does.

Verdict: False

From a virtualization standpoint, ESXi has all of the same features that ESX does – they actually are the same hypervisor – so, any function that you want to perform on ESX, you can do on ESXi. The major difference lies in the way that the software is managed.

2. I need to buy different licenses for ESXi, the ones I have for ESX wont work.

Verdict: False

The license keys for ESX and ESXi are the same and they will unlock the same features. Enterprise Plus with ESX has the same features as Enterprise Plus with ESXi.

3. ESXi is free software and I do not need a license to run it.

Verdict: Both

ESXi is available as free software to be run as a standalone host. These free licenses cannot be managed by a vCenter server and must be managed as individual hosts. Another important detail is that the free license causes the API to grant read only access. This means that any fancy scripts that you can use to automate ESXi probably won’t work. You can license ESXi to any of the license levels to unlock these other features – it is available in several editions (this chart does not include the free edition).

4. Management of ESXi is harder and there are no tools available to manage it.

Verdict: Both

Some people consider ESXi a harder platform to manage because of its lack of service console. However, I consider this a benefit because there is less surface area to manage and secure.  From a management standpoint, ESXi is becoming much more like an appliance. It is often quicker to just wipe the installation and reconfigure a server than it is to figure out what is wrong with it (this is even more true with access to the host profile feature). VMware has many tools available to manage ESXi in addition to vCenter.  Also, from the standpoint of vCenter, the management is the same as a classic host and the two can share the same cluster and resources.  Also, another benefit: the install is ~40mb and takes about two minutes.

5. I cannot automate the installation of ESXi hosts like I can with ESX.

Verdict: False

As of vSphere 4.1, ESXi supports a scriptable installation similar to kickstart that will allow you to make some configuration changes on install and through post-install scripts.  Using this (as well as host profiles) and PowerCLI, it is possible to deploy a large environment much more rapidly than with ESX due to the faster install time and quicker boot time of ESXi.

Those are most of the major misconceptions that I have heard most frequently. If you hear of a good myth or have a question leave a comment and I will write another entry!  Now go forth and virtualize on ESXi – have no fear.

For additional information, VMware has an great KB for a side by side comparison of vSphere 4.1, links to other versions are at the bottom of the article.

VI3 Refrence Card

vSphere Refrence Card

They are basically an all-in-one reference cheat sheets for managing both VI3 and vSphere.  I plan on getting one laminated for myself to keep around for a while.  These will defiantly become part of my reference library and I will recommend them to my clients and contacts for sure.  Thanks Forbes for spending time on those!

This exam differs from the VI3 test in a few ways. First off, it is now 85 questions versus the 60 of the VI3 test.  It also seemed to ask for a more in-depth understanding of the software including some terminal commands (firewall related).  I have updated my VCP page with the information below as well. Document titles are links (need to fix the CSS, apologies).

I would study the following documents from VMware:

Configuration Maximums for VMware vSphere – This is probably the most important document that you can commit to memory. Many of the questions will be indirectly asking questions about a maximum.

Basic System Administration- This is the VMWare document that talks about administration of a virtual infrastructure on a broad scale. It will help re-affirm what was taught in class about the administration of a virtual infrastructure.

ESX and vCenter Server Installation Guide- This guide covers the installation of ESX and vCenter.  The partitioning section for ESX is of particular importance.

ESX Configuration Guide – This document covers the configuration of ESX.  The sections of most importance are the networking and security sections.

Resource Management Guide - This guide offers in-depth discussion of resource management in vSphere.

I used the following additional resources:

Simon Long’s vSphere Study Notes – The most complete VCP study guide I have ever seen. It has direct links to each part of the exam blueprint.

Simon Long’s Practice Tests – These are great exams. The questions are in a format similar to the actual exam and he is adding questions all the time.

VMware Mock Exam – This is the sample test from VMware. In my opinion it is not as thorough as Simon’s, but it is another practice test none the less.

I hope that information helps.  Simon’s blog is really an invaluable resource for preparing for this exam.  Thanks Simon!  As with any exam, go in with a strategy and take it slow.  Good luck!

ESX

First, I have a single host with ESX 4.0 installed and configured with a service console IP address.  I have connected to this IP address with putty over SSH.  Once logged in to the ESX server, there are just a few steps that need to be taken. Also, I use the VI editor – check on google for more information on VI and its commands. I am going to assume that readers posses a basic knowledge of this.

1. First, edit the syslog configuration file (/etc/syslog.conf) by typing:

vi /etc/syslog.conf

The display will look similar to the following:

*.debug                                      @<ip of syslog server>

What this will do is send syslog messages from all facilities and levels to the IP address of the server following the @ symbol.  One caveat with this line is that the space between the *.debug and the @ symbol must be the tab character.  If not the syslog daemon will simply drop the line.  If you desire more than one destination, just add another line with a different host after the @ symbol. 2. Next we need to restart the syslog service, to do that enter one of the following:

service syslog restart or /etc/init.d/sysog restart

The display should look similar to the following:

If there are any errors at this point, troubleshoot accordingly.

3. Next we need to open firewall ports for the syslog traffic.  We are not able to do this through the service console, so we must do this at the command line.  It is a pretty simple command and if it is successful, it won’t produce any output.

esxcfg-firewall –openPort 514,udp,out,”Syslog”

4. Next we need to reload firewall rules on the server and then verify that the rule was added.  For this, we need to type in two commands. The first one reloads the firewall (this will not produce any output if it is successful).  The second one will query the firewall for all active rules and will produce a lot of output. The two commands are:

esxcfg-firewall -l esxcfg-firewall -q

The output outlined in red indicates the rule that we added.  This change is not visible in the GUI – the only way to verify these changes is via the command line.

ESXi

This configuration is much simpler – you only need to change one variable in the advanced settings.  One downside is that ESXi is limited to one destination server However, there are other ways to get around this (via syslog relays). In ESXi the following configuration can be found by clicking on your server, then navigating to the configuration tab and then clicking on “Advanced Settings” under the Software Settings section.  Once that window is open, there is a syslog section near the bottom.  Expand that section and click on “Remote” and fill in an IP address or hostname in the box for the variable ‘Syslog.Remote.Hostname” and click save. 

Screenshot:

Bonus I wanted to include a sample syslog-ng config section for syslog-ng which is what I use to collect my syslogs and sort them accordingly.  Syslog-ng is awesome because it allows much greater flexibility in the processing and archiving of logs.  The extended configuration of syslog-ng is a topic for another post, but here is the configuration I use for most hosts:

This configuration separates each server into an individual file by day according to the time from the source server (in this case the ESX server).  This gives file names like “vm0.09.02.2009.log”, which is great for log rotation.  Also note the “S_” infront of each macro; this tells syslog-ng to use the source information instead of re-writing the logs to the timezone of the syslog-ng server.  It is also possible to filter based on syslog facility, but I will cover that in another post dealing with the analysis of ESX logs.

Update: Videos! I am going to try and include videos of these tutorials, here is my first go at it so please be kind!

ESX:

Tutorial: ESX 4.0 Syslog Configuration [ESX] from Ben Thomas on Vimeo.

The bit outlined in red shows a warning stating that “VMware Detected” which is ironic since VMware is a supported platform for exchange to run on and there are many resources on how to configure exchange on VMware.  Just a funny find.  Tutorial on configuring ESX and ESXi syslog coming up soon!

There has been a lot of buzz about the new Nehalem processor and chipset family from Intel and how to optimize memory configuration for speed. I had quite a lengthy discussion with some colleagues at work on how to best organize the RAM to gain the most performance from the Nehalem’s 5500 chipset. I wanted to share some of what I found while researching. The Nehalem uses an integrated memory controller on each CPU with 3 channels and 3 DIMM slots on each channel. This gives most dual CPU servers 2 memory controllers (one per CPU) with 6 channels and 3 DIMM slots per channel (total of 18). This gives many, many MANY options on how to configure servers. My discussion today with my colleagues was about the HP BL490G6. Here is a great graphic from HP that gives us a look into the way the Nehalem is organized, it includes parts of the BL490 G6 (click to enlarge):

With the Nehalem, I like to stick to non-fully populated memory because of the benefit from the increased memory bandwidth when all channels are not in use.  When using all 18 DIMM slots the bus speed is downgraded to 800mhz compared to the fastest at 1333Mhz with only a single slot per channel occupied.  Having the bus speed at downgrade to 800 Mhz from 1333 Mhz bus is almost 40% less throughput overall which is a considerable jump.

Now I want to talk about all of this in relation to virtualization with VMware.  In this scenario I am going to be talking about using 8GB Dual Ranked Registered ECC DIMMS and the 95w versions of the Nehalem*, but the concepts can be applied to smaller or larger DIMMs.  The generally accepted rule of thumb is to have 2 vCPU per core (not a limit, just a good point to start from when planning). So, assuming that I am going to run 1vcpu per VM (statistically most VMs only require a single vCPU), then that is a starting point of 16 machines on each blade. With 2gb of RAM each (again, an average point to start from), 32gb of RAM would be required (however, in an ideal situation I would want to double that so physical hosts are running at 50% in case of a disaster situation causing a host failure).

One issue with using 64gb (Scenario 1) is that it would give us non-uniform memory distribution across memory channels** so the next logical move would be to 80GB of memory (Scenario 2), which would be 10x8gb memory modules – still allowing for expansion and giving us the extra bus speed over 800mhz.  This again presents an issue; 80GB would create a non-uniform memory distribution situation across CPUs/CPU Cores (80GB / 2cpu / 3 channel comes to 12 which cannot be divided by 8GB DIMM modules evenly across channels), which is less than ideal. In the end (Scenario 3), 8GB of memory per channel per CPU is 48GB, 24 per CPU, 6gb per core and will use the fastest bus speed. This is probably more than adequate for most designs because the next move there would be to 96gb which is probably overkill for most environments.  The 50% overhead margin will be decreased by adding more blades to the cluster, thus the load from a single node failure can be spread out more evenly. Here are a few tables summarizing that last paragraph so it makes more sense:

Scenario 3 and 4 illustrate how to get to 96 GB in the interest of cost savings and speed respectively.  Either of these scenarios I would consider acceptable – I just want to stay away from the 800MHZ speeds due to the huge performance loss.  There really isn’t a wrong way to go about implementing servers based on Nehalem, it just requires some forethought to achieve the best results for each organizations goals.  Both Intel and VMware (as well as most server vendors) have best practice white papers published on this subject so be sure to check with them as well.  I would be interested in hearing about anyone’s experiences with Nehalem and also anything that I may have missed. Leave a comment or drop me a note!

*-HP does offer the BL490c with 1333MHZ bus using 6 DIMMS, but this was not the origional design of the chipset. The 95w processors are required to achieve the 1333MHZ bus speed. ** – It is desirable to have uniform distribution across memory channels and CPU cores because this will then require less calculation on the part of the hypervisor to place work loads.  This is also much more efficient for the hardware as a whole.

…
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 <vlan for port group>
end
…

This configuration has seemed to be fairly reliable. I plan to do some load testing to investigate how balanced the load really is. I will post a follow-up if there are any interesting findings.