January 2008

You are currently browsing the monthly archive for January 2008.

Leopard Upgrade

Sunday, January 20, 2008 in Macintosh by slowe | No comments

So I upgraded my laptop this past weekend to Mac OS X version 10.5, aka “Leopard”. I’ve been reasonably pleased with the upgrade so far.

I keep most of my applications up to date, so I didn’t have too many applications that weren’t already Leopard compatible. That’s an advantage of being a slightly later adopter as opposed to being one of those guys waiting in line when the new OS was released. In addition, I gain the benefit of the Mac OS X 10.5.1 update, which addressed a number of issues with the initial Leopard release.

So far I’ve only run into a couple of issues, both of them very minor:

  • Mail.app 3.1 complains about the self-signed SSL certificate that my hosting provider uses with IMAP-TLS and SMTP-TLS. This occurred with Tiger as well, but some instructions I’d seen before the upgrade indicated that I might be able to bypass those warnings by setting the certificate to “Always Trust”. This doesn’t seem to work. Admittedly, a very minor issue.
  • My blogging application, ecto, was supposedly not Leopard compatible with the version I was using (version 2.4.2, Intel build). (I left the older version installed side-by-side with the newer version and the old version seems to run fine, though.) So I switched to a beta build of ecto3, which is a complete rewrite of the blogging application, and I’ve run into a few little issues there. Those are directly related to the ecto3 upgrade, though, and not necessarily to the Leopard upgrade itself.

One of the first “tweaks” I reached for was the tweak to return the menu bar to a more opaque status. There are a number of sites out there providing instructions; here’s the Terminal command I used:

sudo defaults write /System/Library/LaunchDaemons/
com.apple.WindowServer 'EnvironmentVariables'
-dict 'CI_NO_BACKGROUND_IMAGE' 0.62

The command worked like a champ, and my menu bar was restored to some sense of normalcy. I initially also switched the Dock to a 2-D smoked glass look, but then switched back to the default 3-D appearance. I figured I’d give the new Dock appearance a chance before just banishing it to the ether.

I haven’t been back to the office or at a customer’s site since the upgrade, obviously, so I don’t have any feedback yet on interoperability with Windows-based networks, Kerberos support, etc. I do need to look up the information on Leopard’s built-in support for SSH keys, since I relied upon SSHKeyChain before the Leopard upgrade. If anyone has any pointers on that one, please let me know.

One huge missing piece so far are the Leopard-compatible versions of MailTags and Mail Act-On. I have the beta versions of both, but I’m a bit hesitant to use them—I don’t want to take any chances with my mail, if you know what I mean. Anyone out there using the beta versions of these on Leopard and have some feedback for me? Are they safe yet, or should I wait just a bit longer yet?

Spaces is pretty cool; it’s nice to have virtual desktops back with Mac OS X again. I’d used a pretty fair number of virtual desktop applications on my Mac, eventually settling on VirtueDesktops (then just called Virtue) and then discontinuing my use of virtual desktops after my Tiger upgrade. VirtueDesktops went through various stages of support and non-support during the Tiger upgrade and the migration to the Intel platform, eventually ending development due to the expected introduction of Spaces. While Spaces doesn’t have all the features that VirtueDesktops had, it is at least fully supported. In addition, the former developer of VirtueDesktops is working on something called Hyperspaces, which will—as the name suggests—extend Spaces to include features that VirtueDesktops used to have. In any case, Spaces seems to work fine so far.

I’ll post more information as I continue to get accustomed to Leopard; in the meantime, I’d love to hear any feedback from other Leopard users on your experiences. Feel free to put your feedback in the comments below!

Tags: , ,

Sorry

Thursday, January 17, 2008 in General by slowe | 4 comments

Apparently my site was compromised and some offensive ads were placed at the top of the site. I’ve removed the ads and the code that placed them there and have taken steps to ensure that we don’t have an issue like this again. Additional steps may be necessary, so be patient with me as I work this out.

