Desktop virtualization packages rely on snapshots and virtual drive functionality. The de facto functionality standard here is found in VMware Workstation and VMware Server, but the tools in Sun’s VirtualBox may be setting a new standard. Let’s take a quick look at how snapshots and virtual drives work within Sun xVM VirtualBox.

VirtualBox snapshot technology provides the same basic functionality as the VMware products in that they can be taken while the virtual machine (VM) is running or offline.  The snapshots are taken from two different places depending on the state of the VM. For a running VM, the snapshot is taken from the running console as shown in the figure below.

When a VM is powered off, snapshots may be taken in the properties of the VM. This difference is a slight inconvenience, but is an easy learning curve to overcome. Further, if a VM needs to revert to a saved snapshot, this same location is where the VM would be reverted. VirtualBox gives the option to build from the snapshots, so there can be multiple point-in-time restores for a single VM. Snapshots in VirtualBox are kept in the .VirtualBox\Machines\VMName\Snapshots location by default, and are a collection of .VDI and .SAV files. The figure below shows three point-in-time restores for a single VM:

As with all snapshot restores, you should be sure that you want to restore as the reverting process is authoritative to the VM. Reverting to a VirtualBox snapshot taken while the system is running reverts precisely to that point with the VM running, rather than a powered off state. Overall, the functionality inventory of VirtualBox snapshot functions as advertised and brings another positive view to this exciting virtualization platform.

More information on the VirtualBox 1.6.x product can be found in the online user guide.

You may hear the term SCSI reservations frequently when dealing with VMware servers that utilize shared storage. SCSI reservations are used to ensure exclusive access to disk-based resources when multiple hosts are accessing the same shared storage resources. In addition to being used by VMware hosts, SCSI reservations are also used by Microsoft Cluster Server.

SCSI reservations are only used for specific operations when metadata changes are made and are necessary to prevent multiple hosts from concurrently writing to the metadata to avoid data corruption. Once the operation completes the reservation is released and other operations can continue. Because of this exclusive lock, it is important to minimize the concurrent number of reservations that are made. When too many reservations are being made at once, you may receive I/O failures because a host is unable to make a reservation to complete an operation because another host has locked the logical unit number (LUN). When a host is unable to make a reservation because of a conflict with another host, it will continue to retry at random intervals until it is successful; however, if too many attempts are made the operation will fail.

Some examples of operations that require metadata updates include:

• Creating or deleting a VMFS datastore
• Expanding a VMFS datastore onto additional extents
• Powering on or off a VM
• Acquiring or releasing a lock on a file
• Creating or deleting a file
• Creating a template
• Deploying a VM from a template
• Creating a new VM
• Migrating a VM with VMotion
• Growing a file (e.g., a Snapshot file or a thin provisioned Virtual Disk)

Having a minimal amount of reservation conflicts is generally unavoidable and will not have a big impact on your hosts and VMs. To avoid having too many conflicts, try to limit the number of operations that can cause reservations and stagger them so too many are not happening simultaneously. All reservation errors are logged to the /var/log/vmkernel log file on each ESX host. To reduce the amount of conflicts:

• Limit the number of snapshots you have running, as snapshots grow in 16MB increments and every time they grow they cause SCSI reservations.
• Only vMotion a single VM per LUN at any one time.
• Only cold migrate a single VM per LUN at any one time.
• Do not power on/off too many VMs simultaneously.
• Limit VM/template creations and deployments to a single VM per LUN at any one time.
• Consider using smaller LUN sizes (<600GB) and do not use extents to extend a VMFS volume

On Monday, June 9, Symantec Corp. of Cupterino, Calif., announced the release of Veritas Virtual Infrastructure (VxVI), a server and storage virtualization product built on Citrix Systems Inc.’s XenServer technology. By exploiting Veritas’ block storage management model, VxVI hopes to compete with VMware-Infrastructure-3-in-production environments by offering increased capabilities for storage and availability-critical systems.

