Does anyone else find it a bit ironic that neither AT&T nor Apple have iPhone-optimized versions of their web sites? Or am I the only one wondering why the iPhone’s exclusive suppliers don’t optimize their own sites for the iPhone?
You are currently browsing the monthly archive for November 2008.
For those readers who celebrate Thanksgiving, I’d like to extend to you my warmest wishes for a very pleasant and very restful Thanksgiving holiday. I am very thankful for the blessings that have been bestowed upon me; despite whatever problems I may be having, it could certainly be worse.
(Yes, I know the holiday isn’t until Thursday, but I’m leaving with my family for a short out-of-town vacation and wanted to go ahead and wish everyone a happy Thanksgiving before leaving.)
To those readers who do not celebrate Thanksgiving but do celebrate something similar, I wish you a very enjoyable holiday as well.
Tags: Personal
Two of my most-used applications have been updated to new versions. OmniGraffle is now updated to version 5.1, and OmniFocus is now updated to version 1.5. (Funny, I just noticed how the versions numbers are reversed—5.1 and 1.5.)
The OmniGraffle update brings one feature that I have especially been anticipating: the ability to import Windows Metafile images in Visio diagrams. This extremely useful feature, first hinted at here back in March, will tremendously ease Visio compatibility and should open up lots of Visio shapes to be used in OmniGraffle that previously were not usable. I tested this functionality this morning on a complex NetApp-VMware-IBM BladeCenter diagram from a co-worker, and it works as advertised. Future tests will see how well this functionality works in bringing Visio stencils into OmniGraffle. This is a free upgrade for current OmniGraffle 5.0 customers.
The OmniFocus update brings this GTD application’s official 1.5 release, and with it synchronization with OmniFocus for iPhone. Now that both the Mac and iPhone versions support Bonjour sync—although this is not without its own travails—I find myself using them more and more. If you’ve been following the pre-release versions of OmniFocus (the so-called “sneaky peeks”) then you won’t find many new features in this official release, but users who have been waiting for the official release to upgrade are in for a real treat. As with OmniGraffle, this OmniFocus upgrade is a free upgrade for existing OmniFocus 1.x customers.
So, I’ve been searching for a good way to establish connectivity to the lab at my office for a while. My first attempt was to work with one of our CCIEs at the office to establish an IPSec-based VPN against a Cisco router at the edge of the lab network, but despite our best efforts we couldn’t get the IPSec VPN client I was using, IPSecuritas, to connect and authenticate. No amount of fiddling would make it work.
We finally gave up on that and instead I went with an OpenBSD box to which I could establish an SSH session and then tunnel traffic from there. That worked reasonably well, especially after I discovered the GNU Screen utility. Talk about a handy little tool! Anyway, I continued using the SSH gateway for quite some time and I had resigned myself to living with the limitations.
Then a co-worker from the office casually mentions that he’s set up a Linux-based OpenVPN server on another subnet in the lab (we have a range of different subnets for different engineers in the lab). He, too, is a Mac user, but still running Mac OS X 10.4 on an older 13″ PowerBook G4 and using the Tunnelblick OpenVPN client. I thought to myself, “Hey, this might actually work!”
Alas, some additional research indicated that Tunnelblick had some stability problems under Leopard, which I’m running on my MacBook Pro. Bummer! I continued to research the issue but didn’t bother trying to use the OpenVPN server until just a couple of weeks ago when I uncovered Viscosity.
Viscosity is a shareware, Leopard-only OpenVPN client. It supports Growl notifications (which I very much like) and operates as a simple menu icon that easily allows you to connect or disconnect individual connections. Owing partially to how OpenVPN works, Viscosity uses (and includes) a TUN/TAP driver for OS X and creates a new TUN/TAP interface for every connection. This makes routing much easier and much more logical, in my opinion.
I’m so pleased with OpenVPN thus far, in fact, that I’m going to be setting up my own OpenVPN server here at the house.
My experience thus far has been quite positive. If you are looking for a good OpenVPN client for your Mac, Viscosity would be an excellent choice. At only $9 for a license, it’s well worth it.
A short while ago, I had a colleague in the blogging industry ask me if the reason I was writing “Short Takes” was because I was too busy to write in-depth articles. At the time, I told this colleague no, but now I’m wondering if I should change that answer…
In any event, here’s my list of links and tidbits that I found interesting, amusing, or useful over the last week or so. Enjoy!
- Eric Sloof of NTPRO.NL points out that VMware has updated their best practices to “allow” the placement of VM swap files on NFS, rather than recommending VMFS. Does anyone have a link to the VMware KB article with those updated recommendations?
- Edward Haletky points out a process for performing “secure P2V” operations. Because the P2V process generally involves network communications with VirtualCenter and/or the VMware ESX Service Console, a straight P2V process would cross security boundaries. Edward’s phased approach helps with that issue.
- Into PowerShell, but finding the process of modifying Offload Policies too difficult? This should help out significantly.
- Expanding upon some earlier work, Rick has added “Resolution Paths” to common network issues and common licensing issues. Excellent work!
- Leo provides some good information on monitoring VI3 with Zenoss.
- Via Alessandro and Ben, I learned about the HVRemote tool for automating the configuration steps for enabling remote management of Hyper-V. HVRemote was created by John Howard and more information is available here.
- Symbolik shares his experience in troubleshooting a PSoD (Purple Screen of Death) with VMware ESX. In his case, the issue turned out to be related to NICs, but it’s nice to see that he was able to zero in on the issue and get it resolved.
- Larger installations with lots of LUNs and an active/active SAN may find this script published by Duncan very helpful. The problem that this script addressed underscores the need for robust multipathing support in VMware ESX such as that which will be allowed via the new vStorage APIs.
- Need more information on Enhanced VMotion Compatibility (EVC)? Both Gabe and Rich have recently tackled the issue on their own blogs. If you’re wondering what EVC is, the short answer is that it’s a way to automate this process in a supported fashion.
That’s it for this time around. Thanks for reading!
UPDATE: Eric Sloof responded about the updated recommendations regarding VM swap files. The new information was disclosed in session TA2784 at VMworld 2008. See slide 38. Thanks for the information, Eric!
Tags: ESX, HyperV, SAN, Virtualization, VMotion, VMware, Windows
I’m sorry, folks, but I’m not going to have the time or the resources to publish an update to my existing instructions for integrating Solaris 10 into Active Directory. Quite some time ago I had posted that I planned on creating an update to the original instructions so as to incorporate some lessons learned, but it keeps get pushed aside for other tasks that are more important and more relevant to my day-to-day work. Rather than keep readers hanging on for something that will likely never appear, I’d rather just be upfront and frank about the situation. As much as I’d love to spend some time working on the Solaris-AD integration situation and documenting my findings, I just don’t have the time. Sorry.
Tags: ActiveDirectory, Interoperability, Kerberos, LDAP, Microsoft, Solaris, UNIX
After noticing a link I’d added to my Delicious.com bookmarks about a cheat sheet for Linux/UNIX, a reader shared with me a cheat sheet that he had created for VMware ESX. The cheat sheet can be downloaded here, and the reader’s weblog is available here. Thanks for sharing this information!
Tags: ESX, Virtualization, VMware
I’ve had this link sitting in my “Articles To Read” list for quite some time, but—to be perfectly honest—I’ve been just too busy to really do anything about it. Now that a hectic few weeks has wrapped up and I have a small breather before the next hectic few weeks, I wanted to comment briefly on Doug Gourlay’s discussion of FCoE versus MR-IOV.
First, some background: For those that aren’t familiar, FCoE is Fibre Channel over Ethernet, a T11 standard for running Fibre Channel Protocol over Ethernet, specifically 10 Gigabit Ethernet. More information on FCoE is found here. MR-IOV is Multi-Root I/O Virtualization, a PCI SIG specification for using PCI Express (PCIe) to connect and share multiple devices. More information on MR-IOV can be found here. MR-IOV is a multi-server extension to Single-Root I/O Virtualization, or SR-IOV.
Like Doug, I’ll put in a disclaimer that I haven’t read the report to which he’s referring in his article, either. However, as an individual who has done some research on the topic of I/O virtualization, I will say that anyone who compares FCoE to MR-IOV is comparing apples to oranges. These two technologies, in my mind, are designed to address two different problems.
FCoE provides the ability to use a single physical transport—10 Gigabit Ethernet, in this case—for Fibre Channel Protocol (FCP) as well as TCP/IP, iSCSI, and other Ethernet-borne protocols. This allows for the creation of a unified fabric, a single physical transport that carries all the various kinds of traffic that Ethernet-based Local Area Networks (LANs) and Storage Area Networks (SANs) carry separately today. Via the IETF Converged Enhanced Ethernet (CEE) standard—adopted by Cisco as Data Center EthernetTM—FCoE will ultimately have the same low, predictable latency and error-free operation that FCP enjoys today. FCoE is not, however, designed or architected to do anything other than allow FCP to run over Ethernet. It’s not intended to be a server interconnect technology. (Unless I’m missing something?)
MR-IOV, on the other hand, is intended to play in the server interconnect field. Its purpose is not to allow FCP to run over Ethernet, or to allow FCoE, iSCSI, and other TCP/IP protocols share the same physical connections. MR-IOV’s purpose is to allow multiple servers to share PCIe-based devices, like a FC Host Bus Adapter (HBA), or an iSCSI HBA, a 10 Gigabit Ethernet network interface card (NIC), or a video capture card. MR-IOV is intended to provide I/O virtualization, regardless of what type of I/O that might be. As long as the I/O runs across a PCI Express bus, MR-IOV comes into play.
I’ve heard multiple people refer to FCoE as an I/O virtualization technology, but I just don’t agree. FCoE only applies to FCP over Ethernet. It doesn’t apply to iSCSI. It doesn’t apply to video traffic, or audio traffic, or HTTP traffic. It only applies to FCP over Ethernet. While I might allow that FCoE does allow for a form of virtualization, by virtualizing the physical transport beneath FCP, I would not call it I/O virtualization. Further, FCoE and MR-IOV are complementary. You could use MR-IOV to share a single Converged Network Adapter (CNA), which provides FCoE and 10 Gigabit Ethernet functionality, among multiple servers. In this situation, what’s providing the I/O virtualization: MR-IOV, which is allowing multiple servers to use a single I/O card, or the CNA, which is putting the traffic onto the converged fabric?
I’m probably missing something huge here, some vital piece of information that would make sense why FCoE and MR-IOV would be considered competitive standards/specifications. Without that information, though, it just doesn’t make any sense to me to compare these two different yet complementary technologies. Someone want to enlighten me?
UPDATE: I’ve corrected my use of “Data Center Ethernet” to Converged Enhanced Ethernet (CEE) when referring to the IETF standard. As correctly pointed out in the comments, Data Center EthernetTM is a Cisco trademarked term referring to their implementation of CEE.
Tags: Cisco, FibreChannel, iSCSI, SAN, Standards, Storage, Virtualization
It looks like I may be able to blog about some of the content that was covered this week at NetApp Insight in LA after all. I’m still working out the details, but I hope to have things straightened out very soon. Stay tuned to this space for more details!
VKernel, whose SearchMyVM search-based management product I wrote about back at the beginning of September, is launching a community site called CompareMyVM. The site is expected to formally launch in early December.
The idea behind the site, according to VKernel, is to provide a means whereby users can share information on how they are allocating resources to VMs. The idea is that as users share how they are configuring certain VMs for certain workloads, that information may be very useful to other users who are looking for that sort of information. Not sure how much memory to allocate to a small Linux-based web server? CompareMyVM wants to be able to provide that information.
Clearly, the site will only be effective if lots of users contribute information and share their VM configurations. I’ve been out of town all week so haven’t had the opportunity to take a look at the site, but I do plan to do so very shortly. In the meantime, I’d encourage readers to have a look and feel free to report back here in the comments.
Tags: Virtualization





Recent Comments