4:22 a.m.
δΊ 2013-3-5 7:49, John Ferlan ει:
On 01/16/2013 12:46 AM, Wenchao Xia wrote:
> Hi, Danial
> Happy new year!
> Could u have a look v3 serial of libcmpituil patches? It is simple
> and need no test case, hope it can be merged if no problem found.
>
First off - let me introduce myself... I'm (relatively) new to Red Hat
having joined in Dec 2012 from HP where I worked on Virtualization
products at HP. Primarily I was responsible for the API/CLI space of
the HPVM product. I also was part of a project that created what HP
calls VirtProvider which was a DSP2013 CIM Provider. Since I knew how
to spell CIM and had some history, I was asked to take a look at
failures that Yanbing Du posted questions about back in October:
https://www.redhat.com/archives/libvirt-cim/2012-October/msg00000.html
Sorry in advance for the length of the rest of this...
It is very nice to hear new people comes to libvirt-cim, although
the developement slows down but user are still there, it need to be
taken care of. Welcome the libvirt-cim project. :).
While this won't be a full time endeavour, putting some cycles
on
libvirt-cim has been added to my list of things to do. I still need a
bit of help - I'm not quite sure of the "proper procedure" to use when
testing a local libvirt-cim build. The only way I was able to make
things work was remove the libvirt-cim package (rpm -e) and then
reinstall (yum localinstall from build rpm in a 'make rpm'). I tried the
install/postinstall process with stopping/starting tog-pegasus, but
couldn't quite get things to work.
Using "rpm -e [old rpm]" and "rpm -ivh [new rpm]" should be
enough to
test new libvirt-cim. I am not sure how you install/postinstall it, in
common case of test, these steps are not needed.
Getting "up to speed" was a bit of a challenge as the
libvirt CIM web
pages seem to be a bit out of date and perhaps assume a few things along
the way. I've taken some notes, but was eventually able to get things
installed. I'm still working through some of the "kinks".
Setting up a CIMserver with tog_pegasus was not something I did at HP,
so it was a bit of an adventure. Eventually I worked my way through
things with lots of trial and error. Following the README instructions I
ran into two issues during the post installation phase, which I'm
somewhat curious if long time users would also hit (not that many are
active any more):
I haven't installed it either, always used the rpm. Can't you use
"rpm -ivh" to install/replace tog_pegasus?
#1: The commit id '22022870d' to Makefile.am which
essentially added
"$(top_srcdir)/" in front of the "schema" directory path caused the
'make postinstall' to fail (at least on my fedora18 system). The
problem is that the path ends up as ".//usr/..." the "./" being the
problem with respect to the ability to "find" the files. Stripping that
off allows finding files to be found again. The fix is to modify the
various "$(subst schema" and replace them with "$(subst
$(top_srcdir)/schema" - this allowed me to continue.
#2: After that was solved, as things were scrolling past I noted that
there was some sort of issue with "schema/SwitchService.registration".
In looking at the file, it seems the blank line at the end of the file
caused some sort of "issue", so I removed it and the registration was
happier.
After those changes I was able to run through the 'cimtest' using the
most recent libvirt (what is looking to be 1.0.3). I didn't see all the
same errors, but did trip across a few.
Figuring that perhaps some of those were fixed by patches that I knew
were out there, I went back to start looking, applying, and running
cimtest again for tests that failed for me.
I downloaded and applied the Dec 2012 patches for libvirt-cim (v3 01 ->
11 and v4 DevicePool) and libcmpiutil (v3 1&2) as well as the Nov 2012
patch submitted by Jirka. I believe that gets me "up to date". Although
it was a bit confusing as what I should have done for the v4 patches on
12/25/12 was to "replace" the 12/18/12 patches 6 and 10. Luckily it was
a quick retrace of my steps.
Sorry for the trouble of different versions, glad you replaced the
correct patches. :)
Unfortunately it didn't seem I was "using" the changes
when I ran
"make", "make preinstall", "make install", & "make
postinstall". So, I
figured I'd try to make a new distribution to see if that would work. I
got a bit further; however, the 'make distcheck' failed for me much in
the same way the 'make postinstall' did above. So I adjusted commit id
'9f5e204f' to rather than "$(subst ./schema," use "$(subst
$(top_srcdir)/schema" which resolve the issue I was running into. Once I
did the 'rpm -e libvirt-cim', I was able to install the rpm I build and
test the changes.
I haven't try it on Fedora, but usually on RH I use "make rpm"
from
source code to build a rpm, then replace the rpm and test. "make
install" seems have problem before and I am not sure if it works
now, so please use rpm replacing if it work on Fedora.
The (partial) good news is between the fixes provided in the
December
patches and some of my own I can get a majority of cimtest to succeed.
I've had to make other adjustments, but I figured that'd be par for the
course anyway.
So some comments about your changes. Now that I have a little more
experience I'll look at the other changes more in depth, but these two
popped out due to me running into "issues" with them.
Patch 01/11:
* The change for 'bridge' networks and not allowing scripts is only for
qemu domains. Apparently Xen domains would still support the script.
So while your change does effectively remove it for Qemu, doing so for
Xen could be a regression (I have no way to test).
See the following for my logic:
http://www.redhat.com/archives/libvir-list/2012-January/msg00240.html
Before I had applied your patches I had made a similar change except
that I passed along the dominfo->type to the bridge_net_to_xml()
function and then test in there whether or not the "script" should be
added based on type of DOMAIN_XENPV or DOMAIN_XENFV.
This seems a safer way,
since we both lack a ENV to test for Xen, If
you wish you could form a patch for it, replace mine in the serial.
Patch 09/11
* This change caused the 'make distcheck" to fail. The
'wait_for_event()' routine has a "ret" variable that is unused.
My bad, this check is not done before.
Some changes I've made to 'cimtest' in order to get things to work
* The test makes use of setting a MAC in quite a few places,
unfortunately the MAC chosen for most (99:aa:bb:cc:ee:ff) is a Multicast
Address. We know this because the low bit of the first byte (e.g. "99")
is set (in hex 0x10011001). Changing those references to "88" works.
* ComputerSystemIndication and RASDIndications fail for me. After a
long pause, I got a Python stack trace where it looks like it's trying
to print testsuite results. What that turns out to be is the
'os_status' being passed along is the errno value for 'ETIMEDOUT' (eg.
110). Using 110 to index into the rc[] record in Reporter.py causes a
KeyError exception. I "fixed" that by checking if os_status was outside
of the valid range and if so, set it to FAIL, but log that I did so.
* Profile/04_verify_libvirt_cim_slp_profiles.py has a bug. It only
checks for "slp" when it should check "slp=true".
Yes, this test case seems need slp server configured correctly and
it never passed on my machine, but user of libvirt-cim with slp=true
works fine, suggest ignore this case.
* Looking for the NFS Server at /sbin/init.d/nfs doesn't work
any more
with the usage of systemd in order to start/stop daemons. I adjusted the
code accordingly
* The ResourcePoolConfigurationService tests 08, 09, & 15 try to create
a pool pointing at /var/lib/libvirt/images which causes a failure
because cimtest-diskpool already exists and uses it. Not sure if this
is a new check or not (remember I haven't been here that long).
Fails also
in mine machine, seems a error in cimtest code.
My current results have 173 of 192 tests passing. There are 4 FAIL, 4
XFAIL, and 11 SKIP (mostly migration which I haven't figured out yet).
2 of the SKIP's are because I already had a domains and storage pools
defined on my system.
This is really nice, I have 8 FAIL. Before I ignored them because
in error message it shows as testcase issue not libvirt-cim's problem.
If you can form patches for cimtest and verify it on RH, pls post
them on maillist, they will be very helpful, fixing the problems
remains in cimtest for a long time.
I am working on qemu dev now but will still pay time for libvirt-cim
for bug/patches. If you like you can post your patches and let me
review. We really need new libvirt-cim 0.6.2 release fast to eliminate
bug reports for old 0.6.1.
John
_______________________________________________
Libvirt-cim mailing list
Libvirt-cim(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-cim
--
Best Regards
Wenchao Xia