vTeardown

Recently, Oracle has been flooding the airwaves with claims that Oracle VM templates are a better way to deploy the many products in their sprawling software portfolio. We’ve taken a look at those template capabilities and have some comments below, but there are other issues we’ve found with Oracle VM you should be aware of before considering it for a production deployment.

Oracle VM lacks a number of important features and tools that are required to run applications in the enterprise.  Absence of these features in any virtualization solution makes for an enterprise environment that may not be able to meet SLA (Service Level Agreement) obligations to the customers as well as an administrative headache to deploy and maintain.

Here are some of the Oracle VM shortcomings we’ve encountered after trying it out:

• Oracle VM has no built-in capability to integrate with naming services such as Microsoft Active Directory or LDAP.  We all know the shortcut that leads to – just have everyone share the same login.
• Oracle VM has limited RBAC (Role-Based Access Control) capability so you can’t control user permissions with fine-grained customizable access to various objects in OVM.
• Limited guest OS support (OEL, Red Hat, Windows) rules out Oracle VM if your applications run on other OSs like Novell NetWare, SUSE Linux or Solaris.
• Oracle VM has no real workload balancing tool like VMware DRS.  You’ll need to run your servers at lower utilization and keep a closer eye on VMs with spiking loads.
• Oracle VM’s reliance on Xen as its virtualization engine means lower VM density per host as Xen 3.1 has no memory overcommit feature like that of VMware ESX.  Overcommit lowers TCO and add great flexibility to VM management.
• Oracle VM pools are only server pools and not resource pools. This prevents memory and CPU resources from being better managed and shared by VMs in the pool.  You can’t carve out resource pools for your business and let them operate autonomously as you can with VMware.
• Oracle VM has no built-in fault tolerance features and VMs must rely on third party tools for zero-downtime fault tolerance.  The new VMware vSphere FT feature brings continuous availability to any OS, any app, any hardware.
• Oracle VM has no snapshot features. That means developers and administrators are handicapped as they are unable to make instant point-in-time copies of VMs to use to roll back development and administrative activities.
• No patch management utility in Oracle VM means manual intervention or extensive scripting is required to administer patching of hosts and VMs.  VMware Update Manager automates host and guest patching – typically the most time-consuming task for virtualization sysadmins.
• Oracle VM also has no backup utility for VMs and relies on LAN-based backup agents that run in each VM. It is also limited in its capability to take advantage of Storage Array based backup for VMs. Without a snapshot-based backup proxy feature like VMware Consolidated Backup or the new vSphere Data Recovery, backups that run in the guests tie up your network and burn host CPU cycles.
• NIC teaming or bonding support is also missing in Oracle VM and it relies on NIC vendors for support or extensive scripting to provide network redundancy.  NIC teaming and bonding is built into VMware ESX and dead simple to use.
• Performance monitoring in Oracle VM is limited in the statistics gathered and the time frames that can be viewed.  That makes it insufficient for capacity planning or long-term resource utilization monitoring.

Finally, let me say a word or two about Oracle VM Templates.

Virtual appliances like Oracle VM templates are a good way to distribute software in standardized and portable container.  The virtual appliance concept is even better when customers can choose the applications, operating systems and hypervisors to use with those appliances.  However, Oracle has taken the virtual appliance concept and twisted it into another way to lock its customers into a 100% Oracle world.  The point of virtual appliances is simplicity and flexibility, but Oracle templates take away the flexibility benefit entirely.  No prudent DBA, system administrator or IT Manager that I know of would deploy these locked-down templates as gold image in their production enterprise datacenter.  Those users need appliances that can be adapted to their own requirements Those customizations can be choice of OS, file system layout, performance tuning kernel parameters or security requirements for package deployments. The restricted Oracle VM templates at best can only serve for preliminary validation of Oracle’s products.  Their templates have a fixed configuration and they only support Oracle’s own OEL operating system and they can run only on the Oracle VM hypervisor platform. It sounds like the perfect strategy for a top-to-bottom lock-in.  Not many CIOs will want to accept that degree of control by a single vendor.

It will be interesting to see what impact the purchase of Sun Microsystems will have on Oracle VM’s roadmap. Sun brings their own Xen-based hypervisor to the party with xVM and it’s supposedly a pretty good implementation, however, I have yet to see a copy of Sun xVM in the wild.  Will Oracle keep both Xen products alive or is one headed for the dustbin?

Recently, my inbox was overwhelmed with notifications about news on Citrix Essentials for XenServer.  (Ok , I admit… my spam filter was not set for the word ‘Essentials’.) I was almost sold on thinking this is the greatest thing since sliced bread until I got my hands on it to see what all the fuss is about.

We already knew that XenServer5  had a shortcoming that is showstopper for most enterprises – every user with login access to the management UI gets full root access to all management hosts and VMs.  When prospective customers ask us how VMware Infrastructure compares to our competition and we tell them about this one issue, we see their eyes bug out in surprise, especially if they operate in a security and audit conscious environment like a bank or government agency.  They simply can’t consider a virtualization platform without access controls and audit tracking of logins and configuration changes – features that VMware vCenter has provided for years.  Burton Group’s Chris Wolf made this issue his primary reason for rating XenServer “not enterprise production-ready”.  In fact, only VMware ESX made the production-ready cut in Chris’ ratings.

Would the now free XenServer, managed by the not-free Citrix Essentials for XenServer, patch up that gaping security hole?  The Citrix Essentials for XenServer trial download just recently became available and, once installed, I quickly saw they had not fixed the issue and XenServer will stay a  liability in any enterprise datacenter.

XenServer root-access only is a critical security flaw

After I connected to my XenServer 5 Server Pool using XenCenter (strangely enough, despite all the fuss about the Citrix Essentials management tools, the XenServer management console is still called “XenCenter”), I was amazed to see I was still allowed root console access to the hypervisor. It seems that there is no way to create accounts other than root that can use XenCenter to connect and manage the virtualization environment. Of course I don’t need to explain what a critical security flaw that can become if the XenCenter console is compromised – the attacker gets the keys to the kingdom – hosts, VMs, everything. Also , it seems that there is no built-in feature to integrate XenServer with any naming services such as Active Directory or LDAP and you may have to buy additional licenses for third- party software (Citrix mentions Centrify in their documentation) to provide that service for your XenServer  environment.  It appears that even though an extra cost third-party directory service connector might let you control who can access XenCenter, every user granted that privilege still has full root access to the entire XenServer environment.  We’d like to hear from anyone who’s tried XenServer with Centrify who can verify this all-or-nothing situation.

XenServer’s lack of RBAC is a critical security and operational shortcoming

RBAC ( role-based access control) is an approach to restricting VM, hypervisor or pool access to authorized users. Within a virtualization solution, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles and those roles are then granted to users registered in your directory service. Some useful  pre-defined roles you can choose in vCenter are Administrator, Manager, Virtual Machine User, NOC operator  or Read-Only, and you can also created fine-grained custom roles..

XenServer has no such capability and  gives all users  the same root-level of control over all objects. This can create an administrative nightmare as you are unable to delegate limited privileges and assign roles to  various members of your organization where granting full privileges  is not allowed.

RBAC is now integrated by many OS and application vendors in their products to support financial, government and businesses customers who have made it a mandatory feature for  managing their large networks.  Those users don’t allow  components lacking RBAC into their environments.  Unfortunately for Citrix, XenServer seems to be one of those products that will remain off-limits.

As we continue to look at XenServer and Citrix Essentials, I’ll point out in upcoming posts a number of shortcomings seen in our initial hands-on evaluation that will demonstrate why the combination falls short of enterprise datacenter requirements