Today on the VMware Communities Roundtable, we had an Ask The Experts session with live callers. As is typical of these kinds of things, the discussion was wide-ranging but lively. I’d like to thank both the roundtable panel as well as the two dozen or so folks who joined us live on the call.
To listen, click on the right or download the mp3. (1:04) Feeds: RSS, iTunes
Next week, same bat-time, same bat-channel. The topic is VMworld, VMworld predictions, and anything else that comes up.
Show notes:
- Announcing VI:OPS, a community for operationalizing VI
- Preventing VM sprawl on IT Knowledge Exchange
- A new generation of management tools?
- NFS vs VMFS
- VMFS vs. NFS for VMware Infrastructure? VMware Storage Blog
- Openfiler
- Create an NFS Share on Windows 2003 for ESX from VMware eLearning. Part 2. Part 3.
- Using Windows-based NFS in VI3
- Communities thread on Windows NFS and ESX 3.5
- Setting up Windows Services For UNIX (SFU) NFS
- Storage VMotion and 10Gb Ethernet support for iSCSI SAN’s
- Storage VMotion and Plug-ins
- VI Toolkit (for Windows) PowerShell scripting contest entries
- VMware and SVVP
- VMware
ESX is the Industry’s First Hypervisor to be Validated by Microsoft,
Offers Customers Expanded Support Options for Microsoft Applications –
VMware - chriswolf.com
- I should clarify what we said on the podcast about apps vs OSes. There were two parts to the recent announcements. The first part was about support on validated hypervisors. Although 31 applications are now be included in the SVVP, the support offered by this program from the beginning covered the operating systems (see here). The second part was about transfering application licenses. This included 41 applications that can now transfer their licenses during a VMotion, but server operating system licenses are not included. See Chris Wolf’s blog for a better explanation: Interpreting Microsoft’s Revised Virtualization Licensing Policy
- VMware
- RCLI
- ESX vs ESXi kb: http://kb.vmware.com/kb/1006543
- RCLI documentation
- VI Client Open Console Attempt Fails
- The most likely possibility was this: The OS on which the VIC resides must be able to resolve not only the VC
server but also each ESX Server. If they can not resolve via name the
ESX servers you get this message. This is regardless of whether VC can
resolve the name. However, proxying fixes this problem. Another fix is to add the information to the static hosts file. - However, a guest on the call had the same problem, and fixed it by disconnecting the ESX server from VC cluster, restarting the agent on ESX server, and then reconnecting.
- The most likely possibility was this: The OS on which the VIC resides must be able to resolve not only the VC
- Hmm, looking at the chat transcript, I see we missed at least two questions: ESX and deduplication and in regard to the previous problem if there is a good DNS healthcheck tool. We’ll save those for later, I guess.
Thanks everybody! It was a great call.
