Although you posted the same patch twice, I chose this one to respond to... On 10/09/2015 01:17 AM, Nitesh_Konkar wrote: ^^ Unnecessary in commit message and different from the S-o-b below... Sometimes it's helpful to provide an example, in this case I assume your example is an attach-device --config using one XML file and address followed by an attach-device --live using a different XML file and different PCI address - is that right? Then your contention is if someone does a "detach-device --live --config" they should expect this to succeed using the same XML file? Which XML - the one they used for the "--live" or the one they used for "--config"? Obviously I think using the "--live" one for "--config" will fail and vice-versa. I think you need to follow the history of the Update & Detach API's - in particular, I think you'll find commit id '1e0534a7'. In there Michal notes that parsing twice is wrong. Although I suppose using 'vmdef' instead of 'vm->def' for the config when both live & config are being used may provide the results you expect (unless of course you're working on a transient domain in which case vmdef == vm->def). Anyway, consider that Detach (and Update as well btw) can work on either the --config or --live or both. If both then, then both XML's should match. If they don't, then I'm going to assume this patch was generated because of some failure scenario, but without the example I can only make assumptions. I'm not so sure this patch is valid based on the above (written after I looked at the code for a while and made comments below). I've kept my comments, but I think you need to convince me more of the need by providing examples. I don't think you can expect to attach using different XML and then expect one detach (or update) to work properly. You've already 'decided' that the config and live will be different, then you must manage them differently. Beyond that as the man page notes, if your XML description of the device isn't specific enough, you could match something you don't expect. Likewise, if you do have specific XML descriptions, then you shouldn't expect to match something different when trying to update both config and live at the same time. Personally, in that case, I'd assume it becomes hypervisor dependent and the 'live' XML is used to update the 'config' device (as long as there isn't a PCI address conflict...). John ?? Spurious change. Should be removed from patch. Note this setting of parse_flags only when update the config. I didn't dig into why this is different than the update path, but it may be important w/r/t your changes. Need to change alignment of remainder of arguments Also 'dev_copy' isn't really a copy is it? Why not name it 'dev_live' or just keep it as 'dev' instead? Could all be one statement - "if (!(dev_live = xxxx(arg, arg, arg, arg, arg)))" This essentially removes the changes from commit id '1e0534a77' Existing, but could be "if (!(vmdef = ...)))" More argument alignment issues. You'll also see that commit id '1e0534a77' used vm->def for both while you're changing to 'vmdef' here. Although in thinking about this - perhaps this is what should have been used originally for the config path. Still if at this point "vmdef == vm->def", then this parse is theoretically no different than above (although Michal's commit message seems to indicate differently and I didn't dig into the Parse to follow why...). Maybe this becomes : if (vmdef == vm->def) dev_config = virDomainDeviceDefCopy(dev_live,...) else dev_config = virDomainDeviceDefParse(xml, vmdef, ...) You could have combine into one statement, e.g.: if (vmdef == vm->def) { if (!(dev_config = virDomainDeviceDefCopy(dev_live,...) goto endjob; } else { if (!(dev_config = virDomainDeviceDefParse(xml, vmdef, ...))) goto endjob; } dev_config and dev_live