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 -=|