If you were offended by the unwanted ads, please accept my apologies!

Tags:

New VDI Article at SearchVMware

Tuesday, January 15, 2008 in Virtualization by slowe | No comments

The fine folks over at SearchVMware.com have published another of my VDI articles, this one focusing on the connection broker’s integration into Active Directory:

The broker’s integration with a back-end directory service can play a significant role in many of the decisions regarding how a virtual desktop infrastructure (VDI) environment is deployed in VMware Infrastructure 3 (VI3). In this tip, we’ll examine the integration between the connection broker and a commonly-used back-end directory service, Microsoft Active Directory.

Please go read the full article!

Tags: , , ,

Good Podcasts

Monday, January 14, 2008 in General by slowe | 11 comments

Up until now, I haven’t really messed around with listening to podcasts. I know all about them, what they are, how they work, and all that wonderful jazz. But I typically have not listened to podcasts at all.

I’m not really sure why, although I suppose it could be due to not having some podcasts that I really find useful or enjoyable.

So I’ll toss it back to you, the readers, for your feedback. Are there podcasts out there that you find useful? What podcasts would you recommend for a guy like me?

Tags:

Proving VMware Over NFS

Monday, January 14, 2008 in Storage, Virtualization by slowe | 11 comments

I’m a fan of using NFS for VMware; I’ve mentioned it before. I’m not the only one, either; there have been a number of recent blog entries from various people regarding the use of NFS for VMware:

Virtual Optics: Why VMware over NetApp NFS

Storage Nuts & Bolts: VMware over NetApp NFS: A Customer’s Testimonial

It’s great that this is receiving more attention in the spotlight, but I still have one question: where are the statistics proving NFS’ value in VMware deployments?

If NFS is equally as good as Fibre Channel or iSCSI—and personally I agree with Nick that most deployments would be hard-pressed to tell the difference—then where are the stats that show this? Or is it impossible to demonstrate that a VMware deployment on NFS is “just as good” as one on Fibre Channel or iSCSI? Does the value of NFS come in subjective measurements that can’t be quantified, and perhaps that’s why we haven’t seen any hard proof of the value of NFS when compared to Fibre Channel or iSCSI?

If you have some insight, please share it in the comments. I’d love to hear everyone’s thoughts on the matter.

Tags: , , , , ,

ESX Server 3.0.1 Patch Needed for VC 2.5

Thursday, January 10, 2008 in Virtualization by slowe | 3 comments

A notice about a potential interaction between ESX Server 3.0.1 and VirtualCenter 2.5 just shot through my e-mail, and I thought it important enough to post here.

According to this VMware KB document, any ESX Server running version 3.0.1 should have patch ESX-7557441 installed before VirtualCenter is upgraded to version 2.5. If this patch is not installed, it’s possible that virtual machines which are configured to automatically start or stop will unexpectedly reboot when VirtualCenter is upgraded to version 2.5. Since VirtualCenter has to be upgraded before you can start upgrading your ESX Servers, then this could definitely be an issue.

More information on why this may occur is provided in this related VMware KB article.

This may be a fairly rare situation, since (tongue in cheek) organizations always make sure that their ESX Servers are kept patched. (OK, you can stop laughing now.) Seriously, though, if you do still have servers running ESX 3.0.1 be sure to apply this patch before starting along your upgrade path.

Tags: , ,

Local Logins Refused in AD Integration Scenarios

Wednesday, January 9, 2008 in Interoperability, Virtualization by slowe | 5 comments

A customer with whom I had worked to fully integrate their ESX Server systems into Active Directory—using my instructions here—had run into a problem. The problem was that local logins were refused when the Service Console lost network connectivity. Clearly, this was a problem; if the customer couldn’t login as root when the network is down, even locally at the console, then we have problems. So I set out today to isolate and fix the problem.

