[Libvirt-cim] [PATCH 0/6] Add Virtual Controller Device

[John Ferlan]

On 03/21/2014 07:57 AM, Boris Fiuczynski wrote:
> On 03/19/2014 03:49 AM, John Ferlan wrote:
>> This is rework of the Controller patch series submitted by Xu Wang. I have
>> built upon the constructs put in place by Xu with respect to reading and
>> writing the XML, but for the remainder of the code I changed where the
>> virtual controller lives.
>>
>> Xu's patches made a Controller RASD which had some issues regarding
>> associations with other devices and pools.
>>
>> Rather than go with a RASD model, I have chosen to make a KVM_Controller
>> virtual device to mimic a CIM_Controller device. This solution keeps things
> In doing so you broke the DMTF Virtual System Profile!
> http://www.dmtf.org/sites/default/files/standards/documents/DSP1057_1.0.0_0.pdf
> Take a look at 7.3.1 which defines a Virtual System Configuration and a 
> Virtual System Representation. It states the class concepts.
> You need to use RASDs.
> 

Hmm... Way too many standards for me to know :-). Also, to say the least
the docs are written for someone that lives/breaths CIM (as far as I'm
concerned at least).

I see a box for "LogicalDevice" which is what CIM_Controller extends -
so it seems the reality is in addition to the CIM_Controller there needs
to be a KVM_ControllerResourceAllocationSettingData, right?

I see for other KVM_*RASD types there is a related KVM_*LogicalDevice,
so it's "more or less" a matter of extending what I already have, I think.

For now the pressure is off though - the issue won't be fixed/ready for
the RHEL7.0 release, so at the earliest it'll be 7.1.  There's *way too
much* code to backport sanely to including in a 7.0.z stream - right now
there's about 30 or so patches - basically anything that's been added
since 0.6.3 was created (and inserted into RHEL7.0).  For me that's
mostly a process issue.

Furthermore, the addition of a keyboard input device in libvirt 1.2.2
has complicated things, especially the cimtest results, see:

http://www.redhat.com/archives/libvir-list/2014-February/msg01058.html

I'm off trying to figure out the best way to add/represent this. The
libvirt code considers it an input device and on the "devices/input" XML
tree.  Thus it's parsed by the device_parsing code.  Of course cimtest
blows up because 'keyboard' doesn't match 'mouse' or 'tablet' and all
the associations and links off in the weeds.

There is a CIM_Keyboard device; however, given the above comments - it
seems that may not be the path to take... If I make a KVM_Keyboard
device and include found keyboards in the "KVM_InputRASD" there's issues
because quite a few of the cimtest tests assume a 1-to-1 relationship
between a classname and the RASD. They are not very happy to find two
KVM_InputRASD's that are different. Building references of the RASD by
the test uses the classname as a key - thus whichever is last (eg,
keyboard) gets the representation.

Anyway different problem, but still I think a similar need for
representation - so it'll be good to understand the requirements for how
a controller needs to be or can be represented.

>> at a lower level and has been able to pass the cimtest as well as the
>> update a defined domain with a changed value test. This second test is
>> what fails for RHEL7.
>>
>> As it turns out, it seems as long as a 'pci' device with model 'pci-root'
>> is created, then things seem to work. The code relies on the previous patch
>> code Xu created to read/write the XML file with some adjustments.
>>
>> Perhaps the only controversial patch (for me at least) is 6/6. I figured
>> that after we've read everything and just before we go to create or update
>> the guest that we need to make sure that at least the 'pci' device with
>> model 'pci-root' exists.  This is similar to the add_default_devs() code,
> Actually libvirt-cim should not be creating default devices but let 
> libvirt do that. Reimplementing libvirt's default behavior would a 
> overestimation of libvirt-cim's own capabilities and in the long run 
> cause extra effort in maintaining default consistency.
> 

Right - so I wasn't sure "how" to handle the issue if someone didn't
configure/add a controller at domain/guest creation time.  Other devices
see to use the add_default_devs() mechanism, but honestly I really don't
understand it that well.

John
>> except that it's run after all that code prior to any add or update of
>> the guest just before the "system_to_xml()" call is made.  I figure this
>> is the last gasp to ensure that at least the 'pci' device is there which
>> seems to be used by a number of "silently added" libvirt devices.
>>
>> John Ferlan (4):
>>    Add virtual controller object defs
>>    Change static API to global API
>>    Controller Device Details
>>    VSMS: Determine if default controller exists for KVM
>>
>> Xu Wang (2):
>>    Add virtual controller device types
>>    Parse/Store controller XML tags
>>
>>   Makefile.am                               |   2 +
>>   libvirt-cim.spec.in                       |   2 +
>>   libxkutil/device_parsing.c                | 119 +++++++++++++++++++++++++++-
>>   libxkutil/device_parsing.h                |  15 ++++
>>   libxkutil/xmlgen.c                        |  72 +++++++++++++++++
>>   schema/Controller.mof                     |  47 +++++++++++
>>   schema/Controller.registration            |  19 +++++
>>   src/Virt_Device.c                         |  84 ++++++++++++++++++++
>>   src/Virt_RASD.c                           |  21 +++--
>>   src/Virt_RASD.h                           |   4 +
>>   src/Virt_VirtualSystemManagementService.c | 106 ++++++++++++++++++++++++-
>>   src/svpc_types.h                          | 127 ++++++++++++++++++++++++++++++
>>   12 files changed, 602 insertions(+), 16 deletions(-)
>>   create mode 100644 schema/Controller.mof
>>   create mode 100644 schema/Controller.registration
>>
> 
>