Hi, Daniel and Dan Thank you for various comments. Exactly. Libvirt is just a library and it is better to not keep states there. The management states would be kept at end point server(eg. XenD, or QEMUD) or an application. So I would like to think again. On Thu, 19 Apr 2007 16:18:28 +0100 "Daniel P. Berrange" wrote: > If we ignore case B, I think we still have lots of interesting > combos to think about: > > 1. Static - change persistent config > 2. Dynamic - change live VM config > 3. Static and Dynamic - change persistent config, and live VM > 4. Static or Dynamic - if domain is inactive, change persistent > config, if it is active, change live VM > > With the virDomainSetMem/MaxMem/VCPUs we in fact implement 3/4 depending > on the backend, because until we switch to XenAPI, that's basically the > only option that is actually possible when talking to XenD. > > So if you want to only change the persistent config, then you need to > redefine the entire domain XML file, using virDomainDefineXML() pasing > in the updated XML doc for the new inactive config. This lets you > indirectly do option 1. Yes, that's a good idea. But I'm not sure how to change the presistent config without that libvirt maintain persiste state. Could you tell me your thinking ? Who has the XML file ? > If we did the API change described above, we could easily provide the > --dynamic or --static flags, eg > > virsh setmem foo 500 -> VIR_DOMAIN_SCOPE_CURRENT > virsh --static setmem foo 500 -> VIR_DOMAIN_SCOPE_STATIC > virsh --dynamic setmem foo 500 -> VIR_DOMAIN_SCOPE_DYNAMIC > virsh --static --dynamic setmem foo 500 -> VIR_DOMAIN_SCOPE_BOTH That's a nice way. > There's some interesting questions / problems around error handling when > ysing the 'BOTH' option - if changing static config succeeds, but > changing dynamic config fails, should the API completely fail or should > it succeed ? If it suceeds is there any way/need to inform caller that it > was unable to change the live config ? Well, in that case, I think we should tell caller a warning. And we should implement the command to confirm the next start information. > It may not even be possible to implement some of these different SCOPE > flags depending on the backend being used. Could make it tricky for > apps using these APIs, but maybe that's OK as long as we get the error > reporting right ? Yeah, I appreciate your suggestion. Thanks, Saori.