December 2008

You are currently browsing the monthly archive for December 2008.

OpenVPN and mt-daapd

Friday, December 26, 2008 in Linux, Macintosh by slowe | 2 comments

I have a system at home with an “older” Linux distribution for mundane tasks like DHCP and content filtering on my broadband connection (no need for the kids to see something they shouldn’t be seeing, if you know what I mean). I’ve thought frequently about rebuilding it with a newer distribution, perhaps Ubuntu, but—to be perfectly honest—I’m just too lazy. It generally just works, and overall doesn’t require a great deal of care and feeding.

One of the various things this server does is run mt-daapd (now called Firefly Media Server, I believe)—basically it’s an iTunes server. I dump copies of the MP3’s generated when I rip a CD onto a mount point on this server, and anyone in the house with iTunes can connect and listen to them. They can’t copy them or sync them to their iPod, but they can listen to them. Since the kids and I share some similar tastes in Christian contemporary music, it works out well.

After being rather impressed with the Viscosity OpenVPN client and OpenVPN in general, I also setup OpenVPN on this Linux home server for those instances when I need to connect to my home network for some reason. I’ve only needed to use it a couple of times, but it’s worked great thus far.

While setting up some older laptops for the kids (one of their Christmas presents this year), I ran into an instance where iTunes for Windows wouldn’t connect to the shared music library on my Linux server. The problem seemed sporadic, and seemed to be somewhat limited to the Windows laptops I was setting up; I was still able to connect from my MacBook Pro. About the same time, one of my younger kids came up and told me that the Mac mini downstairs wouldn’t connect to the shared music library, either. Hmmm, something was going on.

Restarting the mt-daapd daemon didn’t change anything, nor did disabling the Windows Firewall on the laptops. Turning off the firewall on the Linux server didn’t change anything, either. I started to dig in a bit deeper then, and after a short while realized that Bonjour—which is used by iTunes to discover shared music libraries on other systems—was somehow picking up the wrong IP address. But where was this address coming from?

It didn’t take long after that to figure out that mDNSResponder on the Linux server was broadcasting the IP address of the server’s tun0 interface, which is used by OpenVPN. Because of various routing issues and limitations, this range of addresses isn’t reachable by the home LAN; hence, failures to connect to the mt-daapd server.

The fix, in my case at least, was to modify the /etc/init.d/mDNSResponder script to add the “-i eth0″ parameter to the command that started mDNSResponder. This forced mDNSResponder to broadcast only the IP address of eth0, the server’s primary Ethernet interface. Two changes needed to be made to the file:

  1. First, the “-i eth0″ needs to be added to the line that defines the variable $OTHER_MDNSRD_OPTS.
  2. Second, double quotes have to be added around the command that actually launces mDNSResponder using the runuser command. Otherwise, the parameter to mDNSResponder is interpreted as a parameter to runuser and causes an error.

Once I made these changes and restarted both mDNSResponder and mt-daapd, all the systems were able to connect to the shared music library without any further issues. Problem solved!

Tags: , , ,

Merry Christmas!

Thursday, December 25, 2008 in Personal by slowe | 25 comments

Let us never forget the true reason behind Christmas:

1In those days Caesar Augustus issued a decree that a census should be taken of the entire Roman world. 2(This was the first census that took place while Quirinius was governor of Syria.) 3And everyone went to his own town to register.
4So Joseph also went up from the town of Nazareth in Galilee to Judea, to Bethlehem the town of David, because he belonged to the house and line of David. 5He went there to register with Mary, who was pledged to be married to him and was expecting a child. 6While they were there, the time came for the baby to be born, 7and she gave birth to her firstborn, a son. She wrapped him in cloths and placed him in a manger, because there was no room for them in the inn.
8And there were shepherds living out in the fields nearby, keeping watch over their flocks at night. 9An angel of the Lord appeared to them, and the glory of the Lord shone around them, and they were terrified. 10But the angel said to them, “Do not be afraid. I bring you good news of great joy that will be for all the people. 11Today in the town of David a Savior has been born to you; he is Christ the Lord. 12This will be a sign to you: You will find a baby wrapped in cloths and lying in a manger.”
13Suddenly a great company of the heavenly host appeared with the angel, praising God and saying, 14“Glory to God in the highest, and on earth peace to men on whom his favor rests.”
(Luke 2:1-14 NIV)

I’d like to take this moment to wish everyone a very Merry Christmas, and may the true reason behind this celebration live eternally in your hearts.

Tags: ,

Random Reboots with VMware ESX 3.5 Update 3

Tuesday, December 23, 2008 in Virtualization by slowe | 9 comments

