[Libvir] [RFC] Life-cycle Management of the domain

[Saori Fukuta]

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.