3 ms·

Personal anecdote: They came after us, since the extension phones home and they could track it to our ASN. Asked us for an audit of all installs of VB. The idea

by chomp 8y ago

Personal anecdote: They came after us, since the extension phones home and they could track it to our ASN. Asked us for an audit of all installs of VB. The idea was that they wanted to then charge us big money for a corporate license. Instead, IT banned it enterprise-wide. Which is sad, because we like it for Vagrant. We've since started moving all of our developer stuff to OpenShift, so we're not totally up a creek.

arminiusreturns 8y ago
I have a devops guy trying to push me to use Vagrant at the moment, but I am aware of these issues with virtualbox. I was thinking about using one of the lxc shims, but now you have me curious, how useful is openshift in that "I want to spin local vms up for testing" approach? I thought it was much more geared to server and not workstation, as opposed to vagrant. Of course others are right, virt-manager is probably a better replacement I think.
- chomp 8y ago
  So OpenShift (or OKD) is just Redhat's Kubernetes platform. If your dev team isn't already in a docker-like workflow, it's going to be a hard sell. I've found many devops-y people love to be able to SSH into the environment to change code as it runs, and that's not possible with an environment like this. You can spin up KVMs in OpenShift, but I have the feeling it's not going to be quite what you're looking for. I suppose it's all going to be a matter of what workflow is most comfortable for your devops people. If you have an OpenStack install, Vagrant can control those AND they can login and poke around. Also FYI virt-manager is deprecated in RHEL 8, and is superceded by Cockpit.
- nullify88 8y ago
  Out of curiosity, what feature in the extension pack are you using with Vagrant?
  - arminiusreturns 8y ago
    PXE booting mostly.
  - setquk 8y ago
    USB pass through support to drive hardware debuggers here.
plq 8y ago
Why not use KVM via vagrant-libvirt? It's pretty easy to set up and works like a charm. See https://news.ycombinator.com/item?id=18727059 https://news.ycombinator.com/item?id=18727059
- chomp 8y ago
  So one problem with that is not all of our team uses Linux, we're a Mac/Linux hybrid team. Our workflow was to edit the puppet manifests locally and then Vagrant up, and we wanted something that would work across different dev machines. However, the fussiness of environment setup started to go higher the further we got from VBox; our team didn't really want to invest time into a workflow that was supposed to be an intermediate step to our "end game" development pipeline, so we just left it. Thanks for the link though!
  - ergo14 8y ago
    You can have mixed provider vagrant files.
lambda 8y ago
Oh, wow. They've also changed the license a couple of times in 2016 and 2017 to make it more restrictive. Early 2016: https://web.archive.org/web/20160411070811/https://www.virtualbox.org/wiki/VirtualBox_PUEL https://web.archive.org/web/20160411070811/https://www.virtu... Late 2016: https://web.archive.org/web/20161208112443/https://www.virtualbox.org/wiki/VirtualBox_PUEL https://web.archive.org/web/20161208112443/https://www.virtu... Current, last changed July 2017: https://www.virtualbox.org/wiki/VirtualBox_PUEL https://www.virtualbox.org/wiki/VirtualBox_PUEL In the earlier licenses, "personal use" was just defined as the person using it being the same person as who installed it, and only one person remotely accessing the desktop at a time. So I had interpreted this as being OK for developer VMs in which the developer installs it themselves and uses it for their own development purposes. It also contained an "evaluation use" with a vaguely defined period. The current license now defines "personal use" as explicitly non-commercial use, and adds more restrictions on client access that applies to any type of clients and not just remote desktop access, as well as explicitly defining the evaluation use period to being 30 days. So while I didn't really have a concern about developers using VirtualBox with the extension pack previously, given the new license and the fact that they seem to be enforcing it via phoning home, it looks like it's time to set a policy of no one using it. Luckily, we've already pretty much transitioned everything over to libvirt/KVM on Linux hosts, and people have generally been using VMWare or VMWare Fusion on Windows and Mac hosts.

by chomp 8y ago

arminiusreturns 8y ago

I have a devops guy trying to push me to use Vagrant at the moment, but I am aware of these issues with virtualbox. I was thinking about using one of the lxc shims, but now you have me curious, how useful is openshift in that "I want to spin local vms up for testing" approach? I thought it was much more geared to server and not workstation, as opposed to vagrant. Of course others are right, virt-manager is probably a better replacement I think.

chomp 8y ago
So OpenShift (or OKD) is just Redhat's Kubernetes platform. If your dev team isn't already in a docker-like workflow, it's going to be a hard sell. I've found many devops-y people love to be able to SSH into the environment to change code as it runs, and that's not possible with an environment like this. You can spin up KVMs in OpenShift, but I have the feeling it's not going to be quite what you're looking for. I suppose it's all going to be a matter of what workflow is most comfortable for your devops people. If you have an OpenStack install, Vagrant can control those AND they can login and poke around. Also FYI virt-manager is deprecated in RHEL 8, and is superceded by Cockpit.
nullify88 8y ago
Out of curiosity, what feature in the extension pack are you using with Vagrant?
- arminiusreturns 8y ago
  PXE booting mostly.
- setquk 8y ago
  USB pass through support to drive hardware debuggers here.

plq 8y ago

Why not use KVM via vagrant-libvirt? It's pretty easy to set up and works like a charm. See https://news.ycombinator.com/item?id=18727059 https://news.ycombinator.com/item?id=18727059

chomp 8y ago
So one problem with that is not all of our team uses Linux, we're a Mac/Linux hybrid team. Our workflow was to edit the puppet manifests locally and then Vagrant up, and we wanted something that would work across different dev machines. However, the fussiness of environment setup started to go higher the further we got from VBox; our team didn't really want to invest time into a workflow that was supposed to be an intermediate step to our "end game" development pipeline, so we just left it. Thanks for the link though!
- ergo14 8y ago
  You can have mixed provider vagrant files.

lambda 8y ago

Oh, wow. They've also changed the license a couple of times in 2016 and 2017 to make it more restrictive. Early 2016: https://web.archive.org/web/20160411070811/https://www.virtualbox.org/wiki/VirtualBox_PUEL https://web.archive.org/web/20160411070811/https://www.virtu... Late 2016: https://web.archive.org/web/20161208112443/https://www.virtualbox.org/wiki/VirtualBox_PUEL https://web.archive.org/web/20161208112443/https://www.virtu... Current, last changed July 2017: https://www.virtualbox.org/wiki/VirtualBox_PUEL https://www.virtualbox.org/wiki/VirtualBox_PUEL In the earlier licenses, "personal use" was just defined as the person using it being the same person as who installed it, and only one person remotely accessing the desktop at a time. So I had interpreted this as being OK for developer VMs in which the developer installs it themselves and uses it for their own development purposes. It also contained an "evaluation use" with a vaguely defined period. The current license now defines "personal use" as explicitly non-commercial use, and adds more restrictions on client access that applies to any type of clients and not just remote desktop access, as well as explicitly defining the evaluation use period to being 30 days. So while I didn't really have a concern about developers using VirtualBox with the extension pack previously, given the new license and the fact that they seem to be enforcing it via phoning home, it looks like it's time to set a policy of no one using it. Luckily, we've already pretty much transitioned everything over to libvirt/KVM on Linux hosts, and people have generally been using VMWare or VMWare Fusion on Windows and Mac hosts.