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.... 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