Today I updated Vagrant, Vagrant VMware Utility, and vagrant-vmware-desktop on my Mac. After everythnig was updated I checked the status of my machines - vagrant status - and received an unusual error:
failure encountered: Command is not supported by Fusion standard license version
Debug shows an issue accessing accessing vmnet information:
DEBUG vagrant_utility: request METHOD=GET PATH=/vmnet RESPONSE=400 ERROR=failure encountered: Command is not supported by Fusion standard license version
I've tried reinstalling previous versions of the software mentioned above (except for vagrant-vmware-desktop, not sure how to do that), but this doesn't seem to work. What is the recommended procedure for reinstalling previous versions? Do you need to uninstall existing versions first? Restart?
Thanks!
Vagrant 2.2.10
Vagrant VMware Utility 1.0.11
vagrant-vmware-desktop 2.1.2
VMWare Fusion "standard" 11.5.6 (16696540)
macOS 10.15.6
https://gist.github.com/ryanolton/d9c461b4ebee273b13e086f541ebe90c
I should see a list of my machines.
Error message
I am also experiencing this issue after upgrading to Vagrant 2.2.10 on Mac OS 10.15.6. VMWare Fusion 11.5.6.
vagrant status
An error was encountered while generating the current list of
available VMware adapaters in use on this system.
failure encountered: Command is not supported by Fusion standard license version
Please resolve any problems reported in the error message above and
try again.
I never actually figured out what component was the problem here, but this is what I did to get things back up and running:
Uninstall the vagrant-vmware-desktop plugin: vagrant plugin uninstall vagrant-vmware-desktop
Uninstall the latest version of VMWare (15.5.6), Vagrant (2.2.10), and Vagrant VMWare Utility (1.0.11)
Install VMWare 15.5.5, Vagrant 2.2.8, and Vagrant VMWare Utility 1.0.9
Install v2.1.0 of the vagrant-vmware-plugin: vagrant plugin install vagrant-vmware-desktop --plugin-version 2.1.0
Now things work again.... 😭
I'm experiencing this as well.
$ vagrant version
Installed Version: 2.2.10
Latest Version: 2.2.10
You're running an up-to-date version of Vagrant!
$ vagrant plugin list
vagrant-vmware-desktop (2.1.2, global)
I was able to get vagrant status to work again by downgrading just the vagrant-vmware-desktop plugin. Current environment is now:
Additional info:
vagrant destroy works with:
<--- downgradedvagrant up works with:
<--- downgraded<--- downgradedJust chiming in here to say I am seeing the exact same thing. Ran into this trying to once again get around the awful integration with a paid for plugin for Fusion.
Same issue with Fusion 12 (free version) after upgrading my vagrant license and installing latest versions of vagrant addons. Downgrading Vagrant VMWare Utility to 1.0.9 solved it at least for vagrant up, halt and status.
Same issue with Fusion 12 (free version) after upgrading my vagrant license and installing latest versions of vagrant addons. Downgrading Vagrant VMWare Utility to 1.0.9 solved it at least for vagrant up, halt and status.
Adding to that, I've just upgraded to Fusion 12 Pro (for some extra features), and with that version VMWare Utility 1.0.11 and vagrant-vmware-desktop 2.1.2 (both at their latest versions) work fine. This suggests a regression with non-Pro Fusion.
@stolowski I'm using the latest VMWare Utility and simply downgraded to vagrant-vmware-desktop 2.1.0 to get vagrant up working. A regression with non-Pro fusion would be very misleading by HashiCorp because the page states that:
Do I need VMware Fusion/Workstation Pro or just the regular version?
The Vagrant VMware plugin is compatible with both the regular and Pro versions of VMware Fusion and VMware Workstation. However, some advanced features (such as linked clones), are only supported by the Pro versions of the VMware software.
Wouldn't consider vagrant up an advanced feature. 😄
New to this plugin, was hoping for a faster alternative to VirtualBox. In various combinations of Fusion 12 Pro, Vagrant, Vagrant VMware Utility and vagrant-vmware-desktop and after many wasted hours all I get is either
failure encountered: Command is not supported by Fusion standard license version
or
Failed to create new device
And not a peep from the provider in this issue for a whole month. Is this really paid software?
Sadly experiencing the same issue after upgrading to VMware Fusion 12 (and after having paid for a new vagrant vmware-12 license). This is not good enough.
For reference, to downgrade:
vagrant plugin install --plugin-version 2.1.0 vagrant-vmware-desktopI would strongly recommend everyone with this issue email support, [email protected], as this is a paid for product it comes with support (which isn't been given here) so this would be the best way to get some light on things.
@ajbonner Already done. Have you received any support on this issue yet?
I sent my support email on Sep 8 and only got this auto-response:
Vagrant support is best effort and we will respond to your request as soon as possible. Please refrain from logging additional tickets
I sent my support email on Sep 8 and only got this auto-response:
Vagrant support is best effort and we will respond to your request as soon as possible. Please refrain from logging additional tickets
Oh dear that's really not good enough. I submitted mine today to make sure was doing the 'right thing' Every other day have been tweeting at https://twitter.com/mitchellh. Ironically who himself tweeted about reaching 1000 employees. Hopefully one of them can look at this problem, as I sincerely hope their other paying customers get better support than vagrant vmware ones are.
This is all totally unacceptable and agree 100% w/ @ajbonner that other paying customers for other products hopefully get better support. The fact is that I am sure that I am not the only one who has over the years JUST accepted that there were/are issues with Vagrant and VMware. And more specifically on macOS.
Tweeted @mitchellh. This makes we worry about the release of Big Sur as I have not found a solution to make Vagrant work at all in the Beta. VirtualBox just crashes and relies on kernel extensions which are not allowed in MacOS 11. Parallels advertises their product as Big Sur ready but it leaves you with VMs without network connection. Joined you guys – seems like this product has been having issues for years. Any alternatives I might not know about?
Hi everyone,
First, I would just like to offer my apologies. The root cause of this issue is something I introduced with some new work to stabilize and optimize network interactions with VMware. Controlling VMware's networking has always been a bit tricky, but new tooling has made it easier. However, it seems as though that tooling is unavailable in standard versions and it was not caught during development.
I missed this issue when it was originally posted and some external circumstances have made it difficult catching up on my backlog. I understand the frustration when a tool doesn't work properly and reports of the failure are met with radio silence. Support for the plugin is "best effort", but that best effort should not be met with an extended delay or no response at all. I'm investigating why this has happened to ensure we are getting properly notified of issues (especially breaking issues) in a timely manner. Again, I'm very sorry to everyone that has been encountering this issue without a proper resolution.
I am investigating a fix for this issue and will be implementing it and getting it released today. It will likely be closer to end of day today (PDT) but once it has been released I will update this issue to let everyone know.
Thank you so much, @chrisroberts. The comments above describe different combinations of Fusion plans. Can we expect this plugin to work the free version of Fusion? As far as I can read, there's no statement that this plugin is limited to Fusion Pro licenses on the product page.
Thank you @chrisroberts, really appreciate you explaining things. Look forward to the fix, but mainly just happy it's being looked at. 👍
Just wanted to leave a status note on this. I have a working implementation completed and am wrapping up the last of the test coverage. It should be completed and ready for release in the morning.
Thanks for everyone's patience. The behavior is a bit different across platforms and there were a few other things that needed to be addressed. The updates have been released for both the Vagrant VMware plugin (v2.1.3) and the Vagrant VMware utility (v1.0.12). Upgrading to the latest plugin and utility will provide proper detection and prevent usage of tooling that's not available due to VMware license type.
Again, my apologies for the duration of this breakage. If there are any issues, please let me know.
Cheers!
Thanks for everyone's patience. The behavior is a bit different across platforms and there were a few other things that needed to be addressed. The updates have been released for both the Vagrant VMware plugin (v2.1.3) and the Vagrant VMware utility (v1.0.12). Upgrading to the latest plugin and utility will provide proper detection and prevent usage of tooling that's not available due to VMware license type.
Again, my apologies for the duration of this breakage. If there are any issues, please let me know.
Cheers!
@chrisroberts I finally had a chance to sit down and update the Vagrant VMware plugin and Vagrant VMware plugin to the versions noted here, and I am still having the same problem as before:
failure encountered: Command is not supported by Fusion standard license version
I did follow others suggestions and downgraded to plugin version 2.1.0 and utility versions 1.0.9 and that works as expected. When I then upgrade back to versions 2.1.3 and 1.0.12, I received the error about the license once again.
I have reinstalled VMware Fusion 12 - Professional Version 12.0.0 (16880131) - with the same result. Originally I was using VMware Fusion 11.5.6 - the non-Pro version - does that make a difference somehow? Note, I also upgraded to the latest Vagrant VMware utility version as well (purchased a new license), so I should have all the current licenses needed (both from a VMware and Vagrant perspective).
Do I need to uninstall and reinstall everything in order for these updates to work? Is there some additional log information I can provided or some other tweak I can do to try and help diagnose this issue? My original debug output (first post) is still valid, though with newer version numbers -- the utility is claiming it cannot process this command:
DEBUG vagrant_utility: request METHOD=GET PATH=/vmnet RESPONSE=400 ERROR=failure encountered: Command is not supported by Fusion standard license version
failure encountered: Command is not supported by Fusion standard license version
on MacOS 11 Beta 7, VMware Fusion 12 Pro, Vagrant VMware plugin 2.1.3 and Vagrant VMware utility 1.0.12.
Question @chrisroberts : Is this version supposed to be Big Sur ready I should I just stop testing at this point?
Confirmed that this is still not working:
$ vagrant version
Installed Version: 2.2.10
Latest Version: 2.2.10
You're running an up-to-date version of Vagrant!
$ vagrant plugin list|grep -A 1 vmware-desktop
vagrant-vmware-desktop (2.1.3, global)
- Version Constraint: > 0
$ /opt/vagrant-vmware-desktop/bin/vagrant-vmware-utility --version
1.0.12
$ cat /Library/Preferences/VMware\ Fusion/license-fusion-120-e10-202001|grep -E "^(ProductID|LicenseVersion|LicenseEdition)"
ProductID = "VMware Fusion for Mac OS"
LicenseVersion = "12.0"
LicenseEdition = "fusion.ws.pro.vl"
$sw_vers -productVersion
10.15.6
$ vagrant up
An error was encountered while generating the current list of
available VMware adapaters in use on this system.
failure encountered: Command is not supported by Fusion standard license version
Please resolve any problems reported in the error message above and
try again.
Also ... "adapaters" ----^
The license edition you are showing here isn't matching what I found when installing the standard license vs pro. I'm running some more installations and applying different licenses to determine where the differences are located. Also, since I seem to be finding some inconsistency within the license edition values for checks, I'm adding in a validation check on accessibility of networking related functionality on setup with automatic fallback as well as a configuration option that can be used for force a specific behavior despite local detection.
Exact same as @zestysoft here:
$ vagrant version
Installed Version: 2.2.10
Latest Version: 2.2.10
You're running an up-to-date version of Vagrant!
$ vagrant plugin list|grep -A 1 vmware-desktop
vagrant-vmware-desktop (2.1.3, global)
- Version Constraint: > 0
$ /opt/vagrant-vmware-desktop/bin/vagrant-vmware-utility --version
1.0.12
$ cat /Library/Preferences/VMware\ Fusion/license-fusion-120-e10-202001|grep -E "^(ProductID|LicenseVersion|LicenseEdition)"
ProductID = "VMware Fusion for Mac OS"
LicenseVersion = "12.0"
LicenseEdition = "fusion.ws.pro.vl"
$ sw_vers -productVersion
10.15.7
@chrisroberts - thanks for doing what you do. Digging into VMware internals after each new release looks pretty hairy and we're lucky to have someone who works diligently to support it with Vagrant. Your work is really appreciated 🙏
Hello again everyone! Hopefully this will be the last time we'll need to be here in this issue :smiley:
The license detection addition was validating against LicenseEdition values, but with the most recent release of Fusion and Workstation combined with the cross platform compatible license move they made with this release ended up breaking the check. A new utility package has been released today which includes an updated detection check to properly match on these new values. Since the advanced networking functions are not available on the standard license, if the utility is unable to access them, it will downgrade the detected license to "standard" automatically to ensure things work as expected.
This version of the utility has also added support for a configuration file to make it easier to control the behavior of the utility. A new configuration option has also been added to the utility -license-override which will allow forcing the desired behavior of the utility regardless of the VMware license it may detect. This means that if the utility is mistakenly detecting a standard license, you can force it to behave as if it had detected a professional license:
api {
license_override = "professional"
}
Likewise, you can force it to behave as though it detected a standard license:
api {
license_override = "standard"
}
The utility configuration is documented here: https://www.vagrantup.com/docs/providers/vmware/vagrant-vmware-utility#utility-service-configuration
I'm going to close this issue as it should be resolved at this point, but if anyone runs into issues with the new plugin and utility, please drop a note here and I will re-open this and investigate.
Cheers!
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Hi everyone,
First, I would just like to offer my apologies. The root cause of this issue is something I introduced with some new work to stabilize and optimize network interactions with VMware. Controlling VMware's networking has always been a bit tricky, but new tooling has made it easier. However, it seems as though that tooling is unavailable in standard versions and it was not caught during development.
I missed this issue when it was originally posted and some external circumstances have made it difficult catching up on my backlog. I understand the frustration when a tool doesn't work properly and reports of the failure are met with radio silence. Support for the plugin is "best effort", but that best effort should not be met with an extended delay or no response at all. I'm investigating why this has happened to ensure we are getting properly notified of issues (especially breaking issues) in a timely manner. Again, I'm very sorry to everyone that has been encountering this issue without a proper resolution.
I am investigating a fix for this issue and will be implementing it and getting it released today. It will likely be closer to end of day today (PDT) but once it has been released I will update this issue to let everyone know.