The new Xen-based virtual infrastructure platform from Symantec provides storage management and high availability with cross-platform connectivity for the virtual data center. It’s essentially XenServer with the Veritas storage management layer on top — all wrapped in a Symantec management console.

According to Symantec Senior Vice President of Storage and Availability Management Rob Soderbery, the time is right for a product that addresses the needs of testing and development, needs that have been underserved by VMware. “Users understand the storage management challenges with VMware,” he said. Symantec has delivered something “fundamentally new” in how server virtualization works with storage management, he noted.

The key difference between VMware and Veritas is in how each handles virtual machines (VMs). Soderbery argues that the Virtual Machine File System (VMFS) file-based system that VMware uses can’t compete with the block storage system of Veritas VxVI.

As enterprises build out the x86 data center, Symantec’s product seeks to serve those who want to bring physical capabilities into the virtual environment. Veritas Virtual Infrastructure brings dynamic storage layouts, enclosure and array mirroring and storage-area network (SAN) multipathing/load balancing to server virtualization, adding features such as shared VM boot images with which Symantec hopes to lure VMware customers that are not satisfied with the storage capabilities of the leading server virtualization platform. 

Soderbery says that VxVI will work well with Microsoft’s forthcoming Xen-inspired hypervisor, Hyper-V. “Microsoft has done something pretty interesting here in being open to the Xen community and encouraging the Xen community to be open with Microsoft,” says Soderbery. “Veritas Virtual Infrastructure is technology that we can apply across the Xen ecosystem and Hyper-V as well.”

With another Xen-based virtualization product on the market engineered to be more compatible with the forthcoming Hyper-V, VMware may feel the pinch as users see more options with the other big players in the server virtualization market. But will the $4,595 per two-socket server for Veritas discourage VMware users from even running a demo?

What do you think? If you plan on deploying Veritas VxVI, we want to hear from you. Send us your thoughts via email.

I was recently asked, “do you have any visibility of the storge utilization you provide your virtual machines?” I stopped, thought about it and said “no”. However, in my situation, this is not yet a problem.

A pitfall for most enterprise server virtualization strategies is in a reservation for storage, regardless of what the virtual machine has written on the virtualized filesystem to the defined maximums. For example, if I have a base installation of a Windows Server 2003 system, the footprint as I do my server builds will be around 5 GB. My standard build allocation is 32 GB. This makes this system only 15.6% utilized from inception. This rule of thumb applies to most servers, and a standard build has 32 GB as an accepted footprint per system. 

Excluding backend storage virtualization and de-duplication strategies, what about systems that have a storage footprint larger than 32 GB? Well, luckily we’ve been down this path before:

The storage is the storage, virtual or physical.

Managing the percentage of utilization for shared storage should be a task of continuing diligence. I don’t (yet) have a large number of virtual servers with a footprint above the standard build, these systems face the same battles we have had for years with general purpose servers.  As an example, take a main file and print server that is 2 TB on a general purpose server: It will be about 2 TB on a virtual server as well from the storage perspective. For large storage footprints using iSCSI or storage-area network (SAN) technologies, the difference in configuration is minimal.

However, how do we address the first question about under-utilized storage footprints for the virtualized systems? Is it best to look only at operating system metrics? That may be an adequate solution for each operating system, but the aggregation will be from different sources and outputs. What are you doing to address storage utilization when you are not using storage virtualization?

Since I just love to read white papers (n.b., sarcasm), I grabbed a copy of VMware’s Comparison of Storage Protocol Performance. Actually, I found it to be a good read. It’s short and to the point. This sums it up quite nicely:

“This paper demonstrates that the four network storage connection options available to ESX Server are all capable of reaching a level of performance limited only by the media and storage devices. And even with multiple virtual machines running concurrently on the same ESX Server host, the high performance is maintained. “

The big four storage connections are:

• Fibre Channel (2 GB was tested)
• Software iSCSI
• Hardware iSCSI
• NFS NAS

