From fiuczy at linux.vnet.ibm.com Mon Dec 2 08:28:38 2013 From: fiuczy at linux.vnet.ibm.com (Boris Fiuczynski) Date: Mon, 02 Dec 2013 09:28:38 +0100 Subject: [Libvirt-cim] [PATCH 00/20] REWORK/PARIAL: Changes to solve unsupported tag issue In-Reply-To: <52949494.1040805@gmail.com> References: <1384475049-11435-1-git-send-email-jferlan@redhat.com> <528A2B58.5010907@linux.vnet.ibm.com> <528BDCF9.8010109@redhat.com> <528CB8A5.6090702@linux.vnet.ibm.com> <528D2537.3010408@redhat.com> <528D7AE1.3000202@linux.vnet.ibm.com> <528F83C5.2060108@linux.vnet.ibm.com> <52949494.1040805@gmail.com> Message-ID: <529C44B6.5060208@linux.vnet.ibm.com> John and Xu, in the last view days I have done some thinking about the idea from Xu to work with the unknown tags and properties. Starting off by looking at how one would get into the situation of losing additional tags and properties I ended up with actually only one feasible explanation: A libvirt-cim user wants to use a libvirt feature not implemented in libvirt-cim. With that in mind I revisited the new proposed pattern again: Before I was thinking that the errors caused by new (unknown) tags and properties are just kind of the reversal of losing the new (unknown) tags and properties. I now come to another conclusion: Now I think that the errors are far worse than I thought, because as long as libvirt-cim is reducing everything to the known management scope the libvirt-cim user has it in his control to create and manage a new error free and working libvirt domain. With the new proposed pattern that is no longer true since if errors are caused by new (unknown) tags and properties that are outside of the known management scope of libvirt-cim the users have NO LONGER the capability to fix these problems from within libvirt-cim! What would be the result? I would guess that bugs would be opened against libvirt-cim reporting that it creates erroneous libvirt domain definitions. I would really not like to see libvirt-cim fixes in support for unsupported libvirt features which are caused by the new pattern of how unknown tag and properties are maintained. If currently bugs are opened that libvirt-cim is following the pattern of reducing a domain definition to its known management scope the answer is very easy: The used libvirt feature that is removed from the domain definition is not supported by libvirt-cim and libvirt-cim only maintains what it is supporting in the domain definition. The question should actually be how the missing libvirt feature can be implemented in libvirt-cim. This unsurprisingly correlates exactly with the second paragraph above ("A libvirt-cim user wants to..."). In summary: I no longer agree to the idea of replacing the old pattern with the new proposed pattern of how to handle unknown tags and properties. Sorry that it took me a while to realize that. I hope that my above explanations can be followed of why I changed my mind. On 11/26/2013 01:31 PM, Xu Wang wrote: > > ? 2013/11/23 0:18, Boris Fiuczynski ??: >> On 11/21/2013 04:15 AM, Xu Wang wrote: >>> >>> ? 2013/11/21 5:10, John Ferlan ??: >>>> On 11/20/2013 08:27 AM, Boris Fiuczynski wrote: >>>>> John and Xu, >>>>> >>>>> On 11/19/2013 10:49 PM, John Ferlan wrote: >>>>>> On 11/18/2013 09:59 AM, Boris Fiuczynski wrote: >>>>>>> John and Xu Wang, >>>>>>> here are a few general observations from side: >>>>>> First off - I tend to find myself agreeing with Boris here. I >>>>>> think the >>>>>> concept is important and necessary; however, I'm not convinced the >>>>>> implementation goes far enough. >>>>>> >>>>>>> 1) I agree that it makes sense to preserve the unknown xml >>>>>>> "entities" >>>>>>> even so it can create complex scenarios and even new kinds of >>>>>>> errors if >>>>>>> unknown entities depend on known entities which get modified making >>>>>>> them >>>>>>> unusable for the unknown entities. This error would probably be the >>>>>>> reversal of what is currently the problem when unknown entities >>>>>>> simply >>>>>>> disappear. >>>>>> Is there a more concrete example of "new kinds of errors if unknown >>>>>> entities depend on known entities which get modified making them >>>>>> unusable for the unknown entities" that can be given? Just for >>>>>> clarity. >>>>>> I've read that line a few times and I'm still not sure :-) >>>>> OK, let's take a look at device type disk. >>>>> Since 1.0.2 the property sgio was added. Let's assume this is the >>>>> unknown entity. sgio is only valid for property device "lun". >>>>> If one now changes the property device to "disk" than the unknown >>>>> entity >>>>> sgio would cause an error when specified. >>>>> >>>> Ah - I see. Not only do you have to manage the properties you have to >>>> know how to use them as well and all their rules. I forgot about >>>> that. I >>>> came from HP/HPVM and yes, this brings back all sorts of memories... >>>> >>>> Seems like in this case, when/if the property was changed from "lun" to >>>> "disk" - code would have to search that 'others' list for the "sgio" >>>> property and know how to handle adjusting it. That'll get tricky... >> You cannot search in others for something you do not know about... >> unless you can code magic! :-) > If needed that's possible. We just coding just like...xpath. Before that > we should make sure if it's necessary. -- Mit freundlichen Gr??en/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina K?deritz Gesch?ftsf?hrung: Dirk Wittkopp Sitz der Gesellschaft: B?blingen Registergericht: Amtsgericht Stuttgart, HRB 243294 From gesaint at linux.vnet.ibm.com Tue Dec 3 02:05:31 2013 From: gesaint at linux.vnet.ibm.com (Xu Wang) Date: Tue, 03 Dec 2013 10:05:31 +0800 Subject: [Libvirt-cim] [PATCH 00/20] REWORK/PARIAL: Changes to solve unsupported tag issue In-Reply-To: <529C44B6.5060208@linux.vnet.ibm.com> References: <1384475049-11435-1-git-send-email-jferlan@redhat.com> <528A2B58.5010907@linux.vnet.ibm.com> <528BDCF9.8010109@redhat.com> <528CB8A5.6090702@linux.vnet.ibm.com> <528D2537.3010408@redhat.com> <528D7AE1.3000202@linux.vnet.ibm.com> <528F83C5.2060108@linux.vnet.ibm.com> <52949494.1040805@gmail.com> <529C44B6.5060208@linux.vnet.ibm.com> Message-ID: <529D3C6B.9030103@linux.vnet.ibm.com> Dear Boris and John, Firstly thank you very much for your suggestion. Every comment from you make me gain my knowledge on libvirt-cim. But I think I should explain what the goal we want to reach. The reason I got this mission is most of bugs reported recently is users lost some of tags during resource operation. Even more serious is the lost tag had nothing to do with the device they updated. For example, if one attribute in device changed, the "model" attribute in the lost after updated! Isn't it a serious bug? What should we do after a bug reported? One patch generated. And another bug, another patch...But our users may fall into reporting bugs like this, again and again. After thought about the whole process carefully I think we may lost my original intention. That is just adding some struture to keep some unsupported tags without missing during updating even OTHER devices. Hence, with regard to the device updating issue we ever focused on, an option could be offered to the code may use it instead of user. Such as and Boris mentioned. That situation is impossible occur now because we haven't added this type into libvirt-cim so it belongs to UNKNOWN_TYPE now. That option or some other hack code could be added into this patch (maybe made in the future). So my design is just designed a set of basic operations and use them intead of changed the old pattern. All xml reading and generating logic just like before. As we discuss more the design becomes more complex. So I think I should describe my new version design now, 1. Boris's data structure is so good that it looks very tiny and suitable. That's a good choice to keep data structure and unsupported tags now. 2. Basic operations based on macros is a good choice. 3. We shouldn't extend the function of data structure but just mark it with status UNMANAGED, MANAGED and DELETED (UPDATED is not necessary because all data just could be updated in the virt_device members now). 3. As to resource updating, we just could change the variables in the libvirt-cim API so some resource updating issue would not occur. 4. I am glad to be responsible for all works about it. At last, I sincerely hope get any suggestion from you to solve that issue (my customers and boss almost take me to shreds because that), even an absolutely new one :-) Thanks, Xu Wang ? 2013/12/2 16:28, Boris Fiuczynski ??: > John and Xu, > in the last view days I have done some thinking about the idea from Xu > to work with the unknown tags and properties. > > Starting off by looking at how one would get into the situation of > losing additional tags and properties I ended up with actually only > one feasible explanation: A libvirt-cim user wants to use a libvirt > feature not implemented in libvirt-cim. > > With that in mind I revisited the new proposed pattern again: > Before I was thinking that the errors caused by new (unknown) tags and > properties are just kind of the reversal of losing the new (unknown) > tags and properties. > I now come to another conclusion: Now I think that the errors are far > worse than I thought, because as long as libvirt-cim is reducing > everything to the known management scope the libvirt-cim user has it > in his control to create and manage a new error free and working > libvirt domain. > With the new proposed pattern that is no longer true since if errors > are caused by new (unknown) tags and properties that are outside of > the known management scope of libvirt-cim the users have NO LONGER the > capability to fix these problems from within libvirt-cim! > What would be the result? I would guess that bugs would be opened > against libvirt-cim reporting that it creates erroneous libvirt domain > definitions. > I would really not like to see libvirt-cim fixes in support for > unsupported libvirt features which are caused by the new pattern of > how unknown tag and properties are maintained. > If currently bugs are opened that libvirt-cim is following the pattern > of reducing a domain definition to its known management scope the > answer is very easy: The used libvirt feature that is removed from the > domain definition is not supported by libvirt-cim and libvirt-cim only > maintains what it is supporting in the domain definition. > The question should actually be how the missing libvirt feature can be > implemented in libvirt-cim. This unsurprisingly correlates exactly > with the second paragraph above ("A libvirt-cim user wants to..."). > > In summary: I no longer agree to the idea of replacing the old pattern > with the new proposed pattern of how to handle unknown tags and > properties. > > Sorry that it took me a while to realize that. I hope that my above > explanations can be followed of why I changed my mind. > > > On 11/26/2013 01:31 PM, Xu Wang wrote: >> >> ? 2013/11/23 0:18, Boris Fiuczynski ??: >>> On 11/21/2013 04:15 AM, Xu Wang wrote: >>>> >>>> ? 2013/11/21 5:10, John Ferlan ??: >>>>> On 11/20/2013 08:27 AM, Boris Fiuczynski wrote: >>>>>> John and Xu, >>>>>> >>>>>> On 11/19/2013 10:49 PM, John Ferlan wrote: >>>>>>> On 11/18/2013 09:59 AM, Boris Fiuczynski wrote: >>>>>>>> John and Xu Wang, >>>>>>>> here are a few general observations from side: >>>>>>> First off - I tend to find myself agreeing with Boris here. I >>>>>>> think the >>>>>>> concept is important and necessary; however, I'm not convinced the >>>>>>> implementation goes far enough. >>>>>>> >>>>>>>> 1) I agree that it makes sense to preserve the unknown xml >>>>>>>> "entities" >>>>>>>> even so it can create complex scenarios and even new kinds of >>>>>>>> errors if >>>>>>>> unknown entities depend on known entities which get modified >>>>>>>> making >>>>>>>> them >>>>>>>> unusable for the unknown entities. This error would probably be >>>>>>>> the >>>>>>>> reversal of what is currently the problem when unknown entities >>>>>>>> simply >>>>>>>> disappear. >>>>>>> Is there a more concrete example of "new kinds of errors if unknown >>>>>>> entities depend on known entities which get modified making them >>>>>>> unusable for the unknown entities" that can be given? Just for >>>>>>> clarity. >>>>>>> I've read that line a few times and I'm still not sure :-) >>>>>> OK, let's take a look at device type disk. >>>>>> Since 1.0.2 the property sgio was added. Let's assume this is the >>>>>> unknown entity. sgio is only valid for property device "lun". >>>>>> If one now changes the property device to "disk" than the unknown >>>>>> entity >>>>>> sgio would cause an error when specified. >>>>>> >>>>> Ah - I see. Not only do you have to manage the properties you >>>>> have to >>>>> know how to use them as well and all their rules. I forgot about >>>>> that. I >>>>> came from HP/HPVM and yes, this brings back all sorts of memories... >>>>> >>>>> Seems like in this case, when/if the property was changed from >>>>> "lun" to >>>>> "disk" - code would have to search that 'others' list for the "sgio" >>>>> property and know how to handle adjusting it. That'll get tricky... >>> You cannot search in others for something you do not know about... >>> unless you can code magic! :-) >> If needed that's possible. We just coding just like...xpath. Before that >> we should make sure if it's necessary. > > From fiuczy at linux.vnet.ibm.com Fri Dec 13 13:05:41 2013 From: fiuczy at linux.vnet.ibm.com (Boris Fiuczynski) Date: Fri, 13 Dec 2013 14:05:41 +0100 Subject: [Libvirt-cim] [PATCH 00/20] REWORK/PARIAL: Changes to solve unsupported tag issue In-Reply-To: <529D3C6B.9030103@linux.vnet.ibm.com> References: <1384475049-11435-1-git-send-email-jferlan@redhat.com> <528A2B58.5010907@linux.vnet.ibm.com> <528BDCF9.8010109@redhat.com> <528CB8A5.6090702@linux.vnet.ibm.com> <528D2537.3010408@redhat.com> <528D7AE1.3000202@linux.vnet.ibm.com> <528F83C5.2060108@linux.vnet.ibm.com> <52949494.1040805@gmail.com> <529C44B6.5060208@linux.vnet.ibm.com> <529D3C6B.9030103@linux.vnet.ibm.com> Message-ID: <52AB0625.4060906@linux.vnet.ibm.com> On 12/03/2013 03:05 AM, Xu Wang wrote: > Dear Boris and John, > Firstly thank you very much for your suggestion. Every comment from > you make me gain my knowledge on libvirt-cim. But I think I should > explain what the goal we want to reach. > The reason I got this mission is most of bugs reported recently is > users lost some of tags during resource operation. Even more serious is > the lost tag had nothing to do with the device they updated. For > example, if one attribute in device changed, the "model" > attribute in the lost after updated! Isn't it a serious bug? Actually this is not a bug but a behavior of libvirt-cim that it reduces a guest definition to the scope of its management domain. This is done so that the user can observe and set all the settings in the management domain of libvirt-cim and nothing is preventing him from storing this by libvirt-cim changed guest definition. To make my point: How did the model attribute get into the cpu tag? Not via libvirt-cim! Why did someone use other means to do this modification and than uses libvirt-cim again? Why not implement this libvirt feature so that is available in libvirt-cim? I think that the solution should be to implement the missing feature in libvirt-cim so that the model attribute and whatever else might be missing to support it can be observed and set with libvirt-cim. > What > should we do after a bug reported? One patch generated. And another bug, > another patch...But our users may fall into reporting bugs like this, > again and again. Isn't that business as usual? If libvirt-cim does not support a libvirt feature is that a bug or a feature request? I would say it is a feature request. But if one uses other means to set this libvirt feature in the guest definition and is using libvirt-cim again on this guest definition he should be made aware that libvirt-cim manages within its own management scope and settings will get lost that are outside of this management scope to maintain the manageability from within libvirt-cim. > After thought about the whole process carefully I think we may lost > my original intention. That is just adding some struture to keep some > unsupported tags without missing during updating even OTHER devices. > Hence, with regard to the device updating issue we ever focused on, an > option could be offered to the code may use it instead of user. Such as > and Boris mentioned. That situation is impossible occur now > because we haven't added this type into libvirt-cim so it belongs to > UNKNOWN_TYPE now. That option or some other hack code could be added > into this patch (maybe made in the future). Actually all we need to look at is the use of the method ModifyResourceSettings on KVM_VirtualSystemManagementService. Correct? Looking at how the new pattern behaves: The modified RASD will delete the others structure of internal data representation (meaning all unknown tags and attributes of the corresponding guest xml instance are deleted). You are correct that the example I gave is not a problem... with the way you handle modified instances by deleting all unknown elements and guest definitionerties. A few questions are coming to my mind: 1) Is it acceptable that e.g. the unsupported per device boot setting is eliminated by an update of e.g. a disk resource? Is that the next bug someone will open? 2) What happens if two or more device instances have dependencies on each other by settings that libvirt-cim does not handle but libvirt does? 3) If someone by other means chose to use per device boot elements in the guest definition and now wants to modify this guest definition setting the boot order with libvirt-cim it will no longer work since the OS boot element and the per-device boot elements are mutually exclusive and libvirt is enforcing this! It would leave the user stuck using libvirt-cim. > So my design is just designed a set of basic operations and use them > intead of changed the old pattern. All xml reading and generating logic > just like before. > > As we discuss more the design becomes more complex. So I think I > should describe my new version design now, > 1. Boris's data structure is so good that it looks very tiny and > suitable. That's a good choice to keep data structure and unsupported > tags now. > 2. Basic operations based on macros is a good choice. > 3. We shouldn't extend the function of data structure but just mark > it with status UNMANAGED, MANAGED and DELETED (UPDATED is not necessary > because all data just could be updated in the virt_device members now). > 3. As to resource updating, we just could change the variables in the > libvirt-cim API so some resource updating issue would not occur. > 4. I am glad to be responsible for all works about it. > > At last, I sincerely hope get any suggestion from you to solve that > issue (my customers and boss almost take me to shreds because that), > even an absolutely new one :-) > > Thanks, > Xu Wang > > > ? 2013/12/2 16:28, Boris Fiuczynski ??: >> John and Xu, >> in the last view days I have done some thinking about the idea from Xu >> to work with the unknown tags and guest definitionerties. >> >> Starting off by looking at how one would get into the situation of >> losing additional tags and guest definitionerties I ended up with actually only >> one feasible explanation: A libvirt-cim user wants to use a libvirt >> feature not implemented in libvirt-cim. >> >> With that in mind I revisited the new guest definitionosed pattern again: >> Before I was thinking that the errors caused by new (unknown) tags and >> guest definitionerties are just kind of the reversal of losing the new (unknown) >> tags and guest definitionerties. >> I now come to another conclusion: Now I think that the errors are far >> worse than I thought, because as long as libvirt-cim is reducing >> everything to the known management scope the libvirt-cim user has it >> in his control to create and manage a new error free and working >> libvirt domain. >> With the new guest definitionosed pattern that is no longer true since if errors >> are caused by new (unknown) tags and guest definitionerties that are outside of >> the known management scope of libvirt-cim the users have NO LONGER the >> capability to fix these problems from within libvirt-cim! >> What would be the result? I would guess that bugs would be opened >> against libvirt-cim reporting that it creates erroneous libvirt domain >> definitions. >> I would really not like to see libvirt-cim fixes in support for >> unsupported libvirt features which are caused by the new pattern of >> how unknown tag and guest definitionerties are maintained. >> If currently bugs are opened that libvirt-cim is following the pattern >> of reducing a domain definition to its known management scope the >> answer is very easy: The used libvirt feature that is removed from the >> domain definition is not supported by libvirt-cim and libvirt-cim only >> maintains what it is supporting in the domain definition. >> The question should actually be how the missing libvirt feature can be >> implemented in libvirt-cim. This unsurprisingly correlates exactly >> with the second paragraph above ("A libvirt-cim user wants to..."). >> >> In summary: I no longer agree to the idea of replacing the old pattern >> with the new guest definitionosed pattern of how to handle unknown tags and >> guest definitionerties. >> >> Sorry that it took me a while to realize that. I hope that my above >> explanations can be followed of why I changed my mind. >> >> >> On 11/26/2013 01:31 PM, Xu Wang wrote: >>> >>> ? 2013/11/23 0:18, Boris Fiuczynski ??: >>>> On 11/21/2013 04:15 AM, Xu Wang wrote: >>>>> >>>>> ? 2013/11/21 5:10, John Ferlan ??: >>>>>> On 11/20/2013 08:27 AM, Boris Fiuczynski wrote: >>>>>>> John and Xu, >>>>>>> >>>>>>> On 11/19/2013 10:49 PM, John Ferlan wrote: >>>>>>>> On 11/18/2013 09:59 AM, Boris Fiuczynski wrote: >>>>>>>>> John and Xu Wang, >>>>>>>>> here are a few general observations from side: >>>>>>>> First off - I tend to find myself agreeing with Boris here. I >>>>>>>> think the >>>>>>>> concept is important and necessary; however, I'm not convinced the >>>>>>>> implementation goes far enough. >>>>>>>> >>>>>>>>> 1) I agree that it makes sense to preserve the unknown xml >>>>>>>>> "entities" >>>>>>>>> even so it can create complex scenarios and even new kinds of >>>>>>>>> errors if >>>>>>>>> unknown entities depend on known entities which get modified >>>>>>>>> making >>>>>>>>> them >>>>>>>>> unusable for the unknown entities. This error would probably be >>>>>>>>> the >>>>>>>>> reversal of what is currently the problem when unknown entities >>>>>>>>> simply >>>>>>>>> disappear. >>>>>>>> Is there a more concrete example of "new kinds of errors if unknown >>>>>>>> entities depend on known entities which get modified making them >>>>>>>> unusable for the unknown entities" that can be given? Just for >>>>>>>> clarity. >>>>>>>> I've read that line a few times and I'm still not sure :-) >>>>>>> OK, let's take a look at device type disk. >>>>>>> Since 1.0.2 the guest definitionerty sgio was added. Let's assume this is the >>>>>>> unknown entity. sgio is only valid for guest definitionerty device "lun". >>>>>>> If one now changes the guest definitionerty device to "disk" than the unknown >>>>>>> entity >>>>>>> sgio would cause an error when specified. >>>>>>> >>>>>> Ah - I see. Not only do you have to manage the guest definitionerties you >>>>>> have to >>>>>> know how to use them as well and all their rules. I forgot about >>>>>> that. I >>>>>> came from HP/HPVM and yes, this brings back all sorts of memories... >>>>>> >>>>>> Seems like in this case, when/if the guest definitionerty was changed from >>>>>> "lun" to >>>>>> "disk" - code would have to search that 'others' list for the "sgio" >>>>>> guest definitionerty and know how to handle adjusting it. That'll get tricky... >>>> You cannot search in others for something you do not know about... >>>> unless you can code magic! :-) >>> If needed that's possible. We just coding just like...xpath. Before that >>> we should make sure if it's necessary. >> >> > -- Mit freundlichen Gr??en/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina K?deritz Gesch?ftsf?hrung: Dirk Wittkopp Sitz der Gesellschaft: B?blingen Registergericht: Amtsgericht Stuttgart, HRB 243294 From jferlan at redhat.com Fri Dec 20 17:59:09 2013 From: jferlan at redhat.com (John Ferlan) Date: Fri, 20 Dec 2013 12:59:09 -0500 Subject: [Libvirt-cim] [PATCH] PanicCheckABIStability: Need to check for existence Message-ID: <1387562349-20434-1-git-send-email-jferlan@redhat.com> Commit id '4313fead' added a call to virDomainPanicCheckABIStability() which did not check whether the panic device existed before making a call to virDomainDeviceInfoCheckABIStability() which ended up segfaulting: Thread 1 (Thread 0x7f5332837700 (LWP 10964)): (src=, dst=) at conf/domain_conf.c:13007 (dst=, src=) at conf/domain_conf.c:13712 (src=, dst=) at conf/domain_conf.c:14056 (domain=domain at entry=0x7f53000057c0, vm=vm at entry=0x7f53000036d0, defptr=defptr at entry=0x7f5332836978, snap=snap at entry=0x7f5332836970, update_current=update_current at entry=0x7f5332836962, flags=flags at entry=1) at conf/snapshot_conf.c:1230 (domain=0x7f53000057c0, xmlDesc=, flags=1) at qemu/qemu_driver.c:12719 (domain=domain at entry=0x7f53000057c0, xmlDesc=0x7f53000081d0 "\n snap2\n new-desc\n running\n \n snap1\n \n 1387487268\n def->dom $2 = {virtType = 2, id = -1, .. ... rng = 0x0, panic = 0x0, namespaceData = 0x0,... ... (gdb) print *def->dom $3 = {virtType = 2, id = -1, ... ... rng = 0x0, panic = 0x0, namespaceData = 0x0,... ... (gdb) Signed-off-by: John Ferlan --- NOTE: Optionally the call could be changed to: "if (src->panic && !virDomainPanicCheckABIStability(...)" I went with what I did following the RNGDefCheckABIStability. src/conf/domain_conf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 0079234..c86af9a 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -13709,6 +13709,9 @@ static bool virDomainPanicCheckABIStability(virDomainPanicDefPtr src, virDomainPanicDefPtr dst) { + if (!src && !dst) + return true; + return virDomainDeviceInfoCheckABIStability(&src->info, &dst->info); } -- 1.8.3.1 From jferlan at redhat.com Fri Dec 20 18:08:44 2013 From: jferlan at redhat.com (John Ferlan) Date: Fri, 20 Dec 2013 13:08:44 -0500 Subject: [Libvirt-cim] [PATCH] PanicCheckABIStability: Need to check for existence In-Reply-To: <1387562349-20434-1-git-send-email-jferlan@redhat.com> References: <1387562349-20434-1-git-send-email-jferlan@redhat.com> Message-ID: <52B487AC.8040109@redhat.com> Dang - disregard - cut-n-pasted the wrong line :-) John