It’s great to announce the release of the new Mastering vSphere 5.5 book.
This is the updated version of Scott’s long revered mastering title, with all-new content covering vSphere 5.5. In this latest revision, industry leading virtualization experts explain new features such as VSAN, vFlash, and AppHA, along with the countless enhancements since 5.0. Everything from vSphere 5.5 (and 5.1) has been added. Mysteries around certificates and single-sign-on (SSO) are examined, and the book lays out the best paths for installing each component.
Despite the minor sounding update, 5.0 to 5.5; this new edition is a substantial rewrite. Scott was joined by Nick Marshall who lead the charge. Nick is a VMware PSO consultant based in Australia but most well-known for his work with the vBrownbag community. He has worked tirelessly this year to update the book and get it released into book stores as close to the official release date as possible. Like the book’s 5.0 predecessor, I had the great honour to join Nick and Scott’s efforts as a contributing author. Alongside me I was joined by the business critical applications (BCA) guru, Mr Matt Liebowitz; and the wizard of all things powershell and automation, Mr Josh Atwell.
Wow, what a technical writing line-up!
We’re all immensely proud of this book and truly believe that it’s a great resource for learning about vSphere 5.5. We hope you snag yourself a copy and enjoy reading it as much as we enjoyed writing it.
This is the third part in a series of three articles describing how I created a basic DNS/DHCP/NTP server for my lab that only uses 24MB RAM and 12MB disk space.
Setting up the services
If you’ve followed parts 1 and 2 correctly, you should be able to hit the web-based GUI now. By default you can access this on any of the interfaces configured. Log in with the root account and the password you just set.
Clicking on the Network tab, followed by the Interface tab, shows the three interfaces that were manually configured in the
/etc/config/network file. From here you can add new interfaces and edit existing ones.
Configuring the OpenWRT instance to act as an NTP server is very straightforward. On the System > System tab, you can set the hostname and timezone. The Provide NTP server checkbox turns the OpenWRT VM into a local NTP server. The Enable NTP client checkbox keeps it’s local time synced with external time servers. You can set pool servers here as well. My lab is completely isolated from the outside world so I don’t set pool servers. If the time is out, I use the Sync with browser option to update it, which will then correct all my downstream devices. In the real world having accurate time is important for things like log files, but in my lab the important thing is that all the devices have the same time – this NTP server does that.
Once any changes have been made in the Web GUI, click Save & Apply in the bottom right corner.
General DHCP and DNS settings
On the Network > DHCP and DNS tab there are some general settings which apply to all the interfaces. If you can tick the This is the only DHCP on the local network then do so. Making it authoritative will speed up how quickly the clients get their leases. The Local Server setting is how non-FQDN hostnames get resolved by DNS, and the Local Domain setting is the default domain setting given out to DHCP clients.
The next section show the active DHCP leases. The last section is where you add your static DHCP reservations.
Each interface can be associated with a DHCP pool. On the Network > Interfaces page, click the Edit button next to the VLAN that you want DHCP leases to be provided. Below the Common Configuration section, is the DHCP server section. On the General Setup tab, the first checkbox will disable DHCP if ticked. Assuming this is a subnet where you want a DHCP scope, leave this unticked. You then set the starting address (for example 100 to start at x.x.x.100 on a /24 subnet), the number of leases (for example 99 which will make the pool x.x.x.100 to x.x.x.199), and the duration of the leases.
On the Advanced Settings tab you can set the subnet mask and the scope options given out with each lease. In the screenshot below I’ve set option 3 to explicitly state the default gateway, and option 6 for the DNS servers.
Remember to hit Save & Apply at the bottom of the page.
To set the DNS A records, select the Network > Hostnames tab and add in each record.
To review the entire DNS and DHCP configuration, log into the console and take a look at the configuration file
One last thing to do before finishing up. Click on the System > Backup/Flash Firmware tab. From here you can get a configuration backup exported as a compressed tarball. This is not only useful if you need to rebuild the server, but it’s an easy way to review all the important config files (it’s just a dump of those files in an archive file).
When I get my SimpliVity sponsored Raspberry Pi delivered, I’ll try to follow up with another post to explain how to install OpenWRT on it.
This is the second part in a series of three articles describing how I created a basic DNS/DHCP/NTP server for my lab that only uses 24MB RAM and 12MB disk space.
To install OpenWRT as VM, start by downloading the latest version. At the time of writing the latest version is the 12.09 release from April 2013. A pre-build virtual disk image is available from here:
In your vSphere Web Client (or Windows Client) create a new VM. I based it on Ubuntu 32bit.
Before powering on the VM, upload the openwrt-x86-generic-combined-ext4.vmdk image to the VM’s datastore folder. Then edit the VM’s settings to reduce the vRAM down (I run mine with 24MB, but you can probably go lower), make sure that only 1 vCPU is configured, delete the VMDK that was originally attached during the creation process, and attach the OpenWRT disk.
Now that the install is complete, onto the configuration.
Power on the VM and you’ll be faced with some console output:
enter and the command prompt is displayed:
Set the password
First thing you’ll probably want to do is to set a password. By default the console will log you in as root and no password is required (it’s blank). So on the console:
This ensures that the web interface, once it’s reachable via an IP interface, will have some protection. This by itself doesn’t force a login at the console. This is a lab so I’m not that concerned, but if you want to set this up there is a script here. (I think the reason is the OpenWRT image is primarily aimed at home routers, and you’d only see this if you were attached to it via a console serial cable. Telnet and Web access forces you to log in.)
Please note: I’m only going to discuss the configuration of the VM and the host it sits on. How your hosts are connected to their switch, how the switch is configured and what it’s capable of (layer 3 switching?) is up to you.
Ordinarily, at least couple of interfaces are created (not including the loopback interface):
wan and they’re bridged together. But because we built a standard VM which only has a single vNIC, then only the
lan interface is created. This is exactly what we want because we’re not planning on using this appliance for routing or firewalling traffic (although you could if you wanted to).
By default the
lan interface is set to 22.214.171.124/24 so if the VM is on a subnet that you can connect to via this IP, then you should be able to connect with a web browser and configure everything in the GUI.
However, I want to set up DHCP for several trunked subnets and I’ve found it much quicker just to enter this straight into the config file from the outset. Here’s how I set it up.
I changed the
lan (eth0) interface to remove the bridging and set the IP address appropriately.
I also added two virtual trunked interfaces (
vms). The syntax to do this is eth0.x where x is the VLAN ID. For each virtual interface give it a name and an appropriate IP settings for that VLAN’s subnet. My
lan interface doesn’t need VLAN tagged as it sits on the switch port’s default VLAN (PVID).
Here’s how I configured mine:
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0'
config interface 'lan' option ifname 'eth0' option proto 'static' option netmask '255.255.255.0' option gateway '192.168.1.254' option ipaddr '192.168.1.99'
config interface 'mgt' option proto 'static' option ifname 'eth0.1000' option ipaddr '10.0.0.99' option netmask '255.255.255.0' option gateway '10.0.0.1'
config interface 'vms' option proto 'static' option ifname 'eth0.1003' option ipaddr '10.0.3.99' option netmask '255.255.255.0' option gateway '10.0.3.1'
Top tip: in
viyou can use
yyto copy (yank) a line, and
pto paste it.
Once you make any changes to the
/etc/config/network file, you need to execute:
to stop and restart the network interfaces.
VM’s trunked connection
In most cases these days, a VM is a connected to a port group in ESXi using Virtual Switch Tagging (VST) – remember the contents of this classic white paper. But here we’re getting the guest OS in the VM to tag the traffic. We don’t want the port group to act as an access port, but we want it to act like a trunk port, sending and receiving traffic on multiple VLANs. To do this, create a new port group and set it to VLAN ID 4095:
and set the port group as promiscuous:
Now, if everything is set correctly you should be able to ping each interface from something in each subnet (or from anywhere if you have layer 3 switching in your lab).
In the next post I describe how to configure NTP, DHCP and DNS services in OpenWRT.
This is the first part in a series of three articles describing how I created a basic DNS/DHCP/NTP server for my lab that only uses 24MB RAM and 12MB disk space.
I’ve been building a new lab environment recently and wanted a small infrastructure server that could sit permanently in the management cluster and provide basic services such as DNS, DHCP and NTP. The lab will host multiple different testing environments, often for short periods of time. I use the ever awesome Autolab to rapidly provision new setups. Autolabs are self-contained, so they provide their own Active Directory (AD) domain controller (DC), which in turn includes DNS/DHCP/NTP, along with their own vCenter and nested hosts. But to save a considerable amount of rework after I’m finished with each test environment, a management cluster will provide the base services I need and can remain in-place through each cycle. Chris Wahl has a lengthier post espousing the benefits of such a strategy.
Why vCSA instead of a windows-based vCenter?
- They both use similar amount of resources – you can happily run it on 3GB vRAM for a small lab
- Autolabs use a windows-based vCenter, so I still gets lots of face-time with them
- vCSA is more stable in my opinion
- vCSA only takes a few minutes to deploy and is simple to update/patch
- vCSA doesn’t need a Windows license. This is a deal breaker for me. I don’t want to rebuild my management vCenter every 180 days (technet is going away)
So what else do I need in the management cluster? AD? I thought carefully about this because of the 180 day license timeout. And honestly, for the small amount of servers it simple isn’t worth it. Nothing in my management cluster needs AD, so why bother.
So without a DC I also lose other basic services that we take for granted, such as DNS, DHCP and NTP. In reality I could do without those as well. I don’t need DNS if I’m happy to use IP addresses everywhere in the management cluster. I expect most long term components will have static IPs so there’s no strict need for DHCP. It’s a lab so is time that important? (actually it can be, and it becomes particularly obvious in a more volatile physical/virtual lab environment). So perhaps I could do it all with just one vCSA and the physical hosts in my management cluster.
But I thought it would be handy to provide these simple services as I plan to spin up a number of associated management tools such as backup, monitoring, logging, etc. I know before long I’ll have a non-trivial number of long-term appliances that would benefit from these services. We live in the world of bespoke virtual appliances I thought – it shouldn’t be that hard to find a good solution just designed for this purpose. Surprisingly, there wasn’t an obvious contender.
Which tool to use?
I reviewed a number of options:
pfsense came highly recommended:
pfsense is small firewall appliance that comes bundled with lots of additional features. It only uses 128MB of vRAM so is sufficiently small for a lab and it has a nice web interface. Unfortunately I wrangled with it for hours and never got it to work properly. I kept putting it back on the shelf, looking at alternatives, picking it back up again; would get frustrated with it, and went back out to find something else. I’m sure it’s a great package, but it evidently wasn’t for me.
I was somewhat familiar with FreeSCO as it’s the “router on a floppy” VM that Autolab uses as its gateway device. It ticks a lot of boxes and runs comfortably in only 16MB of vRAM. It’s not the most handsome web interface but configuring it is relatively straightforward. However the functionality of the server services that I was looking to host were more limited on FreeSCO than the competition.
OpenWRT includes the dnsmasq package to provide basic DNS and DHCP functionality. This is a common toolkit and would satisfy my lab needs. (You can replace it with a BIND configuration should you wish a richer DNS option. OpenWRT packaging is handled by okpg which is very similar to dkpg so anyone familiar with Debian/Ubuntu should feel right at home.)
I’ve often thought about getting one of these Rapberry Pi devices, but could never come up with a good use-case (Xtravirt’s vPi looks interesting but I’m not convinced that it would be anything more than a toy for me). I then thought about the pfsense, FreeSCO and OpenWRT appliances I’d been testing. After some digging it seems that there is some preliminary support for OpenWRT on the Raspberry Pi. I thought how useful it could be to have a virtual copy on the first lab host that could travel with the lab (the Intel NUC hosts are very portable so they make an excellent mobile lab), and a small hardware appliance with a similar configuration (and no vSphere dependencies) when everything is static and ticking along. Very small footprint, low power, and plenty of geek cred!
The next post will explain how I installed OpenWRT into a VM and configured the networking for multiple VLANs.
VMworld 2013 starts in less than a week! Mr Scott Lowe and I will be presenting another design-focused session this year and we hope that you can all make it. Unfortunately I doubt we’ll be able to fit 20,000+ folk into the allocated room, so I’d suggest reserving a spot while there is still places available. The session should be useful for anyone that’s interested in vSphere design choices, those pursuing design-style certifications, or budding architects. This year we’re taking a case-study scenario and looking at how the design process helps us to examine the options hands-on. It should be a lot of fun.
VSVC4995 – Examining vSphere Design Through a Design Scenario
Led by authors Forbes Guthrie and Scott Lowe (co-authors of VMware vSphere Design and VMware vSphere Design 2nd Edition), this workshop-style session will provide attendees an insight into vSphere design by cooperatively working through a design scenario. The session will start with a brief review of key design concepts and the design process, then quickly move into a design scenario that will allow the audience to interactively participate and identify design requirements, explore various design decisions, and evaluate the impact of those decisions on the overall design.
- Session time: Tuesday 4 – 5 pm
Sign up without delay.
This a response to Gabrie van Zanten’s question – Design question: Why vCenter Server Datacenter?
To summarize, Gabe argues that the datacenter object in vCenter creates artificial limits on his operational abilities and asks why he shouldn’t just use folder objects across sites. Gabe postulates that perhaps the default for our designs should be to avoid multiple datacenter objects.
There are several reasons to use the datacenter object in your design. Primarily it’s there as a logical container for items that you want to create limits around. Yes, that’s right, you want to artificially limit mobility in the design because you recognize that those items have characteristics which should be contained. A folder object can contain those same sub-objects, but it’s precisely because you recognize that the physical equipment represented in the containers are best grouped together that you use datacenters.
To recap, the vCenter hierarchy is important for many reasons. Quoting from our VMware vSphere Design book:
The inventory structure creates a delineation that serves a number of purposes. It helps you organize all the elements into more manageable chunks, making them easier to find and work with. Monitoring can be arranged around the levels with associated alarms; events trigger different responses, depending on their place in the structure. You can set security permissions on hierarchical objects, meaning you can split up permissions as required for different areas and also nest and group permissions as needed. Perhaps most important, the inventory structure permits certain functionality in groups of objects, so they can work together.
It is not only VM mobility that is contained within a datacenter object. If you switch views in the vSphere client to Storage (called Datastores in the Windows client), you see datastores and datastore clusters are contained within a datacenter. You can create folders in there, but they are distinct to that view. Datacenter objects span each view. If you switch to the Networking view, datacenters are the containers for vDS and Port Groups. There’s a reason for this. The crux of datacenter objects, and what they do for you over and above folders, is logically explain where the network and storage boundaries are (and by association, host boundaries as well). Your design identifies these physical confines and implements it in vSphere using these logical objects.
- Where will you stretch your layer 2 networks?
- How far are you going to stretch your VMs from their storage (IP and/or FC)?
When you design your vCenter hierarchy, these choices are affected by things such as bandwidth, latency, storage fabric topology, etc.
If you recognise a datacenter as a separate physical location, then in the majority of cases you’ll split the location’s components into a separate datacenter object. There are certainly cases where this decision becomes less clear – for example, a campus-style design, where server rooms are only a couple of kilometers apart. The rooms are commonly recognized as two distinct sites (or not), but it’s feasible that with the right dark fiber links you could logical treat this as one datacenter. To quote from the vSphere Design book again:
Remember that despite the moniker, a datacenter doesn’t necessarily have to align with a physical datacenter or server-room location. However, network and storage connections do tend to be determined by geographical location, so it’s common to see this parallel used.
You can stretch layer 2 networks and storage across much larger distances, and this can provide very interesting highly available solutions, but this requires a substantial amount of planning. For example, during regular operations you don’t want your VMs’ disks on the remote storage array.
The vSphere datacenter object should be used in your design precisely because of the limitations it creates on your operational mobility. Without them, if you elect to only use folders, then you’ll need to create extremely complex operational processes to prevent problems. So I say, “by default, use datacenter objects to represent your datacenters” – they’re essential constructs in your design.
I’m delighted to reveal that the new version of the VMware vSphere Design book is now available from leading book stores.
The electronic versions are widely available now, and hard copies can be pre-ordered and should ship within the next couple of weeks.
This revised, updated, and largely rewritten second edition of VMware vSphere Design has been thoroughly overhauled to encompass all the great new changes that have been introduced in vSphere up to and including version 5.1. We’ve been blown away by the sheer volume of improvements and additions to this product. Every area of vSphere design has been affected deeply, and the revamped book reflects this.
In addition to the changing landscape of vSphere in the datacenter, the book now incorporates another key tenet of VMware’s datacenter portfolio: vCloud Director, its private/public cloud integration piece. This emerging technology is now deeply intertwined in the future of vSphere and becoming an essential skill for anyone currently involved or interested in vSphere design.
I’ve been asked several times if a book like this, which is so focused on design concepts, has really changed that much since the 4.x original edition. Well, for starters the book has grown around 150 pages – so right off the bat you can see there is a lot more goodness squeezed in. While I appreciate many of the fundamental principles remains, we poured over every section to ensure that it reflected the vSphere 5.x toolset. For example, chapter 2 in the first edition was based on the design choice of ESX or ESXi as the hypervisor. For this edition I largely re-wrote the chapter. It now dives under the covers of ESXi to explore how the image ticks, looks at how to deploy it across different environments, compares the design impacts of stateless versus installable ESXi, and how to configure and then manage the image. So yes, even if you have already read the first edition I highly recommend upgrading to this new release.
You can download the book’s introduction section here, which describes in detail what the book covers and why you’ll find it an essential addition to your technical library:
As with the first edition, we were very fortunate to have Jason Boche (blog/twitter) as our Technical Editor. I’d also like to personally extend my thanks to Maish Saidel-Keesing (blog/twitter); as an author on the first edition his involvement naturally bleeds through to this edition.
We’re all immensely proud of this book and truly believe that it’s a great resource for learning about vSphere design. We hope you snag yourself a copy and enjoy reading it as much as we enjoyed writing it.
This week I sat VMware’s VCAP5-DCD exam (and I’m proud to say I passed). As many have commented before me, time is real constraint (or is that a risk). I won’t list out the resources I used to prepare for it; suffice it to say that Gregg Robertson has an excellent post that covers this. Although I have heard about this fantastic design book out there…
Obviously I can’t reveal anything about the content of the exam, but I did want to highlight a small, but important change to the exam format that’s happened recently. The exam consists of a mixture of multiple choice, drag ‘n drop and a handful of Visio style questions. According to Jon Hall, VMware’s certification developer, these diagrammatic questions can account for around half the available points. The most common DCD advice I hear revolves around how to apportion your time to these few, but critical questions. The recommendation is that you skim through the exam once answering all the multiple choice questions and flag the rest. Then you can allocate the remaining time to the big and arguably more important questions. Personally I always read that advice and thought it was topsy-turvy; I was planning to tackle the diagrams first.
However the latest version of official exam blueprint, dated October 26th, has changed its wording and now states:
Once you have provided a complete answer or design for a given exam item and advanced to the next item, you will NOT be allowed to return to that item and the item cannot be flagged for later review. Please ensure when taking the exam that you have completed each answer and/or design before continuing to the next item. Drag-and-drop items and Design items will prompt you for confirmation that the item is complete before advancing to the next item.
Fortunately I noticed this the day before I sat the exam, but because I hadn’t heard anything about it in the community, I wasn’t sure how it would affect things.
Here’s what I found when I sat the exam. Right at the beginning of the exam, just before I hit the start button, the instructions page told me clearly that I was going to get 94 multiple choice and drag ‘n drop, and 6 diagram questions. I believe this ratio can vary, and I’ve heard folk getting only 4 or 5 of the diagram questions. As I progressed onto the questions each page only had a Next button. There was no option to go back, and no option to flag any questions. As the blueprint paragraph states, you get a confirmation dialogue box for the bigger questions to make sure you haven’t accidentally clicked next. On question 100, I picked my answer, hit next, and that was it. Straight to a congratulations/commiserations score page. So there is only one direction you can take and that is forward.
In retrospect I think it’s a good move on VMware’s part. I don’t like seeing these strategies float around that can give an advantage if you happen to know the special handshake. Now everyone is going to have to address the questions in the same way. It certainly resets the dynamic, and you really have to concentrate on how you want to spend your precious 225 minutes. I’ll be honest, there was plenty of multiple choice questions where I didn’t even read the scenario – I just scanned the actual question and selected what I thought the most likely answer was. There just wasn’t the time to analyse everything properly, and on these low value questions I had to take a chance. I literally finished with less than 2 minutes on the clock. I appreciate the need to test candidates resolving problems quickly, assessing their time management skills and keeping the pressure on; but to me this ability is more suited to break-fix scenarios. This is what the DCA is for. For me, design analysis should be more considered.
Anyway, forewarned is forearmed as they say. Hopefully some of you might read this and not be shocked when the first you realize of the change is when you’re partway through the exam.
Now that vSphere 5.1 has been announced, it’s time to update the reference card. Due to another project I’m working on, I won’t have the spare cycles to devote time to this for the next couple of months. Those of you who attended VMworld and caught the session that Scott Lowe and I presented, will know what I’m talking about. If you don’t know, don’t worry, I’ll write about the project here soon.
I expect that I’ll be able to start updating the card to 5.1 in November. What would great in the meantime, is if you spot anything which needs updating let me know in the comments below. If your feeling particularly focussed then grab a section, and try to list all the updates required and any new features which you think need added. I collate these cards and distribute them under a liberal license for everyone in the community to use as freely as possible. It would be great if we can get some feedback from the community itself this time around. Doing so will ensure that it’s released as quickly and accurately as possible.
P.S. I don’t plan on updating my Documentation Notes. I only update those on major releases, i.e. vSphere 4.0, 5.0, etc. I suggest you grab the 5.0 notes and supplement them with the latest What’s New in vSphere 5.1 whitepapers.
Following some great feedback from Brandt, Bjorn and Jakk recently in the comments, I’ve created a small update to the reference cards. Thanks guys! As ever, if you spot anything you think needs correcting or new changes that need applied then let us all know.
As usual, you can grab the latest copy over here.
- Detoks on vSphere 5 Card
- Forbes Guthrie on vSphere 5 Card
- Namma Karma on vSphere 5 Card
- Micro infrastructure server with OpenWRT – part 3 | vReference on Micro infrastructure server with OpenWRT – part 1
- Micro infrastructure server with OpenWRT – part 1 | vReference on Micro infrastructure server with OpenWRT – part 2
- Forbes Guthrie on Large Pages – a problem of perception and measurement
- Eduardo Aguiar on Large Pages – a problem of perception and measurement
- Forbes Guthrie on How to PXE boot from your trunked vmnic0
- Bryan on How to PXE boot from your trunked vmnic0
- AlphenIT on vSphere 5 Card