Linux is a registered trademark of Linus Torvalds.
libvirt-cim
Dan Smith <[email protected]>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
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