On 1/29/07, Dave Blaschke <[EMAIL PROTECTED]> wrote:
Andrew Beekhof wrote:
> On 1/29/07, Serge Dubrouski <[EMAIL PROTECTED]> wrote:
>> On 1/29/07, Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
>> > On 2007-01-29T10:10:44, Andrew Beekhof <[EMAIL PROTECTED]> wrote:
>> >
>> > > >Attached is an update version. It supports on and off commands now.
>> > > >User still have to configure hostlist in a form "node:xen0_host
>> > > >node:xen0_host ...".
>> > > thats going to be a pain when the VMs are also resources (and
>> therefor
>> > > moving around).
>> > >
>> > > or aren't we dealing with this case here? i loose track
>> sometimes :-)
>> >
>> > That's not being dealt with, AFAIK. In that case, the command wouldn't
>> > be a xm shutdown/start, but a "crm_resource ..." invocation;
>> potentially
>> > one trying to stop a specific clone. I'm not sure _you_ want to deal
>> > with that yet. ;-)
>> >
>> > However, I think it could be simplified.
>> >
>> > First, in many cases, all the virtual guests are going to be on a
>> single
>> > physical node. (ie, test "clusters".) Then only supplying one node to
>> > ssh to should be sufficient.
>>
>> Let's nod discuss trivial cases.
>>
>> >
>> > Second, by providing a simple list of all physical nodes, the system
>> > should be able to automatically figure out which node it needs to
>> ssh to
>> > to shot the guest. It could try to autopopulate the hostlist from
>> > /etc/xen/vm/* or some other directory, as well.
>>
>> Ok, Let's say user provided us with 3 Xen0 Nodes and ALL 3 of them
>> have config file for node1 in /etc/xen/vm. Then where should I start
>> node1 when "on" command is called?
> wouldn't you just use the same node name that you used for "off"?
>
> or are "on" and "off" distinct operations sent to you from the stonithd?
>
> by that i mean that stonithd will never just tell you to turn a node
> on, only to stop or reset it in some way. so if you were able to do
> the "off", then you know you can also do the "on".
Sorry to interrupt the flow of this thread, but I have been off chasing
down other non-HA problems...
Yes, "on" and "off" are distinct operations sent from stonithd.
However, in the event of a STONITH condition, I believe that only
"reset" is sent by stonithd (hence why "on" and "off" are optional
parameters, while "reset" is required). Indeed, even some STONITH
plugins do not recognize the "on" and "off" parameters. The "on" and
"off" parameters were added to the stonith command so that one could
reset and power on/off nodes from the command line, so it is possible
for a plugin to receive the "on" or "off" command but that would
indicate that the request came from outside stonithd (command line,
script). I am not able to grep through the code right now (my pSeries
machine is no longer accepting connections to HMCs so it is lost in
space) to verify my statements, but I believe them to be true from my
journeys through STONITH code...
In this case if we all are agrre I can do following for this plugin:
1. Accept a simple list of possible Xen0 hosts as a required parameter.
2. Accept xen_vm_config_dir as an optional parameter
3. Implement "reset" and "off" commands and ignore "on" command.
It is still not clear what additional commands have to be implemented.
I mean do I have to have OCF's "meta-" commands and which of stonith
"getinfo-" commands are really required.
>
>>
>> >
>> > Then having to actually configure something should be quite rare.
>> >
>> > (Note that dealing with dead physical nodes is slightly tricky.)
>> >
>> > > as an aside (for lars/alan), would it be worthwhile having these
>> > > plugins use the OCF RA standard instead?
>> >
>> > They already mostly are.
>> >
>> >
>> > Sincerely,
>> > Lars
>> >
>> > --
>> > SUSE Labs, Research and Development
>> > SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
>> > "Ignorance more frequently begets confidence than does knowledge."
>> >
>> > _______________________________________________________
>> > Linux-HA-Dev: [email protected]
>> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> > Home Page: http://linux-ha.org/
>> >
>> _______________________________________________________
>> Linux-HA-Dev: [email protected]
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
>>
> _______________________________________________________
> Linux-HA-Dev: [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
