[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] XCP XenAPI fencing script (clustering support)



Hi Matt,

Regarding the status call could you send me some pointers about what must/can a fence/stonith agent implement (the requirements of fenced/pacemaker)? I've based my work on a quick look at what the other stonith scripts do (especially the ssh and xen0, which were written as shell scripts).

Cheers,

Geza

Hi geza,

Just had a quick look. One thing that is missing is a status rpc. The underlying fencing libraries use status to make sure the fencing worked.

Otherwise looking good.

Cheers,
Matt.

On 04/04/2011 6:12 AM, "Gémes Géza" <geza@xxxxxxxxxxx> wrote:
> 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
>> <mailto: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:-
>>> http://code.google.com/p/fence-xenserver/downloads/list
>>>
>>> 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):-
>>>
>>> cd /tmp
>>> tar xvzf fence-xenserver-0.8.tar.gz
>>> cd fence-xenserver-0.8
>>> ./fence_cxs_redhat.py -o list -s http://192.168.1.1/ -l root -p
>>> <passwd>
>>>
>>> That should be enough to test if it is functioning properly.
>>> Appreciate any feedback.
>>>
>>> Thanks,
>>> Matt.
>>>
>>>
>>> _______________________________________________
>>> Xen-users mailing list
>>> Xen-users@xxxxxxxxxxxxxxxxxxx
>>> <mailto:Xen-users@xxxxxxxxxxxxxxxxxxx>
>>> http://lists.xensource.com/xen-users
>> Hi,
>>
>> 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.
>>
>> Best Regards
>>
>> Geza
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx <mailto:Xen-users@xxxxxxxxxxxxxxxxxxx>
>> http://lists.xensource.com/xen-users
>>
>>
>

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.