The paper infers that network file system (NFS) is perfectly valid for virtual machine (VM) storage, performing in all of the tests at a level comparable with software iSCSI, very close to hardware iSCSI and lagging behind 2 GB Fibre Channel (FC). This doesn’t surprise me one bit: I like NFS network-attached storage (NAS) for VM storage. I prefer storage area network, or SAN-based storage because I prefer to store on a virtual machine file system; but for low-criticality VMs, NAS’s price is right (well, as long as you don’t count Openfiler, IET, etc.) Also, it’s plausible to build out a virtual infrastructure storage architecture using nothing but Fedora Core and be supported.

I was particularly interested in the FC vs. iSCSI performance results presented in this VMware white paper. At the lowest end of the scale, iSCSI beat FC. Granted, the low end of the scale isn’t what will be seen in most production environments but it is  interesting data. What I liked most was that nowhere did 2GB FC truly outclass 1Gb iSCSI. It was faster in most of the higher I/O testing, but never did it double the performance. 2 GB FC did show a big performance improvement in the multiple VM scalability test but not double (about 185 MB per second vs. about 117 MB per second).

On to what I didn’t like in this white paper:

• No 4 GB FC comparisons. 4 GB FC is the sweet spot for high-performance enterprise SANs being put in place to support the big iron now being virtualized. It should have been covered, even if it is still a little bit of a nascient technology (well, not in terms of maturity but in terms of it’s market segment.)
• No 1 GB FC connections. (There are still plenty out there.)
• No NIC Teaming comparisons. I want to know how much additional CPU overhead is involved. I want to know how much performance is improved if you team NICs on your software iSCSI targets and initiators.
• No multipathed comparisons. This should have been done. Mutipathing is a way of life for anything as mission critical as a server that hosts multiple servers.
• No 10 GB Ethernet iSCSI comparisons. VI 3.5 is out. 10 GB Ethernet support is built into VI 3.5 (see the HCL, page 29.) Not to test this is a big oversight.
• No internal-disk storage was tested. Ok, maybe it’s not reasonable for me to expect this to be tested. Maybe I’m just grouching now.

I was surprised to see that software iSCSI got its tail handed to it in CPU workload testing. I’ve never done this testing but I knew there was a big overhead involved. I just didn’t expect it to be that big, especially compared to NAS, which I expected to be right there with iSCSI rather than much more CPU efficient (FC was the 1.0 baseline, NAS scored about 1.8-ish 1.9-ish, and SW iSCSI was about 2.75.) This means one thing: while performance is great across all protocols, plan on extra CPU power for software iSCSI.

I was pleasently surprised to see hardware iSCSI dead-even with 2 GB FC. I had expected some additional overhead even with dedicated hardware, but that wasn’t the case. I would expect to find that in a dedicated iSCSI solution–unless you’re using really cheap equpment like hooking up a couple of big drives to that old desktop–you won’t hit the CPU-use ceiling unless you fail badly at planning.

All of these protocols are perfectly valid. There could have been more meat in the paper, but it did a good job of accurately testing four of the most common storage architectures used with VMware’s products.

Overall, I give this white paper seven “pokers.” Why pokers? Because stars and 1-10 ratings are common. Pokers are mine. Because fireplace pokers can jar you into action if you get bit by one, seven pokers means you should read this paper if you have any responsibility for virtualization.

If one thing annoys me to no end, it is unused capacity.

That’s why I like virtualization. And it’s also why I like grid computing. Heck, that’s why I like cheeseburgers (there’s no empty space in my stomach after a trip to In-and-Out.) Virtualization makes efficient use of existing hardware to control costs. VMware environments often have host servers with more than a small RAID1 array in them because they were existing servers retasked as ESX hosts. Sometimes this space gets used for ISO file storage, sometimes it gets used for virtual machine toys (so called gray- or black- boxes) and sometimes it’s used for production VMs. Labs are often set up on the local storage with machines that have no production value hosted, which makes great use of that space (but perhaps not as good of use of CPU or memory for production machines).

