Hi all, I am having an hard time trying to figure out permission level to connect to ESXi 5.5. Command: vpx://USERNAME@vCenterServerName/Data%20Center%20Name/ESXiCluster/ESXiHostName/?no_verify=1 list --all Error: error: failed to connect to the hypervisor error: internal error: HTTP response code 500 for call to 'SessionIsActive'. Fault: ServerFaultCode - Permission to perform this operation was denied. [root@CENTOS7 ~]# We are trying to limit the level of privileges to assign to the user that tries to connect to the vCenter Server and ESXi host to convert VMs and avoid to assign an Administrator role. Is there a a specific list of vCenter Server objects that libvirt needs to access in order to connect to the ESXi host successfully? Note: Connection to the host works fine if the user is set under Administrator role. Libvirt version: libvirt-client-1.2.17-1.el7.x86_64 Many Thanks!
As far as I know, no one has ever looked into this. However if you come up with a useful list of permissions required for various operations, it would be good to know.
Figured that the following vCenter Objects are the minimum required for Libvirt and virt-v2v to connect and convert VMs: Create custom Role under vCenter Server (tested in version 5.5) and check mark the following objects: Datastore: -Browse datastore -Low level file operations Session: -Validate session Virtual Machine: + Provisioning: -Allow disk access -Allow read-only disk access This procedure allows Administrator to assign Non-Admin right to external users that need to convert VMs with Virt-v2v. Regards.
So, what can be done on libvirt's behalf so that this situation gets off the table? I believe the result should be a documentation patch, but I am afraid that I know too little about ESX to produce something meaningful. Alessandro - do you mind proposing a patch?
Thanks, I have documented this in virt-v2v upstream: https://github.com/libguestfs/libguestfs/commit/4e2433862505762b926d9eaf2201ddf666fa73a5
(In reply to Michal Privoznik from comment #3) > So, what can be done on libvirt's behalf so that this situation gets off the > table? I believe the result should be a documentation patch, but I am afraid > that I know too little about ESX to produce something meaningful. Alessandro > - do you mind proposing a patch? Michal, I believe the best way would be to write a prerequisite paragraph on both Libvirt and Virt-v2v documentation/guides regarding VMware environments. As a user that needs to migrate from VMware to KVM I had a bit of an hard time putting together all the info to successfully build a working environment, specifically on Fedora since I am using CentOS. I would be very happy to help! Regards, Alessandro
(In reply to Richard W.M. Jones from comment #4) > Thanks, I have documented this in virt-v2v upstream: > > https://github.com/libguestfs/libguestfs/commit/ > 4e2433862505762b926d9eaf2201ddf666fa73a5 Added the following object. Virtual Machine: + Provisioning: - Guest Operating system management by VIX API Without the above the "Copying disk" step by Virt-v2v would hang at 0.00%.
Thanks, I will push this additional change shortly.