Red Hat Bugzilla – Bug 624673
Rework fence_vmware fence agent to use SOAP API to connect to Virtual Center instead of VMware Perl API
Last modified: 2013-03-06 16:01:41 EST
Description of problem: Existing fence_vmware uses 3rd party RPM dependency from VMware (VMware Perl API). libvirt VMware/ESX driver implemented a SOAP method to connect to Virtual Center. libvirt usage is fairly different than what we want for a general fence agent, so it's been recommended by libvirt team that we lift their SOAP code (just the parts of it that we need for the fence agent) and use it to rework the fence_vmware agent.
Doing this will allow us to remove fence_vmware_helper.pl and fence_vware can be exclusively Python code. This will likely create a dependency on a SOAP module to be pulled into Pyton, such as SOAPy. The vmware web site has a "VMware Infrastructure SDK Programming Guide" that seems helpful, too. Basic power on/off operations are PowerOnVM_Task and PowerOffVM_Task. Also look at libvirt, which uses a C API but has some python code to generate the SOAP code. This is more than we need for fence_vmware, but might be a handy reference.
*** Bug 486207 has been marked as a duplicate of this bug. ***
*** Bug 590696 has been marked as a duplicate of this bug. ***
One thing to consider is that having a username/password combination with this level of access can be dangerous. In documentation we ought to recommend that access levels be leveraged to provide a user with specific privileges. Further, usernames and passwords can expire - using some authentication method (similar to ssh keys as in ESX connectivity previously) would be the ideal solution/option.
liko also mentioned that there may be a way to use some sort of vCenter auth token in place of traditional user/pass. If this auth method exists in vCenter we should investigate and incorporate it into the design of the new fence agent.
Talked to marx about this, and he is not aware of any auth mechanism exposed via the SOAP interface aside from standard user/password. There may be other auth mechanisms available to vCenter in general, but if they're not exposed via SOAP we can't take advantage of them. As liko mentions above, we should document the following as best practice: In vCenter create a new user that has limited permissions (i.e. user foo can only control guest 1 & 2 lifecycle functions). Then the fence_vmware agent can be configured only with user foo credentials, limiting exposure of that user/pass. liko: is pw timeout a hardcoded thing in vCenter or maybe does it only apply to the top level Administrator user?
I have found out that even it is not mentioned in manual, method LoginBySSPI is documented in API. So we can try to implement it.
LoginBySSPI in VMWare SOAP API: http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.SessionManager.html#loginBySSPI @dpal: Can we use IPA for that instead of Windows AD?
(In reply to comment #10) > LoginBySSPI in VMWare SOAP API: > > http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.SessionManager.html#loginBySSPI > > @dpal: Can we use IPA for that instead of Windows AD? SSPI is a native Windows interface. I am not sure but it actually might work. Please see the following link http://msdn.microsoft.com/en-us/library/ms995352.aspx I think you would have to implement service and client in a special way as described in the article. Simo, can you add more?
@pmyers, regarding https://bugzilla.redhat.com/show_bug.cgi?id=624673#c8, I was incorrect. There is no session timeout, so this might no longer be an issue. From the documentation I've seen - there is fine granularity in permissions, such that the fence user can be locked down quite a bit. I agree that we should document that as a best practice.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1599.html