While running VMware Server 2.0.2-203138 on Windows 7, I experienced the following issue:
- Installed guests assigned to VMnet0 can not ping or access any hosts aside from other VMware guests.
- My NIC is a: Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit Ethernet NIC (NDIS 6.20)
- In the NIC properties, the VMware Bridge Protocol is enabled.
Guests could see each other and communicate on VMnet0, but cannot ping the host or anything beyond the host.
In Windows 7’s Network and Sharing center, only NIC is listed under “Internet Access”, and VMnet1 and VMnet8 are listed under “No network access,” but this seems to be normal.
From the Start menu, I opened Manage Virtual Networks, and the Summary page told me VMnet0 was supposed to automatically bridge to some adapter. Apparently, it wasn’t doing so.
At the Host Virtual Network Mapping tab, I was able to specify that I wanted VMnet0 to use the Realtek NIC.
After clicking Apply/OK and waiting a bit for VMware and the guests to figure out just what in tarnation had just changed, guest networking began working as expected.
Within my Solaris 10 guest, I then created /etc/resolv.conf, added the two Google DNS servers, and copied /etc/nsswitch.dns to /etc/nsswitch.conf:
# touch /etc/resolv.conf
# vi /etc/resolv.conf
Add the text:
nameserver 192.168.0.1 # my router
nameserver 126.96.36.199 # google
nameserver 188.8.131.52 # google
# cp nsswitch.dns nsswitch.conf
What happens when a significant number of your users use their own devices at work (Bring Your Own Device — BYOD), and an OEM patch breaks the system for those users?
I have talked to several clients that want to move forward with BYOD initiatives, but are predictably cautious. Several have initiated small pilots with the goal of supporting a specific use case (e.g., iPads for c-level executives). Others are more cautious with planning and architecture and have yet to support any BYOD implementation. However, some clients are already using server-hosted virtual desktops (SHVD) to support call center employees that work from home. In some instances, those workers access their virtual desktops from personal PCs.
That leads us to a significant problem that occurred this week. A Windows 7 update broke the VMware View client. You can read about the problem in the VMware KB here. The problem can be resolved by upgrading the View client or by uninstalling the Windows 7 patches noted in the workaround here.
via Windows 7 Update Breaks VMware View Client: An Important Lesson In BYOD.
Dell is building up its system management capabilities to make it easier for customers to monitor and manage their PowerEdge servers in virtualized data centers.
Dell officials on Jan. 19 announced several enhancements to its systems management portfolio, including the Dell Management Plug-in for VMware vCenter, which enables IT administrators to do a wide variety of server tasks—from provisioning bare metal servers to deploying hypervisors to updating firmware and BIOS—directly from VMware’s vCenter management console.
With the VMware plug-in the cost is contingent on the number of 11th-generation PowerEdge servers that are being managed via VMware’s vCenter, Iler said. Pricing starts at $299 for three servers, and goes to $799 for 10 servers, $1,799 for 50 and $2,999 for 1,000 systems.
This is very handy indeed, although I don’t forsee smaller companies paying for the feature very frequently.
via Dell Offers VMware Plug-In for PowerEdge Servers – IT Infrastructure – News & Reviews – eWeek.com.
Surprisingly and happily, with ESXi 4.1, VMware has made it possible to enable and disable SSH access to the host via the vSphere client. No longer is it necessary to enter the top-secret unsupported console via <alt-F1> and edit inetd.conf by hand.
To enable local or remote TSM from the vSphere Client:
- Select the host and click the Configuration tab.
- Click Security profile > Properties.
- Click Local Tech Support or Remote Tech Support SSH and click Options.
- Choose the desired startup policy and click Start, then click OK.
- Verify that the daemon selected in step 3 shows as running in the Services Properties window.
via VMware KB: Using Tech Support Mode in ESXi 4.1.
Something for the next patch cycle:
VMware Inc. has released a security advisory, warning users of its ESX 4.1 software that a vulnerability in the hypervisor could allow a local user to gain local privileges.
The company issued a patch, Monday, fixing a stack pointer underflow problem that could fail to block a local user from gaining additional privileges without proper controls.
via VMware fixes ESX 4.1 hypervisor flaw.
Cameron Sturdevant lists 9 points to keep in mind when comparing virtual desktop hypervisors.
I start by identifying what will be required of the desktops, what sort of hardware (client and server) will be required to support the requirements, and then I dive into the murky, swirling world of licensing:
1. License costs
In addition to the “three C’s” one of the most important testing criteria is licensing costs. None of the competing vendors make it easy to do an apples-to-apples comparison, so you’ll need to do some noodling to get a price per-desktop, per-year figure. It makes a difference how many years you include in your calculations. I suggest looking at a minimum of three and a maximum of five years, depending on your current physical desktop or laptop formula. Speaking of physical systems, you should factor in the costs of the user devices on which the remote virtual desktops will be hosted.
via Critical Testing Criteria: Virtual Desktop Infrastructure – Virtualization from eWeek.
Several months after Citrix met all of the Gartner Group’s enterprise-ready virtual desktop requirements, VMware takes minor-version-leap forward to catch up:
View 4.5 addressed all four of the above shortcomings, and the breadth of their feature improvements were deeply scrutinized with hands-on assessments in our lab. To VMware’s credit, they didn’t try to address customer management requirements with band aids. Instead, they literally scrapped their previous management console and replaced with a far improved Adobe Flex-based console. In addition, they unveiled a Microsoft System Center Operations Manager (SCOM) management pack for View 4.5 management. That was another common request I’ve heard from early VMware View adopters. On the scalability side, View 4.5 is now capable of scaling to 10,000 managed desktops per management domain, which is currently double the maximum scalability supported by Citrix.
via VMware View 4.5: Ready for the Large Enterprise.
Looks like a fantastic new option, if you have the budget.
Cisco Systems, NetApp and VMware jointly announced July 28 that they have made ready for prime time a new fully certified, end-to-end FCOE storage package for VMware virtual environments.
The package contains VMware-validated Cisco Nexus 5000 Series Switches and NetApp FAS-series unified storage using FCOE in virtual environments running VMware vSphere.
via Cisco, NetApp, VMware Combine Forces on FCOE Storage System – Data Storage from eWeek.
New release, new features!
VMware’s vCenter management server has offered Active Directory authentication for some time, but many of our clients have continually asked VMware to extend AD authentication to the individual hypervisor level. Prior to vSphere 4.1, administrators could login to ESX or ESXi hypervisors using a local account typically root. Organizations that wanted tighter security at the individual hypervisor required a third party add-on such as HyTrust. While hypervisor-level AD authentication was a key value-add for HyTrust,it’s other key features such as security policy enforcement and audit logging will ensure its longevity.
This is the biggest win for my current client. Having slightly more than a handful of ESXi hosts without a vCenter manager required individual logins on each machine. With 4.1 supporting AD authentication on the hypervisor, user administration should become a tad easier.
via VMware vSphere 4.1: Not the Typical .1 Release.
An interesting study from the Burton Group on VMware View and Citrix XenDesktop. For the purposes of my current client, the administrative roles problem they outline isn’t an issue – we have only 3 administrators, and all have the same access. However, I’m interested in seeing what criteria they examined, and why View fell so far behind XenDesktop in every category.
After Simon Bramfitt and I assessed XenDesktop 4.0 and View 4.0.1, we reached a similar conclusion – neither product is ready for the demands of the large enterprise. A comparison scorecard of each product is shown below.xd-view-scorecardBoth products do not deliver what we consider to be essential features.
For example, neither product offers role based access controls RBACs to support the delegated administration models our clients expect. Offering only “User” and “Administrator” roles, for example, does not constitute delegated administration. In addition neither product offers complete administrative change logging, meaning that it is not possible to maintain an audit trail for all administrative actions.
via Citrix Synergy 2010: Burton Group’s Citrix XenDesktop and VMware View Assessments.