Oracle VM Manager as an Appliance
By PoorFrodo on Mar 18, 2014
I manage a small server environment where I develop and document best practices for Oracle VM. It’s not large but I have about ten different Oracle VM labs; each lab consists of two to five servers and an Oracle VM Manager.
Needless to say I don’t really want to spend a lot of my
time managing the lab so I deploy the Oracle VM Managers in a way that makes it
really easy to recover from my little destructive experiments. I “containerize” the individual lab environments
so they are completely isolated from each other on the storage array. Everything about each lab is contained within
individual volumes on a storage array - I cannot emphasize enough what an important role storage plays in building a robust, resilient and scalable Oracle VM environment.
What I Mean by Appliance
The concept of containerization naturally extends to the Oracle VM management server for each lab. I want each of my Oracle VM Managers to be simple to install, manage, backup and recover so I treat each Oracle VM Manager as an appliance. What I mean by “appliance” is deploying the Manager as a completely self-contained service by installing the product onto a single Oracle VM guest using MySQL as the database engine. This is a no fuss, no muss deployment of Oracle VM Manager with a couple solid, automated levels of backup.
Full, Hot, Daily Backups are Automatic
My first level of back up for Oracle VM Manager database is enabled automatically when you install the Manager using MySQL as the database engine. Full, hot, daily backups are enabled right out of the box whether you want it or not; you do absolutely nothing to configure it, enable it or use it. How great is that?
I change the backup path for MySQL in the /etc/sysconfig/ovmm file from the default location under /u01 to a NFS mount point I call /ovmm-backups. The NFS export is served from the storage array where I perform automated daily snapshots. My Oracle VM database is protected on a daily basis and it only takes about 2 minutes to restore to the previous day or the previous two weeks. I can also take ad-hoc backups at any time just before I plan on doing anything stupid or dangerous.
My next level of backup is through the use of automated daily snapshots on the storage array. Since everything about each lab is contained within its own space on the array, I capture everything about each individual Oracle VM lab environment in a single snapshot in a few seconds. When I say I capture everything, I mean everything. I can recover anything about each Oracle VM lab from any day as far back as a month in a few minutes: pool file system, storage repositories, the Oracle VM Manager as well as physical disks and NFS passed directly to the Oracle VM guests.
The Appliance Concept Makes the Manager Portable
Since the Oracle VM Manager is completely self contained on a single Oracle VM guest (virtual machine), I can restore the entire server by restoring a single file from a snapshot on the array. This is why I like to refer to it as an appliance: its a single unit; easy to restore, easy to move to another server pool, easy to start anywhere that runs Xen - with or without Oracle VM running.
There are many additional advantages to deploying Oracle VM Manager as an appliance contained within an Oracle VM guest using MySQL, but the primary point I would like to make is that the design, implementation, backup and recovery of the Oracle VM Manager and database become very simple while very robust at the same time.