This is an archived copy of the Xen.org mailing list, which we have
preserved to ensure that existing links to archives are not broken.
The live archive, which contains the latest emails, can be found at
http://lists.xen.org/
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
Hi Matt,
As I've wrote before I've started working on the server part. The
first working example server code is at: https://github.com/geza-gemes/Xen-Cloud-Platform-Xensever-stonith-fence-agent
It is an XML-RPC server which accept start, shutdown and reboot
requests. The stonith/fence agent
There are still lots of things to do:
-Load configuration, secrets from a ini file (I've started working
on this)
-Handle the signals which could be sent to the server process
-Better logging (currently none)
-Better handling of already running already shutdown, paused
suspended states (there is none at the moment)
-Set up an init script, and an optional stunel config for the server
(XCP/Xenserver doesn't have SSL python libs)
-Build a rpm of the server part so it can be easily installed in
Dom0
Cheers,
Geza
Hi Geza,
Thanks for your feedback.
Using a specific server for this was the first approach I
took, writing a python daemon process that utilised XML-RPC (I
will see if I can dig it up). Got a fair way down that path but
realised I was just rewriting fence-virtd so then I started to
look into altering fence-virtd instead. That's where I stopped.
I want to get back around to this eventually, but that's not
what this script is for.
This script is to fence a node through the XenAPI. As you
mentioned, the security model employed by XenAPI does not allow
username/password based access control of specific VM's (that I
am aware of without using windows based active directory
credentials), but maybe it will in the future. Note that this is
an underlying API limitation.
The same script can be updated to also use GezaAPI in the
future, once this is written. I will be happy to make the
changes once you have your daemon working and API laid out. To
be honest it should be a pretty straight forward transition.
Cheers,
Matt.
On Thu, Mar 31, 2011 at 6:51 AM, Gémes
Géza <geza@xxxxxxxxxxx>
wrote:
2011-03-30 13:09
keltezéssel, m c írta:
Hi,
I think
this would be the best forum, let me know if
not.
I am in
the middle of writing fencing scripts for Citrix
XenServer virtual machines (specifically for use
with Redhat Clustering, but will also work from
pacemaker etc) and I noticed that XCP uses the
same XenAPI (from what I can tell).
Just
wondering if someone would be able to test the
scripts on XCP and let me know if they work.
The
latest tar ball can be downloaded from the
following URL:-
Once
extracted a test can be performed as follows
(the following will just list all the VM's and
their current state, it will not turn reboot a
machine so is safe):-
Just this morning I've decided to start writing something
similar (stonith script for pacemaker).
I have only one objection to the approach used by your
script. It would be more robust (more secure) if the
script would connect to a small server running in Dom0
with some shared secret corresponding to each DomU, in
this way non-cluster member DomU's won't be able to shut
down cluster members, or legit DomU's wouldn't be able to
do whatever they would want on the Dom0 (allowing
fence/stonith to run with root credentials, ssh keys,
whatever laying somewhere in the DomUs filesystem is not
the best solution regarding security).
I planed to write a small server program which would run
on the Dom0, with a htpasswd like config file, where user
entries would have been DomUs, each with a password. The
fence agent/stonith script would connect to this server
and providing the right credentials for the given DomU it
would be able to issue force-reboot, start,
force-shutdown, whatever would be needed actions on that
DomU, and nothing more. A similar approach without using a
Dom0 side server would be possible if using AD
authentication and assignment of different DomUs to
different roles.
Home