Generic Libvirt Utility Extensions (GLUE)

Libvirt is an OpenSource (LGPL) toolkit to interact with the virtualization capabilities of recent versions of Linux (and other operating systems).  It provides a generic API to manage Xen, KVM, QEMU, LXC, OpenVZ, User Mode Linux, VirtualBox and storage on IDE/SCSI/USB disks, FibreChannel, LVM, iSCSI, NFS and filesystems.  It is a C library with bindings to a variety of languages including Java, Python,  Perl, OCaml, and Ruby.  It is also a CIM provider for the DMTF virtualization schema and a QMF agent for the AMQP/QPid messaging system. It provides remote management using TLS encryption and x509 certificates, remote management authenticating with Kerberos and SASL and local access control using PolicyKit.

In our work we are extending libvirt to be more generic, along with adding support for cloud datacenter utilities, and adding drivers to support IBM specific products and initiatives.

 

Network Virtualization

Service Principles
The RESERVOIR project addresses key issues that lay in the heart of Cloud Computing. Most notably, RESERVOIR defines principles for constructing a global Platform as a Service (PaaS) including:
(1) Separation of concerns between the service customers using the PaaS and Infrastructure Providers such that mutual dependency is reduced.
(2) Isolation of customer services such that a customer experiences the look and feel of a dedicated service while being billed based on shared resources.
(3) Elasticity of services allowing customers to grow and shrink their resources in view of real world demand.
(4) Federation, such that Infrastructure Providers may construct independently administered sites that collaborate to construct the offered global service. 

The IBM Haifa RESERVOIR team is developing technology called Virtual Application Network (VAN) to solve problems with network virtualization in a cloud, and to support the RESERVOIR principles of Separation, Isolation, Elasticity and Federation.

Virtual Application Networks (VANs) are a host side solution that allows hosts to construct a fully virtualized network service overlay on top of a standard IP physical network.  VAN highlights include:

• VANs are private to the hosted customer and managed by it, allowing customers to determine their own address space.
• VANs may extend beyond the limits of a single data center (physical and administrative) without requiring coordinated management and while maintaining data center independence and security.
• VANs are established ad-hoc without requiring pre-configuration and/or management control of the physical network
• VANs are scalable (number of VMs in the virtual network, number of physical hosts, number of virtual networks, etc.)

Value Proposition of VANs for IBM and Customers
VANs are developed to contribute to IBM cloud computing offerings and IBM customers. In particular, VANs enable:
(1) connectivity between workloads, and
(2) migration of workloads across data center subnets and across data centers.

Some of VAN features are notably designed to fit into an enhanced offering by IBM systems and/or as part of IBM services.

• VAN technology is a host side solution and does not require control over the physical network of the data center or that between data centers.
• VAN technology offers true virtualization of network services and decouples the network concerns of the customer from that of the infrastructure
• VAN technology automates otherwise management intensive tasks for creating and maintaining the ever changing virtual network services.
• VAN technology addresses key scalability issues

 

Virtual Machine Relocation Enablement

The goal of the Relocation Enablers project is to relax some of the restrictions of workload mobility encountered using virtual machine (VM) live migration. While virtual machine live migration itself has become a commodity in most of today's virtualization environments, a current limitations in most (if not all) implementations is that live migration cannot be applied over large distances. When trying to extend live migration to large-distance setups, a new set of problems arrives, which includes:

• Live migration (especially memory transfer) is typically not designed for large-latency interconnects
• Network setup is typically limited to a single subnet
• Storage used by the VM must be shared across the source and target host

In 2007-2008, we addressed the issue of cross-subnet migration which was demonstrated in the CeBIT2009 exhibition (http://www-03.ibm.com/press/us/en/pressrelease/26824.wss).

In 2009, our main focus is to enable VM live migration without shared storage, by leveraging storage mirroring as well as additional technologies and optimization techniques.

We are also looking into the issues related to large latencies between the source and the destination of the migration.
The research is being conducted on both PowerVM and x86/KVM platforms.

 

Development of allocation algorithms for optimized placement of virtual machines

Cost efficient provisioning of virtual resources to meet Service Level Agreements (SLAs) is key to the operation of a Compute Cloud. Our solution can be roughly divided into two complementary components:

• Policy-Driven Probabilistic Business Service Management (BSM)-aligned Admission Control (AC) : As shown in the diagram, each time a new service is deployed in the Cloud, Admission Control is performed. The AC component is responsible for calculating the risk of SLA noncompliance and estimating the impact of this noncompliance on the business goals of the RESERVOIR site. Based on the business policy of the site, the service is then either accepted or rejected.
• Policy-Driven Placement Optimization : After a service passes Admission Control it is subjected to continuous placement optimization.  Policy-driven Placement Optimization continuously optimizes Virtual Machines (VM) placement striving to better satisfy the cloud operator management policies such as, load balancing or power consumption reduction.

We define new optimization problems that deal with affinity/antiaffinity constraints, minimal configuration constraints, locality constraints, administrative constraints, etc., pertaining to VM placement. Our policy-driven VM placement optimization engine is fully integrated with the open COIN-OR Services for Operations Research (COIN-OR OS) framework (http://www.coin-or.org/projects/OS.xml). A great advantage of using COIN-OR OS is the ability to cast our specialized problem instances into well known problems using the standard XML-based representation language, OS instance language (OSiL), and then interface through the COIN supplied adaptors to more than 20 commercial and free solvers.  Additionally we are also developing our own solvers,specifically geared to the VM optimization problem which also interface with COIN-OR. The results produced by the back-end solvers are transformed by COIN-OR OS into a standard XML-based representation, OS result language (OSrL). An additional advantage of integrating our framework with COIN-OR OS is that it allows submission of the optimization problem instances over the Internet using Web services. This allows seamless and flexible physical separation of the computationally intensive tasks from the problem and results preparation and parsing.

VM placement under constraints poses interesting theoretical and practical challenges.  We define novel optimization problems, which are reminiscent of Bi-criteria Multiple Knapsack Problems with assignment restrictions (BMKAR), bin-packing with conflicts and Generalized Assignment Problem with Conflicts (GAP). Although these problems have been extensively studied in the last 30 years, some aspects of BSM-aligned VM placement require new approaches.

Some important differences from previously studied problems include:

• Penalization for non-placement : in BMKAR, as in all classical Knapsack Problems, no-placement of an item results in 0 profit for that item. In the VM placement with SLA protection problem, non-placement of an item or a group of items may result in SLA violation and, thus, payment of penalty.
• Selection Constraints : selection constraints imply that only when a group of VEEs (items) collectively forming a service is placed, this meta-item yields profit. Partial placement may even lead to penalty, as the SLA of a service may be violated. Thus, partial placement should be prevented.
• Repeated solution: as the placement problem is solved continuously, it is important to minimize the cost of replacement. In particular, we need to minimize the cost of re-assignments of VMs to hosts as this entails VMs migrations.
• Placement conflicts between individual VMs and groups of VMs.