> Even better would be to require libvirt 0.9.13 and use the proposed > virConnectListAllDomains() API to get all domains in one shot, as > the approach you have used is inherently racy due to the flaws in > the older APIs (which reminds me, Peter is still working on posting > a v2 of that series). That would be great! In my case, I'm running Centos 6.2, and it uses libvirt 0.9.4 at the moment. > > - This will be a breaking change for anyone who assumes that the > > old behavior is still in place (i.e., that the guest table > > only includes non-shutdown domains). However, it might not be > > *that* bad because the domain rows already included a 'state' > > that one could already filter on. > > I'm not familiar enough with libvirt-snmp to say whether this is > important, or to even know how the current bindings work. Is this > something where you might be better served by instead adding new > libvirt-snmp bindings to the existing virConnectListDefinedDomains > and upcoming virConnectListAllDomains, instead of changing the > behavior of the existing query method which is currently bound to > virConnectListDomains? I don't quite understand your question. To clarify: the issue I am raising here is that anyone who issues an "snmpwalk" command will now get (potentially) more domain entries in the result than they expected. Even if those entries have the proper state (i.e., not running), if they wrote code under the assumption that all of the guest domains in the SNMP result would be running (due to the behavior prior to my patch), they'd end up with a bug. This is an application behavior change in the "libvirtMib_subagent" program (which is the chief result of building libvirt-snmp). Does that clarify? Thanks! -- Jonathan Daugherty Software Engineer Galois, Inc. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list