Re: [Libvir] [RFC] Life-cycle Management of the domain
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.