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/
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.