I was thinking about how CDROM media changes could be requested by apps,
which in turn got me thinking about distinction between persistent & live
configuration changes. It occurred to me that this is something that is
not really mentioned in the spec, and thus could do with further clarity .
Considering the domain object - we obviously have setters & getters
for all the properties of a domain (and any nested objects there-in
such as network / block devices). In reading the spec I've previously
assumed that all the setters / getters refer directly to the domain's
config file, however, re-reading its clear this isn't a valid assumption.
When setting a property, clearly the domain's underlying persistent
configuration will be updated, but does the change also apply to the
live VM if it is currently executing ? The spec would seem to imply that
this is the case, and if so, things get very interesting (read: complicated)
At a coarse level there are two kinds of properties - those which can be
changed at runtime (memory allocation, # virtual CPUs); those which can
only be changed before/at boot (maximum memory, NUMA topology). What is
more, the set which can be adjusted at runtime varies according to the
capabilities of the guest - paravirt can balloon memory, HVM cannot
(unless the HVM guest were to support memory hotplug, which from the Dom0
side of things we have no way of determining). To add yet another
complication there is no guarentee that the HV will fully satisfy the
changed resource allocation - eg, if we request a memory increase of 200 MB,
the balloon driver may actually only provide 100 MB to the guest, depending
on requirements of other guests). Similarly if we request a CDROM media
change, but the guest OS has locked the media it is impossible to satisfy
So, if we adjust the memory for a domain, the persistent config can defintely
change to the requested value. The live configuration may not change at all,
may change partially, or may change exactly.
What does this mean in terms of the API ? The API defined 3 types of property:
- RO(run) - read only field, whose value is computed automatically at runtime
- RO(ins) - value set a time of object creation, read only for during of
guest execution
- RW - value can be set at any time during guest lifecycle.
There were then two APIs for accessing these properties:
- get(foo) - returns the value for a property 'foo'
- set(foo) - updates the value for a property 'foo'
This would appear to be insufficient granularity to deal with the scenarios
I've outlined above:
- For some properties, the distinction RO(ins) / RW is impossible to define
in the spec - it is fundamentally determined by the capabilities of the
guest OS being run in the VM.
- There is no way to specify the scope of a property change:
a. persistent config
b. live VM config
c. both
- There is no way to determine if the persistent config is in sync with the
live VM config
This could be addressed in many ways
1 Ignore the difference, and declare that 'set' always affect both persistent
&
live config & leave application to infer whether one, other, or both were
successfully updated based on returned error codes.
2 Allow application to explicitly set persistent, vs live config through
separate APIs.
value get_persistent(name)
value get_live(name)
set_persistent(name,value)
set_live(name,value)
3 Allow application to specify a flag indicating the desired scope of the
change.
enum scope { LIVE, PERSISTENT }
value get(name, scope)
set(name, value, scope)
4 Something else ?
Sorry for length - this was intended to be a 4 line mail asking about how
to effect live CDROM media changes, but turned out much much longer!
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 -=|
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home