After much trial and error, I had determined what was not the cause the problem:

  • The /etc/pam.d/system-auth file was not at fault; we tried numerous combinations in system-auth and there was no difference in behavior
  • The /etc/ldap.conf file was not at fault; we even tried adding a few additional entries (like “bind_policy soft”) to help with issues when LDAP was down and not responding
  • A lack of DNS resolution was not the problem; the behavior was the same whether DNS was working or not

Finally, I was able to track down this thread which discusses the behavior of the nss_ldap libraries when the LDAP service is not available across the network. In this specific message in the thread, it is noted that nss_ldap will try to contact LDAP to enumerate group membership, even if LDAP is down. So the problem was with using LDAP for group membership, and a quick edit to /etc/nsswitch.conf to remove LDAP from the group line proved that to be true.

As shown in the message, the only workarounds are:

  • Upgrade to v245 of nss_ldap, which allows the use of the “nss_initgroups_ignoreusers” directive; this instructs nss_ldap to not perform group enumeration for the specified users; or
  • Remove the “ldap” entry from the group line in /etc/nsswitch.conf.

Unfortunately, ESX Server 3.0.2 and ESX Server 3.5.0 only supply nss_ldap v207-17, which is too early to support that directive. Of course, we can’t really upgrade the library, either, since that’s not supported by VMware. So the only real fix for VMware ESX Server AD integration scenarios is to not use Active Directory for group memberships. User accounts can still be managed using Active Directory—and authentication occurs against Active Directory—but groups and group membership will have to be handled locally.

This issue is applicable to other operating systems besides ESX Server, though, and for those operating systems an upgrade of the nss_ldap library and the use of the “nss_initgroups_ignoreuser” directive in ldap.conf may be all that is needed to fix an issue with local logins being refused when network connectivity is not present.

UPDATE: It appears that local logins will work without network connectivity, even with full Active Directory integration, if you use the Emergency Console. Thanks to Magnus for the update!

Tags: , , , , , ,

LACP with Cisco Switches and NetApp VIFs

Tuesday, January 8, 2008 in Interoperability, Networking by slowe | 23 comments

In my previous article about using NetApp multi-mode VIFs with Cisco switches, I mentioned that you could—at that time—only use 802.3ad static link aggregation:

Be aware that Data ONTAP’s multi-mode VIFs are only compatible with static 802.3ad link aggregation; you can’t use PAgP (Cisco proprietary protocol). I would assume dynamic LACP is also incompatible. For this reason we used the “channel-group 1 mode on” statement instead of something like “channel-group 1 mode desirable”.

I recently got some feedback from a NetApp SE in my area; this SE informed me that Link Aggregation Control Protocol (LACP, part of the IEEE 802.3ad specification) is indeed supported with Data ONTAP version 7.2. This KB article on the NetApp NOW site (login required) indicates that ONTAP 7.2.1 is required in order to use a LACP VIF.

There are a couple important requirements to note; these are laid out in the referenced KB article:

  1. Dynamic multimode VIFs should use IP address-based load balancing. This means that the Cisco switch or the channel group must also use IP address-based load balancing.
  2. Dynamic multimode VIFs must be first-level VIFs. This makes sense; LACP is a Layer 2 protocol, so layering a LACP VIF on top of other VIFs just doesn’t work.

To create the dynamic multimode VIF on the Data ONTAP side, the command is pretty simple:

vif create lacp <vif name> -b ip {interface list}

On the Cisco side, the commands are very similar:

s3(config)#int port-channel1
s3(config-if)#description LACP multimode VIF for netapp1
s3(config-if)#int gi0/23
s3(config-if)#channel-protocol lacp
s3(config-if)#channel-group 1 mode active

These commands would be repeated for all physical ports that should be included in the LACP bundle. Note the differences from the earlier commands in the previous article; here we use “channel-group 1 mode active” instead of “channel-group 1 mode on“. We also added the “channel-protocol lacp” command.

