On 10/01/10 07:43, Wei Li wrote:
Thanks a lot Mike for helping clarifying questions above!
I like to further clarify about spconfig. From replied post, my understanding
is autosave and spconfig contain only info on how resources (CPU/mem/mau/vnet
etc) are allocated to each domain. Guest domain state is in separate file.
Should I add-spconfig for any single resource changes to both controller domain
and guest domain, all add-spconfig is needed only for controller domain
resource changes? How delayed reconfiguration comes into the picture?
An spconfig contains resource config (aka machine description or MD)
information for all domains in that config (primary/control + all
guests) + hypervisor config + machine config.
Any resource change (and some other commands, such as 'set-var')
to any domain that is in the current ldmd configuration will make
the ldmd internal configuration different from what is on the SP.
Whether one should update the spconfig after each operation depends
upon usage. If you're doing an initial configuration, I'd think
you'd want to do all the ldm commands to create that configuration
before doing an 'add-spconfig'. If you're doing a more incremental
approach, where you're adding features one at a time to test, say,
then it might make sense to do an 'add-spconfig' after each
operation.
Delayed reconfig is another special case (depending upon which
version of LDoms you're using), and I can't say that I'm an
expert on the ins-and-outs of it. I know it's needed when you change
the primary config and the corresponding DR capability isn't
available (if you add memory and memory DR is not available).
AFAIK, it's more or less orthogonal to spconfig/autosave, although
autosave does keep a backup (hidden) spconfig when you go into delayed
reconfig, in case you want to later do a cancel-reconfig (but all this
is transparent to the user). I think the updated config on a delayed
reconfig only requires a reboot (of the primary domain) to get the
changes, whereas if you did an add-config, it would require a power
cycle.
Mike
_______________________________________________
ldoms-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
