Re: [Xen-users] setting the path where xm looks for config files

["Henning Sprang" <henning_sprang@xxxxxx>]

On 1/14/07, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
> Yes, I don't believe that XenD watches its config files on disk for manual
> changes, so I think you'll need to use the APIs to alter stuff. I fixed a
> few bugs just before 3.0.4 was released so that you can at least use the
> basic 'mem-set', 'mem-max', 'vcpu-set' commands from xm  to change the
> config of an inactive guests, but there's much more it'd be desirable
> to do besides those. Probably the most important commands which I don't
> believe work on inactive guests currently are the block-attach/detach &
> network-attach/detach commands.
Fortunately, xm create seems to keep working as usual ( I
misunderstood you as like xm create would be more like an alias to xm
new, xm start), and it looks to me like domains started with it are
not stored in this place, and disappear completely when destroyed.

I also think( if that's not the case, as I understand you), that all
the manipulation functions should work on stored configs, even when
they are stopped - when using this storage, for sure everyone wants to
have the same full control as with the config of a running domain, or
one stored in a local config file. Otherwise one is forced to first
remove them, and re-add them again, losing the old uuid for no good
reason.

And I'd vote the old create should keep being there. Currently I see
not many good reasons why I should use this config storage. The only
one I can see is maybe that a domain configuration could be remotely
modfied without transferring files.
But in a distributed environment, it would be better to store domain
configuration in a database, then it can be modified centrally, and
remotely, and each domain can be started wherever I want to start it -
e.g. on the machine that currently has the most resources available.

Henning

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users