Bug 1213345
| Summary: | Virsh support connect esxi 6.0 hypervisor. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | tingting zheng <tzheng> | |
| Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> | |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 7.2 | CC: | alfonsi.alex, dyuan, juzhou, mprivozn, mzhan, rbalakri, rjones, usurse, xiaodwan | |
| Target Milestone: | rc | Keywords: | Upstream | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | libvirt-1.2.16-1.el7 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1213348 1277274 (view as bug list) | Environment: | ||
| Last Closed: | 2015-11-19 06:29:14 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1213348 | |||
|
Description
tingting zheng
2015-04-20 11:03:07 UTC
Update libvirt to latest version:
libvirt-1.2.14-1.el7.x86_64
1.Virsh can connect to esx server successfully.
# virsh -c esx://10.66.72.49/?no_verify=1
Enter username for 10.66.72.49 [root]:
Enter root's password for 10.66.72.49:
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # quit
2.But virsh fails to connect esx server via vcenter which is virt-v2v does.
# virsh -c vpx://root.72.112/data/10.66.72.49/?no_verify=1
Enter root's password for 10.66.72.112:
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.
Tested on the latest libvirt version,no such problem exist.
Version:
libvirt-1.2.15-1.el7.x86_64
1.Virsh can connect to esx server successfully.
# virsh -c esx://10.66.72.49/?no_verify=1
Enter username for 10.66.72.49 [root]:
Enter root's password for 10.66.72.49:
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # quit
2.virsh connect esx server via vcenter which is virt-v2v does.
# virsh -c vpx://root.72.112/data/10.66.72.49/?no_verify=1
Enter root's password for 10.66.72.112:
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # list
Id Name State
----------------------------------------------------
60 win2012R2-vcenter running
62 app_vcenter600 running
virsh #
Refer to the above comments,pls close this bug.
Correct. This has been fixed upstream already:
commit 0396394f027edb5fa70514a0d11fa62ea7281bd9
Author: Matthias Bolte <matthias.bolte>
AuthorDate: Sun Oct 19 00:11:13 2014 +0200
Commit: Matthias Bolte <matthias.bolte>
CommitDate: Sat Nov 8 15:35:36 2014 +0100
esx: Simplify VI (vSphere) API and VMware product version handling
Store version numbers in this format
version = 1000000 * major + 1000 * minor + micro
produced by virParseVersionString instead of dedicated enums.
Split the complex esxVI_ProductVersion enum into a simpler
esxVI_ProductLine enum and a product version number.
Relax API and product version number checks to accept everything that
is equal or greater than the supported minimum version. VMware ESX
went through 3 major versions and the vSphere API always stayed
backward compatible. This commit assumes that this will also be true
for future VMware ESX versions.
Also reword error messages in esxConnectTo* to say what was expected
and what was found instead (suggested by Richard W.M. Jones).
v1.2.10-60-g0396394
Tested the bug with:
libvirt-1.2.17-2.el7.x86_64
1.Virsh can connect to esx server successfully.
# virsh -c esx://10.66.72.49/?no_verify=1
Enter username for 10.66.72.49 [root]:
Enter root's password for 10.66.72.49:
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # list
Id Name State
----------------------------------------------------
1 win2012R2-vcenter running
4 app_vcenter600 running
virsh #
2.virsh connect esx server via vcenter which is virt-v2v does.
# virsh -c vpx://root.72.112/data/10.66.72.49/?no_verify=1
Enter root's password for 10.66.72.112:
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # list --all
Id Name State
----------------------------------------------------
60 win2012R2-vcenter running
62 app_vcenter600 running
- Auto-esx6.0-win7-efi shut off
- esx6.0-rhel5.11-i386 shut off
- esx6.0-rhel5.11-x86_64 shut off
- esx6.0-rhel6.7-i386 shut off
- esx6.0-rhel6.7-x86_64 shut off
Refer to the above comments,the bug is fixed,so move the bug to VERIFIED.
Hi all, I am having the exact same issue but on 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 ~]# The difference is that we are trying to limit the level of privileges to assign to the user that tries to connect to the vCenter Server to avoid assigning 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. 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. https://rhn.redhat.com/errata/RHBA-2015-2202.html > Peer certificate cannot be authenticated with given CA certificates (60) : Peer's certificate issuer has been marked as not trusted by the user. You haven't set up certificates correctly. The easiest workaround is to append '?no_verify=1' to the path. See: http://libguestfs.org/virt-v2v.1.html#vcenter:-test-libvirt-connection-to-vcenter > virt-v2v: error: expecting a libvirt guest name on the command line You've used the virt-v2v command incorrectly. Suggest reading the virt-v2v(1) manual page before starting. > HTTP/1.1 404 Not Found As Tingting said in the (private) comment 12, you need to use the --dcpath parameter in RHEL 7.2. Hopefully in RHEL 7.3 we will be able to handle this situation automatically, but it requires some changes to libvirt. It works with upstream/Fedora virt-v2v already. Documentation for --dcpath is also in the virt-v2v man page, in the OPTIONS section: http://libguestfs.org/virt-v2v.1.html#options |