I’ve been communicating with a reader who is experiencing random reboots of virtual machines on his HA/DRS-enabled cluster running VMware ESX 3.5 Update 3. At first, I thought his problem was related to the bug with VM failure monitoring that I discussed here, but upon further discussion the random reboots are continuing to occur even when VM failure monitoring is disabled. The only relief the reader has been able to find thus far has been to completely disable VMware HA on his cluster, which—to be honest—is a less than acceptable solution.

After a little bit of digging around, I turned up this VMware Communities thread, in which several other users also indicate they are seeing the same kinds of problems. The thread closes out by referencing this post by Duncan Epping regarding the VM failure monitoring bug. Clearly, though, this bug should not be affecting users who do not have VM failure monitoring enabled. I also found this blog post about another user having the issue, although it sounds like his problem was solved by disabling VM failure monitoring.

Further research turned up this KB article on a post-Update 3 patch that may address some of the random reboot issues. Judging from the KB article, it looks like the random reboots may be caused due to an unexpected interaction between VMotion and an option to automatically upgrade VMware Tools. This is just speculation, of course, but the symptoms seem to fit.

Have any other users out there experienced this problem? If so, what was the fix, if any? It sounds like there may be more to this issue than perhaps I first suspected.

Tags: , , , , ,

A Closer Look at iCal, CalDAV, Google Calendar, and the iPhone

Tuesday, December 23, 2008 in Collaboration, Macintosh by slowe | 7 comments

A few weeks ago I posted an article titled Manually Configuring iCal for Google Calendar and CalDAV, in which I provided a way to configure iCal in Leopard to use CalDAV to communicate with Google Calendar. I’d done this once before, but when Google made the CalDAV support “official” they removed the how-to pages and instead pointed everyone to their application to do it automatically. In any case, a bit of experimentation turned up the right settings, so in the event you’re interested, have a look there.

Since that time, I’ve been taking a closer look at the integration points between iCal, Google Calendar via CalDAV, and the iPhone. What I’ve found indicates that this may not be the optimal solution for me—but it may be just fine for you. Note that this has not deterred me from moving forward with greater use of Google Calendar, it has just shifted my strategy away from the built-in CalDAV support.

Some of the key limitations that I’ve encountered:

  • The “one-calendar-per-account” limitation is probably already well-known and isn’t a significant limitation, but one to consider nevertheless. This will mean more space required for your calendar list in the event you want to use multiple calendars via CalDAV. For those that aren’t familiar with what I’m talking about, the basic gist of the idea is that when using CalDAV with Google Calendar, each CalDAV account is only allowed to have a single calendar. So, to use multiple calendars, you’ll need multiple CalDAV accounts. These can all be the same Google account, but in iCal they’ll need to be configured as separate CalDAV accounts.
  • The big limitation, for me at least, is that CalDAV calendars synced to the iPhone are, in fact, read-only. That’s right—you won’t be able to make any changes to such calendars from the iPhone itself. I was pleasantly surprised to see that the calendars did actually sync to the iPhone, and then unpleasantly surprised to find they were now read-only. For me and how I work, I need the ability to make changes to my calendar from my iPhone. If that’s not a big deal for you, then continuing down the CalDAV route may be OK. Unfortunately, it’s not for me.
  • You can’t move events between CalDAV-enabled calendars. You actually have to re-create the event on the other calendar, then delete it from the first.

I’m still moving ahead with a greater usage of Google Calendar, but as a result of finding these limitations, I’m now taking a closer look at some of the third-party utilities to provide two-way sync between iCal and Google Calendar. BusySync is the leading candidate right now, although I’m also looking at Calgoo Connect and Spanning Sync. If any readers are using any of these products right now, I’d certainly welcome any feedback on how well they work.

Tags: , ,

Free Veeam Monitor

Monday, December 22, 2008 in Virtualization by slowe | No comments

In the event you haven’t heard elsewhere already, the special Christmas present that Veeam had in store for the virtualization community was a new, free version of Veeam Monitor. The addition of this free solution gives system administrators a new option for real-time monitoring of VMware Infrastructure environments.

Anyone can go and download a copy from the Veeam website. That’s assuming, of course, that you can actually download the software, as I’ve been trying to do all morning. I’m sure that once the initial excitement and the mad rush of downloads subsides, it will be much easier and much faster, but for those of you who just absolutely positively have to have it right now, good luck!

Tags: , , ,

Get Used to vSphere

Friday, December 19, 2008 in Virtualization by slowe | 25 comments

That’s right, VMware has finally settled on a new name for would have been called VMware Infrastructure 4. The new name? VMware vSphere.

Word is already out via several other bloggers, such as Jason Boche, Rich Brambley, and Rick Scherer.

This is just the next step in a series of product renames: Virtual Desktop Manager becomes VMware View, VirtualCenter becomes vCenter Server, etc.

Personally, I very much wished they had selected one of the other names they were tossing around. I liked “VMware Vantage.” vSphere? Who came up with this name, and what in the world is this supposed to mean? To me, it creates connotations of running around in a circle getting nowhere. Not exactly the image we want to create, is it?

Anyway, that’s why VMware doesn’t pay me to think. In fact, they don’t pay me at all! Time will tell whether this was a brilliant marketing move or the beginning of the end. Feel free to tell me what you think in the comments.

UPDATE: I’m writing a book on vSphere! Check out the details here.

Tags: , ,

VMware ESX Networking Articles

Friday, December 19, 2008 in Networking, Virtualization by slowe | 1 comment

Over the past few years—almost four years now that I’ve been writing here on this site—I’ve written quite a few articles on VMware ESX networking. Here’s a collection of links to some of the more notable, and hopefully more useful, articles in that group.

We’ll start with a classic article, but one that is still the number 1 post on this site. Written in December of 2006, this article on VMware ESX, NIC teaming, and VLAN trunking still generates lots of traffic even today. In that post, I describe how to use NIC teaming—more precisely, link aggregation or EtherChannel—along with VLAN trunking with VMware ESX. I guess this is a scenario that still causes problems with admins even today.

That first article was written with Cisco Catalyst switches in mind, but earlier this year I also published a version with information on VMware ESX, NIC teaming, and VLAN trunking with HP ProCurve switches as well.

One key piece to more fully understanding how VMware ESX interacts with VLAN tags is understanding what happens with untagged traffic, and this is something I described in this article on VMware ESX and the native VLAN. The key thing to remember here is to be sure to configure a VMware ESX port group to capture the untagged traffic, if that’s what you desire; otherwise, the traffic will just be ignored.

Similarly, a lot of VMware admins don’t fully understand the implications of the various load balancing policies on the vSwitch. The NIC teaming article from December 2006 assumed link aggregation (EtherChannel in the Cisco world), but how did VMware ESX behave in configurations without link aggregation? I tackled that subject in the post on NIC utilization in VMware ESX, and then provided a follow up post only a couple of months later. Both of these posts provide great information on how VMware ESX will place traffic onto the vSwitch uplinks.

Of course, if you find yourself needing to change the load balancing policy on a vSwitch, you might find this tip on using the CLI to change the vSwitch load balancing policy helpful, too. And this CLI guide to modify a port group may also prove useful.

In addition to an in-depth guide to NIC teaming, link aggregation, and VLAN trunking, I also provided a how-to on configuring VMware ESX, IP-based storage, and jumbo frames. While not officially supported by VMware, many users have reported success with this configuration and seen improved performance. (And before you ask: No, I haven’t run any performance comparisons myself yet.)

With the release of VI4—or whatever it ends up being called—there’ll be plenty of new networking fodder for me to write about: the Distributed vSwitch, the Cisco Nexus 1000V, and more. In the meantime, though, are there any other networking-oriented articles, guides, or how-to’s that readers would be interested in seeing published? I’m open to suggestions.

Tags: , , , , , , ,

Using vmware-vim-cmd to Modify a Portgroup

Tuesday, December 16, 2008 in Networking, Virtualization by slowe | 12 comments

While creating a command-line configuration guide for a design that I’d prepared, I found myself in need of a command that sets the NIC failover order explicitly for a portgroup. I suspected—and was correct—that vmware-vim-cmd would do the job, but was having a hard time finding documentation on the correct syntax. Even the extensive XtraVirt vimsh white paper did not have information on the syntax. After a little bit of digging around, I found the information for which I was looking. Here it is for future benefit.

The syntax for using vmware-vim-cmd to modify the NIC failover order for a portgroup looks like this:

vmware-vim-cmd hostsvc/net/portgroup_set --nicorderpolicy-active=<List of NICs> <vSwitch#> <Portgroup>

If the portgroup name includes spaces, then wrap the portgroup name in double quotes, like this:

vmware-vim-cmd hostsvc/net/portgroup_set --nicorderpolicy-active=vmnic0 vSwitch0 "Service Console"

That sets only the active NICs. Any NICs not included in the command above are set to Unused, which is generally not the desired result. Usually, we’d want those to be Standby NICs. To set the standby NICs, use this command:

vmware-vim-cmd hostsvc/net/portgroup_set --nicorderpolicy-standby=<List of VMNICs> <vSwitch#> <Portgroup>

Run the command to set the active NICs first, then run the command to set the standby NICs. The following example will set vmnic0 as Active and vmnic1 as standby for the Service Console port group on vSwitch0:

vmware-vim-cmd hostsvc/net/portgroup_set --nicorderpolicy-active=vmnic0 vSwitch0 "Service Console"
vmware-vim-cmd hostsvc/net/portgroup_set –nicorderpolicy-standby=vmnic1 vSwitch0 “Service Console”

I hope this is helpful to some readers.

