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