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

Saori Fukuta fukuta.saori at jp.fujitsu.com
Thu May 10 03:06:51 UTC 2007


Hi Daniel,

Thank you for your proposal ! I considered the way with it.

On Fri, 27 Apr 2007 10:35:15 -0400 Daniel Veillard wrote:
>   So I have a problem with this, and I suggest to isolate configuration
> file APIs, which in practice would mean client code a bit more verbose
> but keeping the API simpler. 
>   We have a long week-end ahead, I will try to get back with more complete
> proposal, but I could see a set of API like:
> 
> proposal 1:
> 
>     - create a config from a string (or file)
>       we could autodetect the kind of configs here and automatically support
>       XML, sexpr, old Xen config files, and also VMWare-like ones
>     - create a config from a running domain (like virDomainGetXMLDesc does)
>     - modify values from a config
>     - get a value from a config
>     - save a config (as libvirt XML) in a string or file
> 
> The main drawback of proposal 1 is that it increase the API, but would make
> clear what kind of objects are been managed, i would also allow more specific
> configuration only option in the future.

I think that the proposal is good to keep the API simple, though, the number
of API increases. 

Here is an example of the interface.

We could provide new API (like virDomainSetMemoryConfig), and use only it for
not running domain.

running domain     --> change the allocation using current API(virDomainSetMemory)
not running domain --> change the configuration using new API(virDomainSetMemoryConfig)

    # virsh setmem foo 200
    --- at virsh command
    1. if the domain is running
       -> virDomainSetMemory (current API)
    2. if the domain is not running
       -> virDomainSetMemoryConfig (new API)
    --- at new API for Xen
    1. get a string using expr_get and create a config form a string
    2. modify the value, in this case, modify "memory" to 200
    3. save a config using define

Or to keep the increase to the minimum, we could provide one new command.
    # virsh mod-config foo -memory 200
    --- at virsh command
    1. if the domain is running
       -> return error
    2. call new API virDomainModifyConfig
    --- at new API for Xen
    2. get a string using expr_get and create a config form a string
    3. modify the value, in this case, modify "memory" to 200
    4. save a config using define

and other changing allocation commands are alike described above.

I think this is the better way than I suggested before.
How does this look ?

Thanks,
Saori Fukuta




More information about the libvir-list mailing list