Have you registered for the major cloud infrastructure event VMware is putting on tomorrow? It all happens July 12, 2011 at 9 a.m. Pacific — don’t wait until the last second to sign up, do it now.
Just like Paul Masson, VMware executives Paul Maritz and Steve Herrod will launch no cloud infrastructure before its time. Fortunately for The Cloud, it is almost time…
PXE is a fast and easy way to install operating systems over the network; especially attractive compared to the painfully slow alternative of something like iLO remote media. Microsoft offers a PXE installation solution called Windows Deployment Services (WDS) and PXELINUX is an excellent utility for network installs of Linux or VMware ESXi, Firmware Maintenance DVDs, rescue CDs, and pretty much anything else.
What to do in a heterogeneous environment? This can be a challenge for PXE because it requires DHCP — it is difficult to have more than one PXE server on a network. While it is possible to configure a WDS server to install non-Windows operating systems, NFS support can be an issue. Besides that, do you really want to install Linux via IIS?
Deploying a Linux system configured with DHCP, TFTP, HTTP, and NFS on a separate VLAN is certainly one approach. But wouldn’t it be convenient if the WDS and Linux PXE servers could coexist peacefully on the same network?
As it turns out, thanks to the lesser-known pxechain utility, it is possible to seamlessly jump from one PXE host to another. With a few tweaks to your WDS server, you can continue to use it for Windows OS installs and bounce over to a Linux host for Linux, ESXi, or rescue-CD purposes.
Tags: installation, Linux, PXE, WDS
A recent TechTarget piece pits VMware vSphere memory management technologies against the new Microsoft Hyper-V Dynamic Memory. While certainly an interesting topic, I was disappointed by some of the inaccurate statements propping up the Hyper-V side. With no facility to provide comments on that article directly, I thought I’d take a moment to set the record straight.
The key claim — that Microsoft offers more control over virtual machine memory — is misinformed at best:
Hyper-V Dynamic Memory also has a greater range of configurable options than does VMware memory overcommit. Users can assign limits to problematic VMs with memory-hungry workloads, and if memory contention occurs, users can prioritize specific VMs. A configurable buffer value also identifies how much extra memory is reserved for short-term needs between rebalancing passes.
Readers seeking to find the true differences between these platforms will need to search elsewhere. A factual comparison reveals that Hyper-V Dynamic Memory offers no advantage over VMware vSphere: A VMware ESX VM has settings for memory size, limit, reservation, and shares to specify priority. Not only that, VMware vSphere offers a comprehensive range of memory management technologies: ballooning, page sharing, compression, and host swapping.
What vSphere doesn’t have is a reserve memory buffer setting — this is an artifact of the Dynamic Memory design, accommodating for lag time inherent to the hot-add process. Interestingly, when running important enterprise applications like SQL Server, Microsoft recommends cranking the buffer down to the lowest possible setting.
VMware vSphere offers the widest range of memory management and configuration capabilities, accommodating even the most demanding workloads.
Tags: ESX, Hyper-V, memory overcommit, vSphere
There are many ways to compare alternatives, but for simplicity, things often come down to cost. Unfortunately, it’s not always easy to separate the true comparisons from creative marketing — let’s take a look at some key factors that can help sort the apples from the oranges.
Imagine you are looking to buy a new laptop, equipped with various accessories and software. Part of the decision is to select an appropriate office suite to include in the configuration:
There are a number of office suite options: the less capable choice adds $80 to the price, and the one you really need to do your work adds $230 — almost three times the cost. Outrageous! Read the rest of this entry »
VMware vSphere networking is available in two variations — Standard vSwitch and Distributed Switch (vDS) — that accommodate a wide range of requirements for any environment. Standard switches are simple to set up and understand, but the effort to manage them scales along with the number of ESXi hosts managed. While that management can certainly be automated, e.g., through PowerCLI, there are advantages to the centrally-configured Distributed Switch.
This is not an article to convince you to use one over the other; to see what experts have to say about the matter, take a look at a recent article from Duncan Epping on whether to go pure Distributed or hybrid.
Whenever this topic comes up for debate, it’s clear that the major concern about vDS is the inability to manage virtual networks if vCenter Server goes down. Thus, the impetus for considering a hybrid environment with management interfaces on Standard vSwitches and only VM networking benefiting from vDS. However, there is a configuration alternative that may just boost confidence in a pure vDS network.
Distributed Switches, just like Standard vSwitches, use port groups to configure various network capabilities, VLANs, etc. One difference is that vDS port groups have three different binding options: static, dynamic, and ephemeral. For an overview of these options, check out KB Article 1010593.
The key point to note is that port groups using ephemeral bindings behave very much like a Standard vSwitch — even with vCenter Server powered off, administrators have the ability to connect directly to an ESXi host and reconfigure VM networking. Read the rest of this entry »
Tags: networking, vSphere
The views and opinions published on this site belong to Eric Gray and are not approved or endorsed by his employer, VMware, Inc.
Newsletter 
RSS Feed 
Follow
Recent Comments