[Pkg-virtualbox-devel] Bug#794466: VirtualBox removal impact on Debian work

[Ritesh Raj Sarraf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello Daniel,

On Thu, 2017-01-19 at 09:23 +0100, Daniel Pocock wrote:
> I use VirtualBox on stable (currently jessie) as part of my strategy for
> testing anything that will run in future Debian releases (e.g. stretch).
>  It has been extremely useful for this purpose in the past.
> 
> How many other developers are working this way, either with VirtualBox
> or one of the alternatives?
> 

Used to use/maintain VBox. But moved away after Oracle's attitude towards it.
Pretty happy with KVM/Libvirt right now.

> I recently did a trial of the stretch installer into a Virtualbox VM
> (host running jessie) and ran into trouble getting the graphical
> desktop, it is discussed in bug 851124[1].  Even if Virtualbox won't
> continue being available, it would be helpful to other developers and
> testers to find ways to make them aware of such things before they lose
> any time on it.
> 

And how do you propose doing that ?
I'm interested to know because I maintain many packages, usually used in the
enterprises, for which I'd only get user testing and bug reports, after the next
stable release. By then, it is already late.

The best I've doing is to handpick users and email them to do some early
testing. Also, blogging sometimes helps. But I'm sure, I'm only reaching a minor
subset of the actual users.

> It would also be helpful to have a summary on the wiki about some of the
> points raised already in the thread:
> 

Yes. Would be nice to see that. But creating a wiki means, maintaining its
status. On the other hand, the bug report usually serves as a live status of the
issue.

> - whether or not it will be available as a backport (I was able to run
> the sid packages in my stretch VM without rebuilding or modifying them)
> 
> - a cheat sheet or conversion guide for the next best thing, whatever
> that is, e.g. KVM
> 

Hmmm. Mostly what you want is to convert .vbox image into something that qemu
understands. For the rest of the stuff, like Guest VM setting attributes, I
don't think there's a straight way to do it.

> Given the convenience of Virtualbox, many users may not have been
> tempted to explore KVM or other desktop virtualization solutions before
> so it could be helpful to write a quick summary of how it really
> compares to the Virtualbox package.  In particular:
> 
> - are graphics features and performance equivalent, better or worse?

Someone needs to do it. And I'd still think that such result (on performance)
won't be comprehensive.

On the features side, yes, it'd be nice to have. VBox really enjoys in the UI
front.
Other than that, KVM has a better edge.

* In-kernel hypervisor. No frequent breakages with newer kernels
* In-kernel hypervisor. Doesn't need external modules (dkms pacakges) to be
built.
* Very good performance with Guest VMs that support Para-Virtualized drivers for
block and net (and maybe graphics too now). For non-para-virtualized guest OS,
performance could suck.
* VBox has a lot better UI than libvirt. But libvirt is much nicer to manager
remote hypervisors.


> I've tried setting up KVM once with the pass-through VGA and it never
> worked, although that may have been a chipset limitation.  I also
> recently introduced the virglrenderer[2] for qemu into Debian.  Those
> are both things that Virtualbox doesn't support but they are only useful
> to people with the right hardware.  For people without the right
> hardware, falling back to a remote-desktop protocol might be a serious
> limitation, virtio-gpu might be better but it is not clear that this
> will work for a jessie host or even a stretch host just yet:
> https://www.kraxel.org/blog/tag/virtio-gpu/
> The fact that VirtualBox offers a strong desktop graphics solution is
> probably one key reason some people may want to stay on Virtualbox, at
> least until the KVM / qemu solutions work more effortlessly.
> 


> - how does CPU performance compare, e.g. speed, impact on the host?
> 

It is the same, in my opinion. Without the vbox-guest-dkms package, the Guest
VMs run under Full virtualization, and inherit its performance bottlenecks.

> - how convenient is it to do the basic things that most people do with
> the Virtualbox GUI?  For me, those basic things are typically attaching
> and detaching VDI and ISO images and tweaking the network from NAT to
> bridge.
> 

Things are simple in libvirt too. But vbox does have a cleaner UI.

> - what is the impact of migration on guest operating systems that are
> sensitive to perceived hardware change, e.g. for each Windows version?
> 

I don't know. Last I used was with Windows 7. And it was sensitive.

> Having some of these things in one place could help people get on with
> other things they are testing.
> 
> Regards,
> 
> Daniel
> 
> 
> 
> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851124
> 2. https://virgil3d.github.io/
> 
- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAliCDdkACgkQpjpYo/Lh
dWn6Hw//YjubU3WC7DMTxTmFIdf5tcTnS8XSFg0dXU+aYLukiw/Edk7QgnwNScLs
Zx2dQZ3OABmpWOSYxkmhvhjqWRnqeRnsNxifGC7a3WwlVyxuG/uugspAPsqBPrgm
gamnNtooOqL7eg0ri4no9VhP3moEIEidMUUzj+TetA+EmP2XpjMdK1n49I5E00p1
0hZh9hrBEiGbFo/2bmh7av/XUrQgKtGSP3dPz/6HiMqwXu9bKyeEE+HMNcX+1Y9P
nzqFsDSGI7CJCFtBt487pqwz7BXXDe6EAfzCe2p1p2yF4Xg+uXcuLut24nMEHJ3t
3U8dV47npPZ7pRN84J/whH8lmcLVZgQzXyty8hbXFVWVwcQQZLc0Z4S+8Uw+9wvM
Ut5XezMxAlVe0fMQJ6tpGPCRo2u/PG99snGXz9jpIxzxJofalf2j1DVz3MZnMV27
cyfkEmXQASO/LEhus+oZ/XGIUsFlTf+ffLnLrmBDf+d6SCT0r+SkvjVvVdhkTHIM
kXnX++vc5psB2ncK7zv/HcSmtgOU1wW2GWgjlYVsK/QdO49ACjrXr6ypUn9DayRB
rnB3dGnGXcTIs0H08RtnggWTeDe6B3lewOahOoQiVTU1qGsQdKxhcnP4vBmbv0bv
TaH5rFnonSPlkBuTdsfin434+tMP2J0Iuo/AQQaB3ufaiZb1vjw=
=IyWE
-----END PGP SIGNATURE-----