A case study in space, storage and VMs
Then there are times when I walk into sites like the one I saw last week. They had a virtual-machine iSCSI SAN set up on each ESX host homed to the local storage. This was in addition to their FC SAN, by the way. They even ran part of their production environment off of it, using the unused internal disk space on the ESX servers to store virtual appliances that ran iSCSI Targets in them, similar to what I described in an earlier post. What a great use of space. Kudos to them!

I was concerned about how they were to keep those virtual machines up in the event of host failure. First I was told that they put in a poor-man’s round robin, which is to say, host 1 has iSCSI SAN 1, host 2 has iSCSI SAN 2, 3 had 3, and 4 had 4, and they all replicated to each other; VMs hosted by ESX 1 were on SAN 2, those on ESX 2 were on SAN 3, those on ESX 3 were on SAN 4, and those on ESX4 were on SAN1. Then, anti-affinity rules were used to prevent VMotioned VMs from winding up on the same host as the SAN on which their files existed. The replication prevented any single SAN failure from becomming a nightmare. They hadn’t done anything unusual on the network side though, which bothered me (I would prefer dedicated physical NICs for the SAN VMs!), but their performance testing showed no need for the extra NICs to be added. It’s a little hard to follow-the-leader, but it worked reasonable well. This was done with a variety of open-source packages, some of which I had never seen before. I recognized IET right away, but the SAN appliances were all custom builds, and it took me some time to figure out what was what and what was going on where. It was not an efficient use of that internal disk space because of all the replication across servers being, essentially, mirrors of mirrors.

Ingenious? Yep. Complicated to track? Yep. Functional. Yep. Needing of a little less work to manage? Yep.

There are commercial products to do this, one of them is LeftHand Network’s Virtual Storage Appliance. I’ll post more about my experiences with this very soon.

Using Storage VMotion (SVM) from the command line is fairly straightforward. However, a lot of admins may not be comfortable with the inefficiency of taking extra steps to perform a task that can be better handled via an integrated GUI tool.

It’s a feature that was clearly lacking in the VI 3.5 / VC 2.5 product release. It’s one that should have been addressed by the product team but wasn’t (I suspect for reasons related to release dates more than anything.) I looked at a few of the graphical tools for managing SVM, and found a couple of them to be pretty robust. One comes from fellow TechTarget blogger Andrew Kutz, while another comes from developer Alexander Gaiswinkler.

Gaiswinkler’s application is pretty neat and does  good job outputting information. It takes the remote command line interface (CLI) utility for managing a VMware environment and adds a graphical layer to it. Setup is relatively simple and quick, taking a few short steps. I would expect, if a firm were to make a product around it, an installation package would be able to handle the process easily. Simply put, to install the SVM GUI, you need only follow the following:

