virtualbox.org

We forgot to mention an important new feature of VirtualBox 5.0 in the changelog: The separate GUI mode. Just try it out:

• Start a VM from the command line like this:

  Code: Select all

  VirtualBox --startvm VM_NAME --separate

• Open the Close VM dialog
• Select Continue running in the background and press OK

The GUI process is now terminated but the VM process continues running. To re-attach to such a running VM, do

• Code: Select all

  VirtualBox --startvm VM_NAME --separate

as you did before and there will be a new GUI process attached to the VM process.

Q Why is this mode not default?
A It causes some performance impact for graphics output. In fact there is a VBoxHeadless VM process in the background and the GUI process. For graphics output both need to communicate. 2D acceleration does not work currently. 3D acceleration might not work, it depends on the host and how the VM process was started i.e. as headless or as separate from the GUI.

Q Why do I need to specify command line parameters, is there no GUI function?
A to be implemented.

Detach a running machine would improve a lot my vbox usage. Thanks!

However, I really don't get why the --separate is needed in machine startvm.

If a user can:
1) start a vm without separate
2) close vm saving its state
3) restore vm with separate
4) close leaving it running
4.1) vm is detached

VBox has all needed resources to:

1) start a vm without separate
2) close vm asking to leave it running
2.1) vbox enable "separate"
2.2) vm is detached

Enabling "separate" using saving/restore already works. It is not ideal but it is better than nothing. I've being using this to convert headless2gui or gui2headless for years. If the "separate activation" could skip the save/restore step (just pause the machine and keep it in memory), I guess that the downtime, if needed, would be neglectable.

From what I understand, "separate" is actually simply a headless VM (with a optional gui client). I can even attach to a headless VM started without any --separate option. I understand that the client-gui/server-headless comm introduces overhead. However, if there is a fast way to do what a "save gui/restore as headless" does, simply convert the machine to headless/gui as needed and avoid any overhead.

For example:
a) when a gui vm is closed, if selected "leave it running", convert to headless vm
b) when a headless vm is doubleclicked on gui, covert it to gui vm

Also, "ask to attach to a running VM" using "startvm" arg is really confusing. Start a VM but no?
I would add:

VBoxManage attachvm xxxx (convert a headless vm to gui vm)
VBoxManage detachvm xxxx (convert a gui vm to headless vm)

If overhead is solved, I guess there is no need to add a special attach to Virtualbox, as its usage would be on GUI. CUI is for VboxManage.

BTW, I can attach a VM twice . The result is that video on the first VM is frozen until second "session" is closed, but every other input/change is kept working. Seems like a bug.

Can performance of this detachable VM be improved in the future somehow ? (at least theoretically)

luizluca, you are right that the "separate" mode means that the VM runs as VBoxHeadless process and the GUI client can attach to it. The "-separate" command line parameter tells the GUI to launch such VM process rather than initialize the VM in the GUI process.

I think that converting a GUI VM process to a headless will require save/load state in some form anyway, because the GUI process must be stopped and new headless started. However there might be some shortcuts and optimizations for this case to improve performance.

The user interface for this feature is not yet fully implemented and you suggestions are right. We have similar ideas.

Yes, it is possible to attach twice, it is a known bug.

Technologov wrote:Can performance of this detachable VM be improved in the future somehow ? (at least theoretically)

Yes. However it is difficult to estimate how much.

is this client/server, i.e. can i start a headless instance on my main machine and connect to the gui from another machine (without x11 forwarding over ssh or running rdp in the guest) ?