Linux is a registered trademark of Linus Torvalds.

libvirt-cim

Dan Smith <danms@us.ibm.com>IBM Linux Technology Center

Open Virtualization Team

January 15, 2009

Outline● History of Open Virtualization CIM instrumentation● Goal for libvirt-cim● DMTF Model Overview● Implementation● Testing● Status

– Model Support– DMTF Profiles

● Future Plans● Work items up for grabs● Pointers

History of Open Virt CIM● IBM developed proprietary xen-cmpi in 2005

– 70 KLOC– Supported Xen only, using system(“xm foo”);– Lots of duplicated code and quality issues– Used the conventional “template” method– No “dynamic” operations (ballooning, etc)– Unaware of distro-created domains

● IBM contributed xen-cmpi as os-xen-cmpi in 2006– Novell (et al) reduced to 40 KLOC– Ported to XenAPI– Became even more Xen-specific– XenAPI is now fragmented and dead

● IBM started fresh with libvirt-cim in mid-2007

Goal for libvirt-cim● Support Xen, KVM, etc.● Leverage libvirt● Start with a fresh codebase and steer clear of

“conventional” template-written providers● Bring the development closer to the technology

owners for better integration● Play nice with domains created with existing

distro tools● Push into distros for consistent out-of-the-box

management● Support the rest of the DMTF model with

resource pools, dynamic device actions, etc.

DMTF Model Overview● Important objects:

– CIM_ComputerSystem– CIM_LogicalDevice– CIM_ResourceAllocationSettingData– CIM_VirtualSystemSettingData– CIM_VirtualSystemManagementService

● Important associations:– CIM_SystemDevice– CIM_SettingsDefineState– CIM_HostedService

● Other modeled components– Resource pools, additional services, domain

lifecycle, asynchronous notifications

DMTF Model Overview

Implementation● Pulled out a lot of repetitive CMPI actions into

libcmpiutil● Designed a standardized framework to handle

association and method providers● Designed each provider to be able to handle

Xen_, KVM_, Foo_ variants of each class with the same code path

● Some providers handle multiple classes (i.e. Network, Disk, Processor, Memory)

● At feature parity with xen-cmpi and os-xen-cmpi, we were <10 KLOC

Testing● cimtest – uses PyWBEM to drive providers● Framework could be used by other CIM projects● Currently 140 libvirt-cim tests – most

supporting Xen, KVM, and XenFV● Some tests enabled for Containers● Weekly test runs are sent to external list● Will soon have automated fully-automated runs

– Will checkout the providers nightly and send a report to the list

● Test run results and test failure status: http://wiki.libvirt.org/page/Cimtest

Status● Supports the majority of the DMTF SVPC model● Resource changes are dynamic (where

supported by the platform)● Uses the same mechanism as distro tools, so

both tool sets are aware of each other● Exceeds functionality of os-cmpi-xen providers

in the areas of migration, resource pools, etc.● Integrated into Fedora 9 and 10, RHEL5.3● Supports Xen, KVM, Linux Containers

Status – Model Support● Domain lifecycle

– Create, Destroy, Power On/Off– Save, Restore– Pause, Unpause– Migrate

● Virtual Resources– Disk/CD-ROM, Network, Memory, Graphics, Input– Processor

● With scheduling parameter controls● CPU shares, etc

● Asynchronous Indications– Domain configuration and state changes– Domain migration progress

Status – Model Support● Resource Pools (read only)

– Storage, virtual networks as network pools● Allocation Capabilities

– Template configuration elements– Min, Max, Increment, and Default (suggested)

configurations for each resource type

DMTF Profiles● Virtual System 1.0.0a● System Virtualization 1.0.0● Generic Device Resource Virtualization 1.0.0

– Disk, Network, Processor● Memory Resource Virtualization 1.0.0● Virtual System Migration 0.8.1● KVM Redirection 1.0.0● Allocation Capabilities 1.0.0● Resource Allocation 1.0.0

Future Plans● Support resource pool manipulation

– Will require coordination between storage service providers

– Provide mechanism to make libvirt aware of new resources as pool objects

● Expand support for other bits of the model– Multiple domain configurations (active, next)– Additional async indications

● Further integrate with base instrumentation (SBLIM, SMASH, etc)

Future Plans● Text console modeling● Update to latest DMTF schema

– Currently on 2.16 Experimental– 2.20 has been released

● Investigate KVM migration changes in libvirt API

Work items up for grabs● Things other groups could work on:

– Multiple processor and memory pools for resource management

– Definition of implementation-specific error codes and updating the providers to use them

– Additional asynchronous events– Support for additional devices (PCI, USB,

pvclock, etc)– Additional platforms?

Pointers● CIM: www.dmtf.org/standards/cim/● DMTF Profiles: www.dmtf.org/standards/profiles/● Libvirt: www.libvirt.org● Libvirt-CIM: www.libvirt.org/CIM

– Mailing list: www.redhat.com/mailman/listinfo/libvirt-cim– Source: www.libvirt.org/hg/libvirt-cim