- Only for Linux and Solaris x64
- <= 2 CPU cores
- Max of 4 user volumes
I'm not sure I "get" this move. Historically, there has been a philosophical battle going on in the enterprise engineering space over whether 'tis best to manage your root disks with Sun's Solaris Volume Manager (SVM) or Veritas' Volume Manager (VxVM).
On one side, VxVM had the strength of a volume management solution that scaled to infinity and beyond. It's not much more difficult to manage 1000 disks on VxVM than it is to manage 10. The corollary to this point is that if you require VxVM for your data farm, then you can reduce system architecture complexity by standardizing on use of VxVM for management of root disks as well. Simple is good, right?
On the other side, SVM is extremely easy to use, and extremely easy to recover from problems with. Given it's simple layering approach, it's also much more difficult to get into trouble with. SVM has long been a favorite with Sys Admins because it means they never have to worry about the dreaded unencapsulation dance. Again, simple is good, right?
From a purely academic standpoint, the complexity of using multiple Volume Managers seems unnecessary. In practice, I believe the opposite is true. Root disks are a very different beast than data disks. For one thing, they tend to be configured and then forgotten (barring a disk failure). In contrast, the data farm is always churning with reconfiguration or expansion. Given the opposing dynamics of these types of volumes, it makes sense to use tools with different strengths.
When a root mirror pair needs work, you want a simple and reliable way to solve the problem and move on with very little chance of making an unrecoverable mistake. This is SVM in a nutshell. Its tight OS integration, and shallow learning curve mean that even a junior SA has a great probability of pulling off that disk replacement.
Unfortunately, if you have terrabytes of disk storage hooked to your Enterprise 20k you want a volume manager that is very flexible and agile. Historically, SVM has not been that tool. Its GUI does not display huge data farms efficiently, and its volume naming conventions get unruly when the disk count grows. This is where VxVM comes in.
VxVM use abstraction and well designed (although complex) interfaces that allow mountains of data to be displayed quickly through either command line interface or GUI. Historically, it also had much more power and flexibility than Sun's offerings. This meant you needed VxVM for data farms.
The best of both worlds, in my opinion is using SVM for Operating System volumes and internal disks, and VxVM for all external storage whether SAN or DAS. If you only have limited external storage then just use SVM. Really, simple is good!
Returning to Veritas' recent change in marketing strategy, it seems that they may be trying to counter some of the arguments for using Sun's integrated solution. It's clear that ZFS is going to provide a very powerful facility for storage provisioning within Solaris 10, and SVM already supports many of the core features which used to be Veritas' key selling points. Veritas has one key advantage in that they have a time tested solution available NOW. ZFS isn't mature enough yet for the mission critical enterprise, but that's a very short term disadvantage. The OpenSolaris model means that when ZFS makes it into a hardware update of Solaris 10, it's going to be 95% there. I'll give it six months before they master that remaining 5% which wider distribution will open up.
Is the right strategy to pick to seldom-used platforms to make VxVM free on, and then limit use to four volumes on a product which is only advantageous when volumes are plentiful? I don't think so. If you have a simple system you're not going to WANT to use VxVM because SVM is so much simpler.
To me it looks like Veritas is trying to use a seeding strategy for a market that it has no chance of enticing. While Veritas has a great product, it seems that they don't fully understand their niche. I'm putting my money on SVM and ZFS.