Together, these commands will establish a LACP-based link aggregate between a NetApp storage system running Data ONTAP version 7.2.1 or higher and a Cisco IOS-based switch.

Thanks to Jeff, our NetApp SE, for providing the updated information.

Tags: , , , , ,

VMware HA Clarification?

Monday, January 7, 2008 in Virtualization by slowe | 1 comment

VMwarewolf posted an update today intended clarify the behavior of VMware HA admission control:

I was previously under the impression that Configured Memory (in a VM) was the number used in this consideration. Some further investigation has revealed this is incorrect. It is the Reserved Memory, plus overhead, that is used in this calculation.

If I’m reading this correctly, then reserved memory is the number that really matters when calculating failover capacity. That leads me to believe, assuming I am understanding this correctly, that a 2GB VM which only has 256MB of RAM reserved would be calculated as 340MB for the purposes of calculating failover capacity (256MB + 84MB overhead for a 32-bit virtual machine, slightly higher for a 64-bit virtual machine).

I suppose in a way that makes sense, since only reserved memory is ever really “guaranteed” to a VM.

However, this again underscores the need for VMware to get on the ball and prepare some useful, comprehensive documentation about VMware HA, how it works, how it’s configured, how one goes about troubleshooting it, and how it behaves when it’s not configured correctly. Right now, the community is attempting to figure this out itself, and doesn’t seem to be having a great deal of success.

Tags: , , ,

Underwhelmed by the Remote CLI

Monday, January 7, 2008 in Virtualization by slowe | 7 comments

Along with the release of VMware Infrastructure 3 version 3.5 and ESX Server 3i version 3.5, VMware released the VMware Remote CLI. This was supposed to be, to my understanding, the new way to manage ESX Server 3i since there is no longer a Service Console with ESX Server 3i. Of course, you can still manage ESX Server 3i with VirtualCenter, but the Remote CLI was the only reasonable way to get a command line interface. In addition, the Remote CLI is the method whereby users can initiate a Storage VMotion operation.

Given the relative importance of the Remote CLI, I expected more. After visiting the download page for the Remote CLI and seeing, once again, only Windows and Linux versions, I downloaded the Remote CLI appliance. It seemed logical to me that I should be able to import the virtual appliance into my DRS/HA cluster and simply run it from there.

Unfortunately, things didn’t work quite as I had planned. Despite repeated attempts, the import of the virtual appliance from the *.OVF file into VirtualCenter continually failed when attempting to map the networks for the virtual appliance. No amount of fiddling with the *.OVF file to put in network names that I was currently using would fix the problem. If anyone has a workaround for this particular issue, I’d love to hear it.

Seeing that the virtual appliance was apparently a dead end, I proceeded to install the Remote CLI on my VirtualCenter server. When the installation was complete, I found that I had no visible way of even knowing if the installation was successful. No new icons, no Start Menu items, no pop-up dialog box asking me if I’d like to run the Remote CLI…nothing. Only by opening a command prompt and navigating to the directory where the Remote CLI had been installed was I able to determine that something had actually happened. And what had happened? VMware had installed ActivePerl and a set of Perl scripts. That’s all.

I did recall seeing this warning from Bob Plankers about logging out and logging back in again, so I did that. It didn’t really make any difference. I can run Remote CLI commands without having to specify the path, but I do have to specify the “.pl” extension on everything. And the scripts seem slow, although that may be attributable to the slightly older hardware I have in my lab.

Something about all this just seems really unpolished. Unfinished. Rushed. Pick whatever adjective suits you best here; I just know that this was not what I had expected. Why call it the “Remote CLI” if its really just a collection of scripts that operate remotely? Wouldn’t “ESX Server  3i Management Tools” be better? And yes, perhaps I am being a bit picky, but sometimes it’s the little things that can make or break a customer’s first impression. Would you want your customer’s first impression of VMware’s products to be the Remote CLI?

Tags: , , , ,

« Older entries § Newer entries »