[Libvir] [RFC] Life-cycle Management of the domain
Hi all, I've been thinking about a way to change the hardware allocation on the Life-cycle. And I have some idea. Can I hear your comments about this? 1. Necessity of function These are conceivable cases of changing hardware allocation. CASE A: Dynamic change change the allocation dynamically -> change the hardware allocation for now, and next time, start by the allocation before it changes. (example of use) At night, change the hardware allocation. Next morning rebooting, return it. CASE B: Static change change the allocation statically -> do not change the hardware allocation for now, but set the allocation for starting next. (example of use) Next time, want to start by the value that set before. CASE C: Permanent change change the allocation permanently -> change the hardware allocation, and start next time with the same setting. (example of use) want to start by same value permanently. The current situation of virsh command with Xen. CASE A / CASE B / CASE C virsh setmem x x o virsh setmaxmem x x o virsh setvcpus o x x virsh vcpupin o x x And I find that the value on Xenstore is used for starting the domain next time. 2. Change of command We need to add 3 options to the virsh command of changing allocation for CASE A, B, and C. So I propose the following options. option name --dynamic ... dynamic change option (default) for CASE A --static ... static change option for CASE B --perm ... permanent change option for CASE C If no option is specified, the Default option("--dynamic") will be chosen. (example) Example of changing the memory allocation 256MB to 512MB. # virsh dominfo Domain-A | grep "Used memory" Used memory: 256000 kB CASE A: Dynamic change # virsh setmem Domain-A 512000 or # virsh setmem Domain-A 512000 --dynamic # virsh dominfo Domain-A | grep "Used memory" Used memory: 512000 kB CASE B: Static change # virsh setmem Domain-A 512000 --static # virsh dominfo Domain-A | grep "Used memory" Used memory: 256000 kB CASE C: Permanent change # virsh setmem Domain-A 512000 --perm # virsh dominfo Domain-A | grep "Used memory" Used memory: 512000 kB 3. Summary of the ways Xen does not provide these cases. So I propose that we start the domain by a file for libvirt. 3.1 When starting the domain first time, copy a file from config.sxp(/etc/xen config file) to virt.sxp(libvirt). (image) +--- Xend ---+ +-- libvirt --+ +--------+ l config.sxp -------> virt.sxp l +--------+ lDomain-Al +------------+ copy +-------------+ lDomain-Al lmem=256 l lmem=256 l +--------+ ----------------------------------> +--------+ "virsh start Domain-A" 3.2 When starting the domain, if they have virt.sxp(libvirt) define that file. (image) Step.1 value of the domain before start. +--- Xend --------------------+ l +-Xenstore-+ +-config.sxp-+ l before l l mem=256 l l mem=256 l l +--------+ l +----------+ +------------+ l lDomain-Al +-----------------------------+ lmem=256 l +--------+ ---------------------------------> continue Step.2 Step.2 define the value of virt.sxp. +--- Xend ---------------------+ l +-Xenstore-+ +-config.sxp-+ l +----> mem=512 l -> mem=512 l l define l l +----------+ +------------+ l l +------------------------------+ l +--- l --------+ l +- l --------+ before l l mem=512 l l +--------+ l +-virt.sxp-+ l lDomain-Al +--- libvirt --+ lmem=256 l +--------+ ---------------------------------> continue Step.3 Step.3 start the domain and copy a file from config.sxp to virt.sxp. +--- Xend ---------------------+ l +-Xenstore-+ +-config.sxp-+ l l l mem=512 l l mem=512 l l l +--- l ----+ +----- l ----+ l +----- l ------------- l ------+ l l +--- libvirt --+ l l copy l +-virt.sxp-+ l l +-------------> mem=256 l l before l l +----------+ l +--------+ l start +--------+ +--------------+ lDomain-Al +------------>lDomain-Al lmem=256 l lmem=512 l +--------+ -------------------> +--------+ "virsh start Domain-A" 3.3 When changing the allocation statically or permanently, write the change into virt.sxp. (When changing the allocation dynamically, do nothing) CASE A: Dynamic change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=512 l l mem=512 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=256 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=512 l ll lmem=256 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=Y, mem=Y mem=X(no change) mem X to Y dynamically 3.stop the domain mem=Y, mem=Y mem=X 4.start the domain <------- <-----------define value mem=X, mem=X --->mem=X(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ CASE B: Static change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=256 l l mem=256 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=512 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=256 l ll lmem=512 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000 --static" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=X, mem=Y mem=Y(change to Y) mem X to Y statically 3.stop the domain mem=X, mem=X mem=Y 4.start the domain <------- <-----------define value mem=Y, mem=Y --->mem=Y(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ CASE C: Permanent change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=512 l l mem=512 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=512 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=512 l ll lmem=512 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000 --perm" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=Y, mem=Y mem=Y(change to Y) mem X to Y permanently 3.stop the domain mem=Y, mem=Y mem=Y 4.start the domain <------- <-----------define value mem=Y, mem=Y --->mem=Y(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ Thanks, Saori Fukuta
Hi, What the following things boil down to is that I hold file that formed in SXP for Life-cycle Management. What do you think of my idea? Thanks Saori Fukuta On Fri, 13 Apr 2007 16:26:37 +0900 Saori Fukuta wrote:
Hi all,
I've been thinking about a way to change the hardware allocation on the Life-cycle. And I have some idea. Can I hear your comments about this?
1. Necessity of function These are conceivable cases of changing hardware allocation.
CASE A: Dynamic change change the allocation dynamically -> change the hardware allocation for now, and next time, start by the allocation before it changes. (example of use) At night, change the hardware allocation. Next morning rebooting, return it.
CASE B: Static change change the allocation statically -> do not change the hardware allocation for now, but set the allocation for starting next. (example of use) Next time, want to start by the value that set before.
CASE C: Permanent change change the allocation permanently -> change the hardware allocation, and start next time with the same setting. (example of use) want to start by same value permanently.
The current situation of virsh command with Xen. CASE A / CASE B / CASE C virsh setmem x x o virsh setmaxmem x x o virsh setvcpus o x x virsh vcpupin o x x
And I find that the value on Xenstore is used for starting the domain next time.
2. Change of command We need to add 3 options to the virsh command of changing allocation for CASE A, B, and C. So I propose the following options.
option name --dynamic ... dynamic change option (default) for CASE A --static ... static change option for CASE B --perm ... permanent change option for CASE C
If no option is specified, the Default option("--dynamic") will be chosen.
(example) Example of changing the memory allocation 256MB to 512MB. # virsh dominfo Domain-A | grep "Used memory" Used memory: 256000 kB
CASE A: Dynamic change # virsh setmem Domain-A 512000 or # virsh setmem Domain-A 512000 --dynamic
# virsh dominfo Domain-A | grep "Used memory" Used memory: 512000 kB
CASE B: Static change # virsh setmem Domain-A 512000 --static
# virsh dominfo Domain-A | grep "Used memory" Used memory: 256000 kB
CASE C: Permanent change # virsh setmem Domain-A 512000 --perm
# virsh dominfo Domain-A | grep "Used memory" Used memory: 512000 kB
3. Summary of the ways Xen does not provide these cases. So I propose that we start the domain by a file for libvirt.
3.1 When starting the domain first time, copy a file from config.sxp(/etc/xen config file) to virt.sxp(libvirt).
(image) +--- Xend ---+ +-- libvirt --+ +--------+ l config.sxp -------> virt.sxp l +--------+ lDomain-Al +------------+ copy +-------------+ lDomain-Al lmem=256 l lmem=256 l +--------+ ----------------------------------> +--------+ "virsh start Domain-A"
3.2 When starting the domain, if they have virt.sxp(libvirt) define that file.
(image) Step.1 value of the domain before start.
+--- Xend --------------------+ l +-Xenstore-+ +-config.sxp-+ l before l l mem=256 l l mem=256 l l +--------+ l +----------+ +------------+ l lDomain-Al +-----------------------------+ lmem=256 l +--------+ ---------------------------------> continue Step.2
Step.2 define the value of virt.sxp.
+--- Xend ---------------------+ l +-Xenstore-+ +-config.sxp-+ l +----> mem=512 l -> mem=512 l l define l l +----------+ +------------+ l l +------------------------------+ l +--- l --------+ l +- l --------+ before l l mem=512 l l +--------+ l +-virt.sxp-+ l lDomain-Al +--- libvirt --+ lmem=256 l +--------+ ---------------------------------> continue Step.3
Step.3 start the domain and copy a file from config.sxp to virt.sxp.
+--- Xend ---------------------+ l +-Xenstore-+ +-config.sxp-+ l l l mem=512 l l mem=512 l l l +--- l ----+ +----- l ----+ l +----- l ------------- l ------+ l l +--- libvirt --+ l l copy l +-virt.sxp-+ l l +-------------> mem=256 l l before l l +----------+ l +--------+ l start +--------+ +--------------+ lDomain-Al +------------>lDomain-Al lmem=256 l lmem=512 l +--------+ -------------------> +--------+ "virsh start Domain-A"
3.3 When changing the allocation statically or permanently, write the change into virt.sxp. (When changing the allocation dynamically, do nothing)
CASE A: Dynamic change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=512 l l mem=512 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=256 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=512 l ll lmem=256 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000" ll
(state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=Y, mem=Y mem=X(no change) mem X to Y dynamically 3.stop the domain mem=Y, mem=Y mem=X 4.start the domain <------- <-----------define value mem=X, mem=X --->mem=X(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+
CASE B: Static change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=256 l l mem=256 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=512 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=256 l ll lmem=512 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000 --static" ll
(state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=X, mem=Y mem=Y(change to Y) mem X to Y statically 3.stop the domain mem=X, mem=X mem=Y 4.start the domain <------- <-----------define value mem=Y, mem=Y --->mem=Y(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+
CASE C: Permanent change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=512 l l mem=512 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=512 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=512 l ll lmem=512 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000 --perm" ll
(state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=Y, mem=Y mem=Y(change to Y) mem X to Y permanently 3.stop the domain mem=Y, mem=Y mem=Y 4.start the domain <------- <-----------define value mem=Y, mem=Y --->mem=Y(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+
Thanks, Saori Fukuta
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 17, 2007 at 02:38:26PM +0900, Saori Fukuta wrote:
Hi,
What the following things boil down to is that I hold file that formed in SXP for Life-cycle Management.
What do you think of my idea?
That I not too fond of adding ome more place where data for domain definition can be stored.
Thanks Saori Fukuta
On Fri, 13 Apr 2007 16:26:37 +0900 Saori Fukuta wrote:
Hi all,
I've been thinking about a way to change the hardware allocation on the Life-cycle. And I have some idea. Can I hear your comments about this?
1. Necessity of function These are conceivable cases of changing hardware allocation.
CASE A: Dynamic change change the allocation dynamically -> change the hardware allocation for now,
okay
and next time, start by the allocation before it changes.
that would have to be done using the API
CASE B: Static change change the allocation statically -> do not change the hardware allocation for now, but set the allocation for starting next. (example of use) Next time, want to start by the value that set before.
We can't know what are the original data which were used to create the domain was that /etc/xen/... ? was that an XML file coming from a client application ? was that another source by calling the Xen API ? We can't know, we can't modify the original data, and I don't think it's wise to try to keep extra data "somewhere" which would only be seen by libvirt or virsh and which would modify the original data. I don't think this has its place in libvirt or virsh, but what we must make sure is that the API allow to make the required change dynamically.
CASE C: Permanent change change the allocation permanently -> change the hardware allocation, and start next time with the same setting. (example of use) want to start by same value permanently.
Same thing, we can't know where the original data used to create a domain are. How do you want to modify it ? For example if I use a python script with the XML docmain definition in the script, you can't guess where it is, you can't change it, I think hoping to be able to do that or override it is a wrong approach. Either you succeed and suddenly from the application point of view the API is not reliable anymore or you won't succeed and it's probably not a good idea to suggest it. So I'm a bit puzzled by what you actually intent to do. In a management framework you can change things because you're supposed to held and control the original data used for those domains, but you can't generalize that model and IMHO it doesn't work if you try to push it down to libvirt or virsh, makes sense ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi Daniel, Thank you for your comments and sorry about my unclear explanation. Let me say what are the original data. The original data are "/var/lib/xend/domains/<domain UUID>/config.sxp" that made by Xen when defining a domain. I expect the following Life-cycle: 1. "Define a domain" -> a config.sxp file is made at "/var/lib/xend/domains/<domainUUID>". 2. "Start a domain" -> libvirt copies a file from "/var/lib/xend/domains/.../config.sxp" to "/var/lib/libvirt/<domainUUID>/virt.sxp"(tentative place). 3. "Change a allocation" 4. "Shutdown a domain" 5. "Start a domain" -> using the data which is "/var/lib/libvirt/.../virt.sxp". 6. Cycle of "Shutdown a domain, Start a domain, and Change a allocation" 7. "Undefine a domain" -> the libvirt deletes a "virt.sxp" file.
We can't know what are the original data which were used to create the domain was that /etc/xen/... ? was that an XML file coming from a client application ? was that another source by calling the Xen API ?
So, we have the original data if the domain was defined by whether using "/etc/xen..." or XML file.
That I not too fond of adding ome more place where data for domain definition can be stored.
I think that we need to store the domain definition to change a allocation dynamically or statically. I know the SXP file is Xen-specific, so I have thinking about another way, as an example, the format is XML. In that case, we can use virDomainGetXMLDesc to get the original data instead of copying a config.sxp file.
but what we must make sure is that the API allow to make the required change dynamically.
I'm not sure what you mean by "the API". Do you mean make sure that Xen API allow to change dynamically, or libvirt API ? Thanks, Saori.
On Thu, Apr 19, 2007 at 07:07:08PM +0900, Saori Fukuta wrote:
Hi Daniel,
Hi Saori,
Thank you for your comments and sorry about my unclear explanation.
I don't think it's a misunderstanding, maybe it is, but I rather think that you want to put something in libvirt, and I don't think it belongs there but into the application using libvirt instead.
Let me say what are the original data. The original data are "/var/lib/xend/domains/<domain UUID>/config.sxp" that made by Xen when defining a domain.
With some version of Xen, not all of them. You cannot rely on that. And what you suggest should be doable with that version of Xen must be doable with any virtualization. How would you do this with Xen 3.0.3, with KVM or with QEmu ? In KVM or QEmu there is no config files, just a running process.
I expect the following Life-cycle: 1. "Define a domain" -> a config.sxp file is made at "/var/lib/xend/domains/<domainUUID>". 2. "Start a domain" -> libvirt copies a file from "/var/lib/xend/domains/.../config.sxp"
No libvirt does not do that. And libvirt should not dig there. It makes it way too dependant on how Xen work, and this 'feature' would not be portable to other virtualization engines.
We can't know what are the original data which were used to create the domain was that /etc/xen/... ? was that an XML file coming from a client application ? was that another source by calling the Xen API ?
So, we have the original data if the domain was defined by whether using "/etc/xen..." or XML file.
We cannot assume we have the original data. The data maybe be XML built on the fly by a program using libvirt based on database records, and there is no way libvirt will ever be able to modify those. This must be handled by the upper layer.
That I not too fond of adding ome more place where data for domain definition can be stored.
I think that we need to store the domain definition to change a allocation dynamically or statically.
And I strongly disagree with that suggestion because I don't think it's a reasonnable expectation that we will always be able to do that.
but what we must make sure is that the API allow to make the required change dynamically.
I'm not sure what you mean by "the API". Do you mean make sure that Xen API allow to change dynamically, or libvirt API ?
Libvirt API provides entry points to manipulate objects. It should not provide a storage for some of those objects. The more state you add at the library level the more real problem you will get on the long term. It is a library, not an application. Manage that state in your application. Don't expect to have the library the state for you. But the library should provide the entry points needed to change what it currently running. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Fri, Apr 13, 2007 at 04:26:37PM +0900, Saori Fukuta wrote:
1. Necessity of function These are conceivable cases of changing hardware allocation.
CASE A: Dynamic change change the allocation dynamically -> change the hardware allocation for now, and next time, start by the allocation before it changes. (example of use) At night, change the hardware allocation. Next morning rebooting, return it.
CASE B: Static change change the allocation statically -> do not change the hardware allocation for now, but set the allocation for starting next. (example of use) Next time, want to start by the value that set before.
CASE C: Permanent change change the allocation permanently -> change the hardware allocation, and start next time with the same setting. (example of use) want to start by same value permanently.
I like cases A & C, because they map very well onto the capabilities provided by underlying virtualization systems like XenD (with XenAPI), or QEMU, or VMWare. I don't think it is possible to implement case B without requiring that libvirt maintain persistent state. This would be a very significant change for libvirt and the implication of this are very tricky when you consider remote management. With remote management, there can be many clients using libvirt, each libvirt instance is on a remote machine. So if libvirt were saving any state it would only be visible on one of the machines, so each client would potentially see a different config depending on which machine had extra state saved. I don't think this is at all desirable. It is better to have all state management done at the ultimate end point server (eg, XenD, or QEMUD), and keep libvirt as a completely stateless API.
The current situation of virsh command with Xen. CASE A / CASE B / CASE C virsh setmem x x o virsh setmaxmem x x o virsh setvcpus o x x virsh vcpupin o x x
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. Longer term I think it would be helpful to have alternate APIs which let the caller explicitly specify the desired scope for an operation eg enum { VIR_DOMAIN_SCOPE_STATIC = 1, VIR_DOMAIN_SCOPE_DYNAMIC = 2, VIR_DOMAIN_SCOPE_BOTH = 3, VIR_DOMAIN_SCOPE_CURRENT = 4, } virDomainScope; Then as well as the existing API: virDomainSetMemory(virDomainPtr dom, int mem); We'd have virDomainSetMemoryScope(virDomainPtr dom, int mem, int scope); Internally, we could simply re-implement the first style in terms of the second style, so we wouldn't increase internal maintainence overhead too much.
2. Change of command We need to add 3 options to the virsh command of changing allocation for CASE A, B, and C. So I propose the following options.
option name --dynamic ... dynamic change option (default) for CASE A --static ... static change option for CASE B --perm ... permanent change option for CASE C
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 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 ? 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 ? Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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.
On Fri, Apr 20, 2007 at 11:35:00AM +0900, Saori Fukuta wrote:
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 ?
This is already possible today actually. In Xen 3.0.4 or later there is the lifecycle management APIs, so there is an API which lets you define a config for a guest. So in this case we just convert from XML -> SEXPR, in the same way that we do to boot a guest. For older Xen, we simply write files straight into /etc/xen. The QEMUD daemon stores the XML files for QEMU/KVM in the native libvirt format, so that's easy. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Fri, 20 Apr 2007 14:31:02 +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
This is already possible today actually. In Xen 3.0.4 or later there is the lifecycle management APIs, so there is an API which lets you define a config for a guest. So in this case we just convert from XML -> SEXPR, in the same way that we do to boot a guest. For older Xen, we simply write files straight into /etc/xen. The QEMUD daemon stores the XML files for QEMU/KVM in the native libvirt format, so that's easy.
So it will be possible following way using new API right ? new API: virDomainSetMemoryScope(virDomainPtr dom, int mem, int scope);
virsh setmem foo 500 -> VIR_DOMAIN_SCOPE_CURRENT(4) virsh --static setmem foo 500 -> VIR_DOMAIN_SCOPE_STATIC(1) virsh --dynamic setmem foo 500 -> VIR_DOMAIN_SCOPE_DYNAMIC(2) virsh --static --dynamic setmem foo 500 -> VIR_DOMAIN_SCOPE_BOTH(3)
When scope is VIR_DOMAIN_SCOPE_CURRENT, execute current handling. When scope is other, execute as follows: 1. get the config using domainDumpXML 2. change the value of memory -> When scope is VIR_DOMAIN_SCOPE_STATIC or VIR_DOMAIN_SCOPE_BOTH: - change the value of currentMemory on the config -> When scope is VIR_DOMAIN_SCOPE_DYNAMIC or VIR_DOMAIN_SCOPE_BOTH: - change the actual memory allocation using domainSetMemory 3. define the config using domainDefineXML Here is example. (NOTE: not compiled or tested. need error handling) Index: virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.73 diff -u -p -r1.73 virsh.c --- virsh.c 13 Apr 2007 08:04:08 -0000 1.73 +++ virsh.c 23 Apr 2007 08:55:55 -0000 @@ -1461,6 +1461,9 @@ cmdSetmem(vshControl * ctl, vshCmd * cmd virDomainPtr dom; int kilobytes; int ret = TRUE; + int op_static = vshCommandOptBool(cmd, "static"); + int op_dynamic = vshCommandOptBool(cmd, "dynamic"); + int flag = VIR_DOMAIN_SCOPE_CURRENT; if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) return FALSE; @@ -1475,7 +1478,14 @@ cmdSetmem(vshControl * ctl, vshCmd * cmd return FALSE; } - if (virDomainSetMemory(dom, kilobytes) != 0) { + if (op_static && op_dynamic) { + flag = VIR_DOMAIN_SCOPE_BOTH; + } else if (op_static) { + flag = VIR_DOMAIN_SCOPE_STATIC; + } else if (op_static) { + flag = VIR_DOMAIN_SCOPE_DYNAMIC; + } + if (virDomainSetMemoryScope(dom, kilobytes, flag) !=0) { ret = FALSE; } Index: libvirt.c =================================================================== RCS file: /data/cvs/libvirt/src/libvirt.c,v retrieving revision 1.68 diff -u -p -r1.68 libvirt.c --- libvirt.c 18 Apr 2007 10:14:07 -0000 1.68 +++ libvirt.c 23 Apr 2007 08:56:14 -0000 @@ -1304,6 +1304,55 @@ virDomainSetMemory(virDomainPtr domain, return -1; } +int +virDomainSetMemoryScope(virDomainPtr domain, unsigned long memory, int scope) +{ + virConnectPtr conn; + char *dump; + virDomainPtr dom; + + if (domain == NULL) { + TODO + return (-1); + } + if (!VIR_IS_CONNECTED_DOMAIN(domain)) { + virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); + return (-1); + } + if (domain->conn->flags & VIR_CONNECT_RO) { + virLibDomainError(domain, VIR_ERR_OPERATION_DENIED, __FUNCTION__); + return (-1); + } + if (memory < 4096) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } + + conn = domain->conn; + + if (scope == VIR_DOMAIN_SCOPE_CURRENT){ + if (conn->driver->domainSetMemory) + return conn->driver->domainSetMemory (domain, memory); + } else { + if (conn->driver->domainDumpXML) + dump = conn->driver->domainDumpXML (domain, 0); + switch (scope) { + case VIR_DOMAIN_SCOPE_STATIC: + /* change the value of currentMemory */ + case VIR_DOMAIN_SCOPE_DYNAMIC: + /* change the actual memory allocation using domainSetMemory */ + case VIR_DOMAIN_SCOPE_BOTH: + /* change the value of currentMemory */ + } + if (conn->driver->domainDefineXML) + dom = conn->driver->domainDefineXML (conn, dump); + } + + virLibConnError (conn, VIR_ERR_CALL_FAILED, __FUNCTION__); + return -1; +} Thanks, Saori Fukuta.
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Saori Fukuta