2:26 a.m.
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
12:38 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
1:08 p.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
5:07 a.m.
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.
5:20 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
10:18 a.m.
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 -=|
9:35 p.m.
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.
8:31 a.m.
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 -=|
3:59 a.m.
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.
6425
days inactive
6435
days old
8 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Saori Fukuta