Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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?
@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