• Install VMware’s remote CLI
• Save the vms.pl script to %PROGRAMFILES%\VMware\VMware VI Remote CLI\bin\
• Save the svmotiongui.exe to your PC (I put mine in %PROGRAMFILES%\VMware\SVMGUI\ (a directory I created manually, but it really doesn’t matter where you put it)
• Launch said exe file

In testing, I was able to SVM several vmdk files across my iSCSI data stores without incident. My only complaints about the application are that it’s seperate from the VI client interface and that it needs to be documented. But it’s a great tool even without that integration.

I also took Andrew Kutz’s plugin-based SVM GUI for a spin, and was equally happy with it. Because it’s an actual plugin for the VI console, integration was a given. The installation was smooth, just like installing any add-on. The steps are:

• Launch the server and client installers from your VC host and clients and follow the prompts
• Open your VI Client, go to Plugins, and the Available tab
• From the Click Download and Install Plugin
• Follow the prompts again
• From the Installed tab and check the box

I sent the same virtual machines flying around the iSCSI skies again without the slightest problem. While it’s not at a 1.0 release, I was so impressed that I’ve moved it into production. The one downside I’ve found is in the two seperate installers, but since that’s a relatively common practice for server and client-side applications that’s not much of a downside at all. I would personally like one installer which can detect the presense of the VC server, run the server installer if it is present, then run the client installer.

The seperate GUI application is solid. On a scale of 1-10, 10 being terrific, I’d have to give it an 8. The VC integatred client gets 9. Both are great tools, but Andrew’s plugin-based model is tops in my book. Both could use more documentation, and a more streamlined install processes, but neither one is badly in need of either. Both do a great job.

Bad luck sometimes follows you. Then again, I don’t believe in luck, or its evil twin Murphy’s Law.

Still, bad stuff happens, and in IT, you’re usually there to see it. This happened at an undisclosed location near a super secret military installation next to a classified roadside diner in an unidentified town west of an unnamed river. In other words, my office, the place where I’m both the head VMware and Citrix person and the IT Director (which may give me multiple personality disorder someday, but at least I won’t rust out!).

Arriving at 8:15AM, as I’m wont to do in order to get a jump start on the day, I get an angry mob assaulting me with torches and pitchforks before I’m even to my office. That usally means a big problem, and in this case, nothing’s running. No problem, probably just a power outage knocking things around again. We have frequent outages here, and since we’re not a 24×7 shop, sometimes the UPSes run out of juice and I sometimes have to restart things by hand. Normally everything shuts down gracefully, but on this occassion, the whole place was a mess.

A quick check of server health and I see that all of my physical boxes, including my SAN and VI hosts, are up and running and have been all night. I log into VC to see exactly what I had expected: lots of powered-off servers. Now had there been an event, these servers should have VMotioned off to other servers, and failing that, come back up automatically in a set order. They didn’t. That’s usually a SAN-related issue.

Ok, I check the SAN and see that it’s fine now, but showing uptime since a little past midnight. It’s looking more like the power outage was long enough to take down the UPS that the SAN was on, but not the VMware servers, which shouldn’t be the case unless there are battery problems I’m not being alerted to by APC’s software. Guess what? Yep, that’s it. Ok, lets restart some machines - Linux servers all come up wonderfully. Windows servers, not so much on some of them. The blue screens of death are visible as far as the eye can see — so blue, I thought I was in the Caribbean, except for the stress and lack of rum-based drinks.

Most of them are reporting disk and kernel related problems. Most of the error messages relate to a missing %WINDIR%\SYSTEM32\CONFIG\SYSTEM file. Another common one reports that NTOSKERNEL.EXE is missing. Great, that’s a huge part the registry and the system kernel. This is gonna take days to fix if I have to pull backups and restore from them. Well, maybe not if I’m lucky and its just some corrupted space on the virtual disks.

Treating them like physcial machines, the next step is to boot the recovery console from CD (in this case an ISO file) and run chkdsk with the /p and /f switches as a first step to troubleshooting. Except of course, that there’s no hard disk to be found by the Windows installer, which cause a brief, although painful heart flutter at the though of pulling from backup. It’s one thing to do a quarterly test, it’s another when it’s real. Successful tests or not, massive documentation and howtos or not, the worst starts to flash through your head. You question your methodology: no matter how thorough you tried to be, you begin to think that maybe the test methods were somehow flawed and the backups will fail. Ok, the problem at hand is that I can’t get the disks to be seen by the Windows installer CD. Time to focus and forget doubt.

And this is where it becomes about virtualization, in case you thought I was going off-topic.

Fear pushed aside, it’s time to look at this from a hardware point of view, but also to remember that the hardware is all virtual. A common pattern emerges: the machines in trouble are all converted machines from an existing VMware Server 1.x install that we P2Ved some time ago. It wasn’t something I noticed right away, as a few of those machines were never P2V-ed, some were P2Ved by hand (i.e., just rebuilt), and our Linux VMs from that same VS box are all fine.

The common denominator is that all of the problem boxes had the Bus Logic SCSI controller. None of them would see the virtual hard drives. Switching over to the LSI Logic controller and accepting the change allowed me to run the recovery console, as the Windows installer saw the disks. It was a quick fix: from the recovery console, I ran the disk check and recovered with no further steps needed.

So, I get the Windows boxes back up, curse Murphy for his Law, and vow that in all future conversions, I will change over the controller before the converted box goes into production. Oh, that and I will have some people in to look at the UPS situation. Now, where are those rum-based drinks?

Based on the volume of media coverage, explosive growth of iSCSI storage area network (SAN) companies and my own experiences, I think it’s safe to say that NFS and iSCSI SANs have begun to prove their worth as valid storage platforms with VMware’s Infrastructure 3, and both are also a lot cheaper than 2 GB and 4 GB Fibre Channel SANs. This has made it very interesting to those who are in the lower-tier of purchasing power - namely the many small and medium-sized companies that can’t afford the initial acquisition costs (the bulk of my clientele, by the way). That brings in the great equalizer - open source NFS and software iSCSI solutions, though given a choice I prefer iSCSI, because it can support VM partitions.

One of these OSS iSCSI packages is called IET, the iSCSI Enterprise Target, and it’s rolled into a Linux distro called Openfiler, a distribution focused on being a storage platform. Before we all rush out and use Openfiler for all our needs, IET itself has had some problems with supporting VMotion, so it’s earned a bit of a bad rap. In fact, there are often wails of protesters screaming about how IET is unsupported by the good folks at VMware because of the way two SCSI commands are structured and how that can hose a VMotion move. Luckily, there’s some good news on that front.

The truth be told, the good news there is only half-good. IET’s release 0.4.5 addresses those problems. The better news is that this update is rolled into the latest patches for OpenFiler (which has a self-update option, just like any other distro). There’s a nice link in a blog here. The reason it’s only half-good… IET is still not supported, patch or no patch. Still, I’ve been using it in the lab, and it works just fine for me. I’ve done 1, 2, and 10 VMotion moves by manipulating DRS, both manually and automatically, and haven’t hit a snag yet. That said, it isn’t supported.

Hitting an Openfiler target with VI3.5 is easy. First, install OpenFiler, ESX and VirtualCenter and configure them. I will skip most of the details of basic setup, as it’s superflous. Openfiler’s install guide is here, but the Petri IT Knowledgebase has a specific article that covers soup-to-nuts here. I’ll post another below that’s a little shorter and to the point. You’ll need to create the virtual machine on the local disk of the ESX host (otherwise, what’s the point?) and configure it to take up just enough, but not too much of that precious internal disk space. In my example, I built a virtual machine with two virtual disks (you can do it with one, if you want). The trip from an unallocated lump o’ disk to iSCSI-enabled volumes went like this:

Part One: Disk Management

Set up your physical storage from the get-go. During setup, I chose NOT to do anything to the second drive - which is to say, I didn’t let Disk Druid touch it at all. When Openfiler boots, and you have your basic settings done, things like ntp, the admin password, etc., go to the Volumes button, and click on Physical Storage Mgmt. From there, create the extended and logical partitions you will need to get your iSCSI volumes up. The steps, once Openfiler is up, look a little like this:

The basic setup. System, and nothing else:

Creating the Extended Partition:

Creating the Logical (Physical) Partition:

The Partitons on the Second Drive:

During creation, I ran into a problem on both machines I did this build on - in each case I had created the logical partition, but OF didn’t see it. I had to go delete it, and create it again.

Part 2: Creating the LUN

First up, enable the server to act as an iSCSI Target. This is done from the Services tab, under Enable/Disable. In this example, I’m only using iSCSI, but if you wanted to enable NFS, this is where you would do so. Mine looked like this:

Then, go back to Volumes, under Volume Group Mgmt, and create the iSCSI volume group. In this example, I’m using the whole disk, but you don’t have to.

The before and after looks like this:

Next, head over to Create New Volume (one tab left). Creating a volume is, like the rest of the process, relatively straightforward. I made one volume, comprising the entirety of my one Volume Group. Having chosen the name”san” (how creative of me) for the process, I kept with the same simplicity for the volume I created.

After that, you are forwarded to the List of Existing Volumes tab. Congratulations, you have an iSCSI SAN. Now, about configuring that SAN…

Part 3: Security

There are two ways to lock down your SAN. One is via the network, and choosing only to allow certain hosts or networks access to the SAN. From the List of Existing Volumes tab, select the Edit link under the Properties column. You will then be presented with a screen called Volume’s Properties giving you a number of options for securing the LUN. I won’t dwell too much on the network access restrictions, as my screen captures will be different from other networks. The long and short of it is that in the General tab there is a sub-tab called Local Networks. You can create individual hosts and subnets there, and then allow or deny access to these networks on the Volume’s Properties tab.Using MS-CHAP to lock down who can connect to your target is a much smarter plan.

Part 4: Getting VMware to See Your LUN

This is extremely straightforward, and is no different than any other iSCSI implementation. The only thing I’ll mention here is something that is left out of many, many documents. Open the ports for iSCSI on your ESX hosts! In 3.5, it looks like this:

There are a lot of considerations that need to be addressed about what you keep there, chiefly around reliability and performance. For example, if you put virtual machines in the iSCSI SAN on the physical host, when the physcial host dies, it takes the SAN with it, along with all those virtual machines. Another consideration is networking. The long and short of it is this - if you have a whole lot of unused disk space on your ESX hosts, you can use Openfiler to put stuff there. As to what stuff, that’s entirely up to you. I personally prefer iso files and other junk that doesn’t need to go anywhere or do anything, and isn’t going to hurt me when something fails. Of course, you could also use NFS, which Openfiler supports.

The end result, Openfiler gets a solid 8 pokers from me. I give it a ten for being a soup-to-nuts full-featured distro that I can use at almost any client site for almost any purpose. If this were a storage column, it would remain a ten. It drops back because they haven’t yet earned a nod from VMware, which is something I would have expected them to pursue, considering their growth and media attention lately. What makes it frustrating is that Xinit systems, the company behind the project, makes storage appliances. Since they’ve been producing Openfiler since 2003, I think it’s about time they got on the move with this!

I am blogging from the inaugural Technosium Global Conference and Expo at the Santa Clara Convention Center. I’ll be signing on intermittently to provide you with everything I consider beneficial to the virtualization space.

First off is storage business continuity. I had an opportunity to attend a breakout hosted by Eric Herzog, the vice president of operations for Asempra Technologies. While business continuity is a topic we all are familiar with, attendees had the chance to look at the building blocks of a successful strategy for continuity, and how it applies to storage for virtualized systems. What I took away from this breakout was that there needs to be clearly defined goals that the business requirements define the following within an organization’s service level agreement (SLA):

• Ability to measure availability and uptime
• Data loss tolerance for your business needs (financial and operational)
• Disaster recovery time frames made specific to your environment
• Solutions that reduce costs with combination of technologies with reduced complexity
• Ensuring that the SLA leverages the existing infrastructure (hardware, software, networks) as much as possible
• Ensuring that there will be usable data on first recovery

Traditional approaches to data continuity to virtualization systems tend to respond with multiple technologies, various products, limited manageability and control, increased costs and expense, and a cumbersome process that limits successful execution of the SLA. While each storage business continuity strategy has positives and negatives, the right solution will depend on your virtualization availability requirements. Among the newer storage technologies are drive snapshots, data deduplication, and remote replication. Some solutions address actual virtual machines, where some address the shared storage systems that host virtual environments. Remote replication provides the fastest recovery time for a virtualized storage system, but also at the highest expense.

In summary, the business continuity strategy for virtualized systems needs to resolve primarily around the technology behind the storage systems in use. The other challenge to virtualization management is to define the goals of virtualization continuity via an SLA.