-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Virtualbox support (deprecated) #838
Comments
Re-opening as implementation needs to be removed from machine |
Sounds like a fair bit of rational, objective reasoning. Of course, it doesn't hurt that VirtualBox is an Oracle product as I'm not the only one who sees what isn't being said and what has been done in other venues. Even if this wasn't supported, leaving the documentation alive for those interested would have been more open than striking everything but the GitHub artifacts from existence. |
The vbox-related code paths have been removed from the codebase, so there is nothing that can be documented, virtualbox support has been removed. |
Very poor decision .. Hyper-V is poor to use on a laptop etc compared to Virtual box ( or vmware etc ) . Also it would be nice if CRC actually worked on a virtual box VM for those of use who cannot run Hyper-V on their laptops ... |
Can you be more specific about hyper-v issues compared to vbox/vmware/...? |
I prefer Virtual box to Hyper-v as I want a simple lightweight virtualisation tool that works for development and experimentation .. I do not want to waste my time learning how to use Hyper-V and the crap that goes with it when there are simpler solutions available that do what I need .. Hyper-V may be a great go-to solution for the data centre but that is not what I am trying to achieve on my laptop ... The other lovely "Feature" of Hyper-V is when you use it on laptops that regularly switch between using a physical network cable and Wifi like I do ... Have fun with that.,.. And of course being forced to install Hyper-V means yet more MS bloat-ware that goes with Hyper-V I have to install and manage on my laptop . (And yes I would prefer to run Linux on my laptop but I have to use Windoze due to yet other S/W compatibility issues ). Of course if CRC ( Which is a very nice cool tool ) worked on a RHEL VM running under virtual box then I would not need to install CRC under windows and the Hyper-v junk that goes with it... I would just run it on the RHEL VM... additionally I would also like to be able to run the Docker desktop in parallel to CRC and a vm solution would allow that ... Maybe a solution could be to provide crc as an appliance in something like OVF format that could be imported and run on your virtualisation solution of choice ? |
This seems to be more motivated by preference than a technical limitation.
A cloud image is something that might be possible, but is not worked on at
the moment.
The issue is that CRC is still needed to prepare the cluster by injecting
the pull-secret, and some other settings, before we start the kubelet
service.
Perhaps it is a better suggestion to run your own single node installation
according to the setup as in the snc repo.
note: we deprecated VirtualBox for the poor support and the issue we
encountered, timing related, etc. Plus the fact that we can not test
multiple hypervisors as we have limited test resources.
…On Mon, May 30, 2022 at 12:32 PM rob-4x4 ***@***.***> wrote:
Can you be more specific about hyper-v issues compared to vbox/vmware/...?
I prefer Virtual box to Hyper-v as I want a simple lightweight
virtualisation tool that works for development and experimentation .. I do
not want to waste my time learning how to use Hyper-V and the crap that
goes with it when there are simpler solutions available that do what I need
.. Hyper-V may be a great go-to solution for the data centre but that is
not what I am trying to achieve on my laptop ...
And of course being forced to install Hyper-V means yet more MS bloat-ware
that goes with Hyper-V I have to install and manage on my laptop . (And yes
I would prefer to run Linux on my laptop but I have to use Windoze due to
yet other S/W compatibility issues ).
Of course if CRC ( Which is a very nice cool tool ) worked on a RHEL VM
running under virtual box then I would not need to install CRC under
windows and the Hyper-v junk that goes with it... I would just run it on
the RHEL VM... additionally I would also like to be able to run the Docker
desktop in parallel to CRC and a vm solution would allow that ...
Maybe a solution could be to provide crc as an appliance in something like
OVF format that could be imported and run on your virtualisation solution
of choice ?
—
Reply to this email directly, view it on GitHub
<#838 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAOZXKEH53X5LW7SMGKHTVMRAFZANCNFSM4JRHXIEQ>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
--
Gerard Braad | http://gbraad.nl
STEM is the source, but BUILD is how you develop!
[ Better Understanding Involves Learning and Doing ]
|
Our tests have concluded that native virtualization is easier to deal with in setting up, we even automate this as much as possible, On an aside, they also consume less resources. Mostly due to the fact they are tailored towards the host platform.
However, VirtualBox on Windows and macOS as driver were provided for certain situation where policies prevent the user from self-admin, etc. Windows users for example are often confronted by the restriction that a virtualization suite has been chosen by the other tools they use or by the administrative team. This is less likely on Linux. Due to the ease of use and streamlining the out of the box experience, we have been focussed to pursue native solutions foremost.
While CRC provided a driver for VirtualBox, this was an unsupported and mostly untested driver. We have received positive results from users during the alpha and beta testing period. We have included the driver for those who are willing to tinker when a native hypervisor is unavailable, such as due to company restrictions and/or policies. But be aware, from our own tests we conclude that VirtualBox overall consumes more memory and is slower in use than the native options we provide.
Although, we do not prevent people to add the needed drivers and support, we really do not have the resources and time on our schedule to handle more platforms and hypervisor combinations. We have learned from dealing with Minikube and Minishift and decided to not support these drivers from a basic installation. Take note, nothing prevents outside contributors to add support. But note, 'supported' means more than just adding the setup and driver code, but also being able to run regular tests, integration ... And this is what we talk about here.
Therefore, we have decided to remove the VirtualBox support from our codebase. Starting with v1.2.0 we showed a deprecation notice and for v1.3.0 we have planned to remove the driver implementation. This means we will also not publish VirtualBox image bundles.
— CRC Team
Note: in case of another hypervisor, VirtualBox will default to use full system virtualization (using the emulation backend) as it does not have access to hypercalls. be aware, that when WSL2 is enabled in future (or from Insider) you are unable to use VirtualBox in that case.
The text was updated successfully, but these errors were encountered: