Louwrentius

If you are running a serious VMware environment, chances are you do have a SAN. Often with smaller setups, many people do employ multiple VMware hosts, but the SAN is a single point of failure.

SANs are often fully redundant devices, with redundant PSUs, storage controllers, network links and RAID arrays. But with all that redundancy build in, they still fail. I've seen it happen and a failing SAN is the worst.

So I'd rather have two cheap entry level SANs if possible than just a single big one and keeping my fingers crossed that they won't fail.

A redundant SAN environment where you basically deploy two separate SAN devices with their own storage needs a replication setup. And replication between SAN environments needs often extra licences or more expensive setups. And the replication mechanism must play well with your virtualisation layer, such as VMware.

But the fun thing is that VMware made everything way simpler by integrating their own storage replication into their vSphere product. I have no experience whatsoever with VMware's new build-in replication feature. But I believe that it is significant.

Replication is a new feature introduced in VMware vSphere 5.1 that is now part of the vSphere Essentials Plus Kit and vSphere Standard. So if you start with two or three VMware hosts and two entry-level SAN devices, you can be quite redundant and can have a fully redundant setup. And that will cost you around 3800 Euro ~ 4800 US dollar.

The Essentials Plus Kit is a nice environment for smaller companies, but license-wise, it does not scale as you are stuck with a maximum of 6 physical CPUs and a maximum of three hosts. However it seems that when you need to expand beyond that capacity, you can trade in your existing license and obtain a discount when upgrading to - for example - vSphere Standard or Enterprise.

The most significant thing about the build-in replication is that it does not matter any more what you use for your storage backend. If you use two entirely different devices from different vendors, that's OK. Because VMware handles all the replication stuff. Those SAN devices become just dumb storage boxes. Most of us just can configure whatever does support iSCSI.

You could even try and be cheap and setup your own homegrown storage boxes. It may not have all the cool features of a true SAN, but at least you have redundant storage.

I'm really curious about this feature and I hope it works well. I'm seriously considering deploying this for the VMware setup of the company I currently work for. It does however require an extra external host that manages the actual replication, which may add to the cost.

Any comments are welcome.

If you want to compile PAR2 with multicore support on Linux, it may not work right away from source. I used this version of PAR2 with multicore support. Update 2015: the original link is dead, I foud a copy of the source and put it on my own site here for you to download.

First, make sure that you have these libraries on your system:

libtbb-dev
libaio-dev

According to this source, after downloading the source, you need to add this line:

#include <backward/auto_ptr.h>

To these files:

par2cmdline.cpp
commandline.cpp
par2creator.cpp
par2repairer.cpp

Then edit the Makefile and find the LDADD variable. Add the -lrt option like this:

LDADD = -lstdc++ -ltbb -lrt -L.

This did the trick for me and compiled the PAR2 source with multicore support. Hope it helps somebody.

If you want to use Multicore PAR2 with SABNZBD you need to go to the Config menu. Then select 'Special' and enable 'par2_multicore'. Save the changes. Then go to 'Switches' and enter '-t+' at the Extra PAR2 Parameters field.

Currently, I am running VMware ESXi 4.1 on a test system. To manage ESXi, you need the VSphere client, which is only available for the Windows platform. Therefore, I run VMware Fusion on my Mac to be able to access VSphere and manage my ESXi host.

The trouble is that both ESXi and VMware Fusion use the control-alt shortcut to release a console. So as soon as you start using a console within the VSphere client which itself runs within VMware Fusion, you cannot get back to the Windows OS.

You will have either access to Mac OS X or the ESXi guest. And to top it of, the mouse just completely disappears on Windows.

To get arount this problem, you need to somehow be able to send a control-alt sequence to the Windows guest withouth actually pressing control-alt.

Fortunately, VMware fusion allows you to create a key mapping that allows this.

Within the preferance pane, the first tab is called Key Mappings. You can create a new key mapping. For example, I mapped control+q to control-alt. This allows me to get out of the ESXi guest within the VSphere client, witouth getting grown back to Mac OS X. As a side effect, the mouse also showed up again, which is to be expected.