Before you begin creating and provisioning virtual machines for your business applications, ensure your KVM hypervisor is capable of sustaining these applications. All the virtual machines will rely on the hypervisor's integrity and availability. The three key areas to initially address are:
- Protecting data and resources by providing secure tracking, audit trails, alert mechanisms, and reporting
- Managing and monitoring resources, and offer interfaces for configuring or modifying virtual machines as needed
- Backing up data and executing data recovery aligned to the application's needs.
Protecting data and resources
KVM hypervisor security is critical because it typically has access to all of the virtual machines' resources under its control. If the hypervisor is compromised, an unauthorized user could potentially gain access to confidential data. Good security practices are essential for establishing business trust. How do you do this? Several open source and commercial tools can help effect good security practices and policies. To establish consistency, the same tools available to secure a KVM environment can also secure Linux virtual machines.
Some of the key software components to secure the KVM hypervisor are:
- FirewallD for network security
- LDAP for centralized authentication
- SELinux for access control policies that confine access to data
- Linux Audit to provide detailed audit trail information you might not find in the system log.
In addition, there is support for cryptographic hardware in the IBM z Systems platform that can perform DES, TDES, AES, RSA, SHA-1, and SHA-2 cryptographic operations. CP assist for cryptographic functions (CPACF) instructions are available to KVM for IBM z and its Linux virtual machines when the kernel modules are loaded.
Managing and monitoring resources
The Linux ecosystem offers open source and commercial monitoring tools by which the KVM for IBM z resources can be managed and monitored. There are three primary methods that can be used:
- The Linux shell in KVM for IBM z is available to handle most any resource configuration. CPUs can be configured on or off, memory can be enabled or disabled and storage devices and network interfaces can be added or removed.
- Utilizing the IBM z Systems HMC, either with DPM mode or with standard PR/SM mode additional processors or memory can be dynamically added to a logical partition. With DPM mode, additional storage devices and network interfaces can be added or configured dynamically.
- Kimchi’s management interface for KVM is http based. It allows for KVM network and storage resource management.
KVM for IBM z provides a number of built in open source monitoring packages such as nagios monitoring plugs, snmp agents, standard libvirt APIs, sar, systemtap, and many more. And if you find what was provided does not exactly fit your needs, KVM for IBM z Systems does provide an SDK. The SDK has the compilers and development libraries need to build perform builds of additional software projects.
Libvirt is a library of open source APIs that includes a daemon and management tools, that are installed with KVM for IBM z. You can create, delete, run, stop, and manage your virtual servers using the virsh command. Besides virsh, there is a graphical tool called Virtual Machine Manager or more commonly “virt-manager”. Virt-manager can handle most of the common lifecycle functions of a virtual server, including installation. It also has basic monitoring, console access, and resource management of the virtual server and some KVM host resources.
Many open source tools are typically included in Linux distributions, and if they are not included you can build them from source. To maintain a consistent approach, chose tools that manage both the KVM hypervisor and it's virtual machines.
Backing up data and executing data recovery
A KVM for IBM z environment can be backed up in a number of ways, therefore when designing your backup and recovery strategy consider the following questions:
- Should the virtual machines to be up and running or require them to be shutdown during the backup and recovery?
- How is the disk storage provisioned to the virtual machine?
- What is the recovery point objective (RPO)?
- What is the recovery time objective (RTO) ?
The KVM hypervisor and virtual machine backups can be categorized as:
- The core operating system disk needed for boot
- The additional storage used to host image files and system logs
- Key configuration files such as for networking and virtual machine definitions
There are multiple ways to back up each of these categories. The core operating system disk could in its most basic form be backed up via Linux dd commands from another system. You might want to do this right after installation. You could also utilize FlashCopy or disk mirroring technologies to create a consistent point in time copy without taking down the KVM hypervisor or virtual machine. To exploit FlashCopy or similar technology, there typically is a requirement to install some command line interface program to direct the FlashCopy operation and to have network connectivity to the console of the storage subsystem.
The additional storage used to host image files could also use FlashCopy or disk mirroring, but other options exist as well. A QCOW2 snapshot or a LVM snapshot are examples of other options that may help you minimize downtime.
Key configuration files such as the KVM hypervisor network definitions, Open vSwitch definitions, zipl.conf, zfcp.conf and others could be backed up via file based tools such as rsync. The amount of storage these files take is relatively small.
It may also be useful to have partition, volume group, LVM, and file system information captured and recorded in the event you need to perform a recovery. This information could be easily gathered on a regular basis and transmitted to a remote archive.
Another option would be to utilize file level backups either with open source tools like rsync or commercial tools like IBM Tivoli® Storage Manager (TSM). If a virtual machine were destroyed one approach might be to provision a new base Linux and restore all the files from the most recent backup, rather than using disk image level backups and restores.
Part of the planning for backup and recovery also needs to consider the middleware. For example a database would typically utilize its own utilities in order to provide backups without any or minimal down time. A comprehensive backup and recovery strategy typically involves multiple backup methods and the recovery from those backups should be regularly tested.
To help make you plan and deploy a successful and effective environment, read Getting Started with KVM for IBM z Systems, SG24-8332 at:
Bill White is an IBM Redbooks Project Leader for IBM z Systems. He works with technical experts from around the globe to produce technical enablement content.