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.