I just found these today. They are not new, but they are very useful and I wanted to share them:
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!
As anyone that has taken any type of IT certification test knows, I cannot quote actual questions, but I wanted to write a post about what I used to prepare for the exam and offer some post exam guidance.
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!
This tutorial is intended to explain how to configure syslog on both ESX and ESXi to point to a remote syslog server (for this tutorial I will be using vSphere, but the concepts apply to earlier versions as well as many*nix distros). In both cases the configuration is fairly simple, but can be confusing. I also wanted to include a sample configuration that I use for syslog-ng which is an excellent logging platform for syslog.
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:
Click To Enlarge
I added a line at the end of this file that has the following contents:
*.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:
Click To Enlarge
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”
Click To Enlarge
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
Click To Enlarge
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:
Click To Enlarge
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:
Click To Enlarge
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:
Today I was setting up Exchange 2007 on a VM in a test lab and I came across this when I was running the Best Practices Analyzer:
Click To Enlarge
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!
Audience: Seasoned IT Professionals
Read Time: 10 Min
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):
Click to zoom.
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 10×8gb 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:
Click to zoom.
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.
I have started to write a series of “New User Guides” to help new users become familiar with virtualization and cloud computing. The first is What Is Virtualization?. This guide and future guides can be found using the New User Guides section in the navigation. Enjoy!
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/14
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.
Much of the time in class today was spent talking about scalability. Scalability is an interesting game because there are many ways to build scale into an infrastructure.
One approach is to build fewer, higher powered hosts. This is known as “scale up” architecture. With this architecture there are fewer hosts to manage and a higher virtual machine density. One obvious disadvantage to this is that any single host failure will have a greater impact on the overall infrastructure. Another approach is to build many lower powered hosts. This is known as “scale out” architecture. With this architecture there are more hosts to manage. However, virtual machine density will be small, so a host failure will have less of an impact on the overall infrastructure.
In my opinion, there needs to be a combination of both. There is a delicate balance between scale up and scale out. Too much scale up and there is a greater chance of a failure taking down a critical service. Too much scale out and the density of virtual machines becomes so low that virtualization almost becomes meaningless (aside from the benifits of high availability). I believe this balance will be different in every environment. It is the most important piece of information to determine in any project, yet it is often very difficult and can have long standing effects.
So the question becomes: scale up or scale out, or a combination of both?
Today I started VMware design class, which is shaping up to be a fascinating journey. The class really is affirming many design conclusions that I previously came to on my own. It also is bringing back many of the concepts taught in the ‘Install and Configure’ and ‘Deploy, Secure, Analyze’ classes, which is good to see. My assumptions and research have not been far off, which was good news for me.
One concept that the instructor keeps bringing up is to Know Thy App. What this means is that any successful virtualization project begins with a thorough understanding of the applications that are being virtualized. I never really gave it thought, but this is the most important part of being a VMware engineer: the understanding of many, many, many different applications.
An exceptional systems engineer knows three or four applications, and probably only one or two of them inside and out (obviously there are exceptions to this). An exceptional VM engineer really needs to know every application that would come in contact with his environment in extreme detail. For example, when an application developer comes and claims that virtualization is making their application slow, the VM engineer needs to have the knowledge to analyze their application on all levels and find the issue. The solution may or may not be at the fault of the virtual environment (my guess is it it’s not, but I’m obviously biased).
So, KNOW THY APP.
BeyondVM’s Shared Items