Bug 1036248
| Summary: | VMware support broken in Fusion 6 and WS 10 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Brad Ackerman <brad> | ||||||
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> | ||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | unspecified | CC: | acathrow, berrange, clalancette, denis.kondratenko, eblake, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint | ||||||
| Target Milestone: | --- | Flags: | denis.kondratenko:
needinfo+
|
||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-01-03 18:15:01 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: | |||||||||
| Attachments: |
|
||||||||
Moving to Virtualization Tools instead of Fedora. Created attachment 844995 [details]
Another ver to fix same issue
Found same issue for my VMware Fusion for OS X.
Got this error:
$ virsh -c vmwarefusion:///session
error: failed to connect to the hypervisor
error: An error occurred, but the cause is unknown
Here what I have:
$ virsh -v
1.2.0
$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vmx -v
VMware Fusion Information:
VMware Fusion 6.0.2 build-1398658 Release
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.9.1
BuildVersion: 13B42
After investigation found same root cause. Incorrect usage of virAsprintf and that vmware-vmx reports to stderr.
Please post your patch on the upstream list: libvir-list. There it will get reviewed much faster; not to mention that developers prefer 'git am' on email over manual download of a URL from a bugzilla patch. Will be fixed in the 1.2.1 release:
commit d69415d4bcaf1866af9b728eef5e0d81bc8f7d72
Author: Denis Kondratenko <denis.kondratenko>
Date: Fri Jan 3 19:57:37 2014 +0200
vmware: os x support is broken
https://bugzilla.redhat.com/show_bug.cgi?id=1036248
Incorrect usage of virAsprintf. vmware-vmx reports version
information to stderr, at least for OS X 10.9.1.
Signed-off-by: Eric Blake <eblake>
|
Created attachment 830810 [details] Patch fixing parts 1 and 2 of described bug Description of problem: libvirt is broken in VMware Fusion 6 and Workstation 10. Version-Release number of selected component (if applicable): Both 1.1.4 and HEAD How reproducible: Steps to Reproduce: 1. On a Mac, build 1.1.4. 2. virsh -c vmwarefusion:///session This is sufficient to fail on Fusion 6. I don't have WS 10 to test with me, but if the above fails to error, then: 3. Create and start a domain using VMX hardware version 10. 4. virsh -c again (replace vmwarefusion with the appropriate prefix) Actual results: Can't connect to hypervisor (unspecified error). Once that issue is patched (see below), error reported is: Expecting VMX entry 'virtualHW.version' to be 4, 7, 8 or 9 but found 10 Expected results: virsh connects to the hypervisor; list returns the actual list of domains; other commands work as expected. Additional info: There are at least three issues preventing VMware Fusion 6/Workstation 10 from working: 1. The specification of virAsprintf was changed, but vmware_conf.c wasn't. 2. VMware Fusion 6 (and most likely Workstation 10, but I haven't been able to check) outputs version information (as in vmware-vmx -v) to stderr; it used to output to stdout. 3. libvirt's VMX support does not expect hardware version 10 and has a bad problem when encountering it. I've attached a patch that solves problems #1 and #2, which probably isn't quite the way it should be done but serves to demonstrate the problem. I haven't gotten to #3; hopefully someone more familiar with vmx.c can verify that the obvious fix is sufficient.