10:30 a.m.
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...
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
>