UPDATE: A reader clarified in the comments that the parameters can actually be combined into a single command, like so:

vmware-vim-cmd hostsvc/net/portgroup_set --nicorderpolicy-active=vmnic0 --nicorderpolicy-standby=vmnic1 vSwitch0 "Service Console"

I tested this syntax on VMware ESX 3.5 Update 3 and it does work as expected. Thanks, Timo!

Tags: , , ,

Enabling Enhanced VMXNet

Monday, December 15, 2008 in Networking, Virtualization by slowe | 7 comments

I’ve been doing some additional digging into jumbo frames and other networking configurations, and along the way I came across references to VMware’s Enhanced VMXNet network adapters. These were apparently introduced in VMware ESX 3.5 and are necessary in order for virtual machines to take advantage of features like TCP Segmentation Offload (TSO) or jumbo frames.

The funny thing is this: even though the Enhanced VMXNet adapters are supported on both 32-bit and 64-bit versions of Windows Server 2003 and a few different flavors of Linux, the only way to be able to specify that you want to use an Enhanced VMXNet driver is if the virtual machine is configured as 64-bit Windows Server 2003 Enterprise Edition. This is outlined in this VMware KB article describing to how enable enhanced VMXNet drivers in Windows Server 2003.

Fortunately, there’s a way to also do this in the .VMX file. You’ll need to remove the VM from the VirtualCenter inventory (right-click, Remove From Inventory), then edit the .VMX file to add these entries:

ethernet0.virtualDev = "vmxnet"
ethernet0.features = “15″

Once these lines have been added—changing ethernet0 to ethernet1 or whatever the appropriate value is for the VM—you can use the Datastore Browser to add the VM back into the inventory. The NICs will now be listed as “Enhanced vmxnet”. In addition, Windows itself will now recognize greater offload functionality. The two screenshots below show the output of the command “netsh int ip show offload”; the first one is from a non-Enhanced VMXNet adapter:

Now for the output of the same command from a VM configured with an Enhanced VMXNet adapter:

This technique allows you to preserve the “integrity” of the guest OS selection by enabling Enhanced VMXNet without requiring users to change their guest OS selection to 64-bit Windows Server 2003 Enterprise Edition. Once the Enhanced VMXNet adapter is enabled, then users are free to begin working with jumbo frames and TSO. More on that in a future post…

UPDATE: I learned that in vCenter 2.5 Update 3, the option to select Enhanced VMXNet is now a selectable option for various flavors of Windows and Linux. I guess this information isn’t really needed any longer. Thanks for the information, Wade!

Tags: , , , ,

You’ve Got to be Kidding Me

Monday, December 15, 2008 in Microsoft, Virtualization by slowe | 24 comments

Via jtroyer on Twitter, I learned of this post comparing Hyper-V and VMware ESX.

Now, I’ll be the first to admit that I’m a VMware fan, but as others in the virtualization industry know I also recognize that VMware is not a “one size fits all” solution. There are many places where other virtualization solutions, Hyper-V included, may be a better solution for the customer. It really all depends upon the customer’s needs.

That being said, I do have a few questions for the owner of this particular post:

  • It’s a subtle point, but there is a distinction between “free” and “available at no additional charge”. I take vendors to task for this all the time. Hyper-V isn’t free; it’s available at no additional charge.
  • What in the world is “para metal” virtualization? I’ve heard of bare-metal virtualization (the kind that VMware ESX, Xen, and Hyper-V all perform) and paravirtualization (the kind that VMware ESX and Xen can perform; I don’t think Hyper-V does yet). Is “para metal” virtualization a blend of the two?
  • Identical servers are not required in order to support VMware HA. They are required for VMotion. I would strongly suspect that Hyper-V will have similar requirements or will require hardware support like AMD-V/Intel FlexMigration when it’s live migration feature arrives in 2010.
  • Just because VMware ESX can do memory overcommit doesn’t mean you have to use it. It just gives you the flexibility to use it when you need it.
  • I’m sorry, aren’t Microsoft Windows Server 2008, NTFS, and Windows Failover Clustering every bit as “proprietary” as VMware ESX, VMFS, and VMware HA? Am I missing something here?
  • VMware ESX installs just fine on x64 processors from both AMD and Intel. I have four x64 AMD servers sitting in my lab that are happily running both 32-bit and 64-bit guest operating systems.
  • Since when the hypervisor layer not containing any drivers—i.e., having your I/O drivers reside in the parent partition—have anything to do with direct hardware access by the guest OS? Unless I’m mistaken, these two items have nothing to do with each other. And the jury is still out as to whether having your I/O drivers in the parent partition, an approach used by both Hyper-V and Xen, is really a better approach.

Did I miss anything?

UPDATE: VMware blogger Jason Boche has also responded. Good points, Jason!

Tags: , , , , , , , , , ,

« Older entries