[Solved] Install VirtualBox or Virt-Manager

[sunrat]

virt-manager is a front-end manager. It manages qemu-kvm although optionally it can manage Xen.

I found a nice simple tutorial here - https://i12bretro.github.io/tutorials/0470.html
and related video - https://www.youtube.com/watch?v=u_tsCfi7HMY

There are dozens of tutorials and videos on the internet but most of them are more involved than these, explaining optional and not-so basic features.
This one may be helpful as it explains a few other things - https://www.how2shout.com/linux/how-to- ... eye-linux/

[pwzhangzz]

Since OP is already familiar with Arch, it is probably a no-brainer to opt for qemu-kvm (& I'm all for it!). However, just a few weeks ago Cyberus Technology announced an open-source release of a KVM back-end developed for VirtualBox. It "allows VirtualBox to run virtual machines utilizing the Linux KVM hypervisor instead of the custom kernel module used by standard VirtualBox":

https://github.com/cyberus-technology/virtualbox-kvm

In addition to improved performance, the use of KVM back-end also dispenses with the need for VirtualBox kernel driver. (The latter is a major pain if you regularly update your Linux kernel--just ask Nvidia card owners. )

[limotux]

Thanks a lot @sunrat
The tutorial you provided looks really interesting.
I hope it will solve the issues I mentioned in my previous post.

All what I did was simply installing virt-manager only, and I did no more of the commands shown in the tutorial. May be this is why I had the issues I mentioned. What you think?
I will give it another try.

Thanks as well @pwzhangzz
I will look at KVM after I get first virt-manager up and running.

[pwzhangzz]

Thanks to Debian developers (!!!), running qemu/kvm has indeed become very straightforward (!!!). All you need to do is executing the following command:

Code: Select all

sudo apt update && sudo apt install qemu-system-x86 libvirt-daemon-system libvirt-clients bridge-utils virt-manager

Then add yourself to the libvirt and kvm groups:

Code: Select all

sudo adduser $USER libvirt
sudo adduser $USER kvm

Voila! you are ready to start the virt-manager and create, or import, your own linux.qcow2 vm. Unlike VirtualBox, you don't need to restart your machine but you may need to re-login or run the newgrp command so the group change will take effect. Thus you also need to execute:

Code: Select all

newgrp libvirt
newgrp kvm

to complete the install.

Debian's qemu/kvm package includes very adequate default options for you to "capably" get started. But when you start to modify your virt-manager settings (including editing the xml file), please share your experience with us (or at least with me).

[CwF]

As with everything Linux the target is moving and evolving. The group membership isn't so necessary anymore, but a safe bet. Most of libvirt authority has matured to be within the polkit mechanism. I have used the libvirt group for storage pool group rights in the past and also isn't really necessary. Technically speaking, kvm may not even exist. If you stay within x86 linux vm's then no *kvm* packages are needed.

I recommended only qemu-system-x86 and virt-manager above for a minimal install. This minimum has been working on recent 'nested' testing I've done. My own test sometimes miss details since I may be familiar, do a tweak, add something and then forget to take the note. There are a few areas I'd been looking at and remote access was the focus, so groups, storage pools, minimal packaging, polkit only were under review.

So, depending on use case, install order, base install variations, my last test was:
+virt-manager(+26)+qemu-system-x86(+21)+qemu-utils(+1)+libvirt-daemon-system(+9)
that's the package (and the additional dependencies w/o recommends)

That test was to group vm's with a single base. From a single clone, the .9GB host with a 1.1GB backing and multiple static and dynamic second layers for each vm instance - all within one nested 'thing'. I needed to take some time to arrange network naming for the variations, and test performance of L2 vm's accessed remotely - seems fine. Yes, massive overhead...

As mentioned in post9, I don't use bridges and macvtaps do not require bridge-utils, so I no longer include that package. A quick check, I use no *kvm* packages at all.

After that, for remote control I needed +netcat-openbsd+dnsmasq(+1)+libnftables1. iptables was installed, and may no longer be needed, not sure.

[fabien]

A quick check, I use no *kvm* packages at all.

In fact, there are no *kvm* packages . qemu-kvm is a virtual package since Bullseye (provided by qemu-system-x86), on Buster it already just was a wrapper script which ran qemu-system-x86 in kvm mode for backwards compatibility.

iptables was installed, and may no longer be needed, not sure.

iptables is still a dependency of libvirt-daemon-system, even on Sid.

[CwF]

iptables is still a dependency of libvirt-daemon-system, even on Sid.

Thanks for the check, it's cloudy today!

[limotux]

I tried but got this:

Code: Select all

root@HPdebian:/home/limo# sudo apt install qemu qemu-kvm qemu-system qemu-utils -y
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'qemu-system-x86' instead of 'qemu-kvm'
Package qemu is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

[fabien]

Just install virt-manager, it will install all that is needed.

[limotux]

Just install virt-manager, it will install all that is needed.

Thanks @fabien
I did before install virt-manager, but as in previous post it didn't go well.
And just installing virt-manager is a bit different from the steps in the simple tutorial at https://i12bretro.github.io/tutorials/0470.html that @sunrat posted.

I tried to follow this tutorial, maybe it didn't work well with me because I was missing something.

I am trying to stick to what Debian developers see better for Debian and not install VirtualBox (I tried VirtualBox before and everything just worked).

I hope I can find a way to do it.

[CwF]

root@HPdebian:/home/limo# sudo apt install qemu qemu-kvm qemu-system qemu-utils -y

There are a lot of why's in that reported failure ! ?
I gave the formula I actually just used:

+virt-manager(+26)+qemu-system-x86(+21)+qemu-utils(+1)+libvirt-daemon-system(+9)

So convert that to an apt install line:

Code: Select all

#  apt install virt-manager qemu-system-x86 qemu-utils libvirt-daemon-system

virt-manager alone will not pull in the packages to host a local vm.

qemu-utils is useful but not integral to using virt-manager. The other two are for local vm's.

[limotux]

Thanks @CwF
I just did

Code: Select all

sudo apt-get clean && sudo apt update && sudo apt upgrade && sudo apt-get dist-upgrade && sudo apt-get full-upgrade && sudo apt autoremove --purge -y

just to be sure, then

Code: Select all

apt install virt-manager qemu-system-x86 qemu-utils libvirt-daemon-system

Appears to me everything installed correctly.
Launched virt-manager. OK.
I will report back to you how it goes with of my virtual Debian, I will install from the .iso file.
Thank you all.
Just to be sure, do I need to add user to any group, play with whatever permissions?

[CwF]

Appears to me everything installed correctly.

Good

Just to be sure, do I need to add user to any group, play with whatever permissions?

Well I did lay that out above and my current answer is no. If you have user rights through polkit it will work without 'group rights' Understand polkit vs. groups are parallel methods not competing, one old, one new. If you choose to run with the herd, then we'll jump to a new topic:
viewtopic.php?p=794993#p794993
Read the thread through, that method will grant all the rights you need. We'll tackle exceptions (kde?) as we go...

Well, I should comment more now that I'm thinking about it...

Virt-manager can be installed alone on a computer without any local hosting capability. It's a small and tidy program with minimal resource requirements. With a virtual machine server/host elsewhere on a local network, even an old weak anything computer that can run a desktop with virt-manager installed has what it takes to run a virtual machine remotely. That vm can be much more powerful.

Truth be told I'm always a few legs away. I'm typing now in a vm that is not running on my local computer, well the vm server is over there, but still, qualifies. The host is actually incapable of running a browser on the internet...

Virt-viewer is another front end which can also run vm's remotely and is even tidier than virt-manager. It is even slightly better in some ways but lacks any host control capability. For that there is virsh!

I'm not sure VirtualBox offers that flexibility to divorce the client from the server.

[limotux]

Thanks @CwF
Tried to install, selecting the first option to install from iso file I got a message that I did not select the OS, though the field to slect tho OS was not available (clicking it does nothing.

Now will try the last option "Manual install"
- out of my 8GB RAM I selected 4GB
- Activated network

I got a black screen, so tiny I can't read but it is like failure!
RETRYING again, but unchecked the checkbox at the bottom that says "Automatically detect....." then the filed to chose the OS was available and chose Debian 11 and I selected my iso file.
Again I changed memory to 4GB.

WOW!
Now I see the installation screen as usual.

I will update you how it goes.
Looks much better this time.

UPDATE:
Installation went as usual, seems after it finishe rebooting, I got a black screen (very tiny) last line reads "Booting from Hard Disk". but nothing happens, it is still there.
Tried to switch of, logout from virt-manager but it gave error saying:

Code: Select all

Error shutting down domain: Requested operation is not valid: domain is not running

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1375, in shutdown
    self._backend.shutdown()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 2972, in shutdown
    raise libvirtError('virDomainShutdown() failed')
libvirt.libvirtError: Requested operation is not valid: domain is not running

Which I don't have a clue what is this, other than while creating the virtual machine I came to a screen asking me something about "domain" I just left it blank as I don't know what to put there as domain. I think the issue is here and I should have entered a "domain" but I don't know what to put in the field! Sorry, I am not that techie!

UPDATE 2:
I can't switch off the machine, I can only "force off"

[CwF]

WOW!
Now I see the installation screen as usual.

Good. Perhaps the goal of the thread has been reached!

From here we may not need a play by play. There are hundreds of pages here to search for the minutia of issues that will crop up. The best thing now is to use it, make errors, notice things...learn through play.

"domain" I just left it blank as I don't know what to put there as domain....
UPDATE 2:
I can't switch off the machine, I can only "force off"

I think domain is the name of the vm...I'm in a hurry here...
for graceful shutdown and reboot the vm may need acpi support packages, and the extra agents listed above.

Also, @Fabien brought up the single package install method that differs from my advice. I only (usually) use synaptic and uncheck the option to treat recommends as dependencies. To attain minimal function as I've mentioned this would be required. I do always review the recommends and will cherry pick what I want separately. With 'recommends as dependencies' enabled the single package install should work fine. --> I did not clearly state that above.

[limotux]

Thanks @CwF
I just thought that me not knowing what is the domain name was so stupid of me! It is simply just the name of the machine.
I deleted the machine, created a new one and put the domain name as "HP" which is my laptop.
Still the same black screen!
I wonder why it can't boot after installation finishes!

[CwF]

Still the same black screen!

When you 'Open' the vm you should get a window with a title "$domain on QEMU/KVM"
Is that the black screen you speak of..type of? If the whole screen goes black, something else is amiss!
If you are referring to a blank window, did you hit the play button?

You will hit dozens of details as you progress, from tiny fonts to your mouse getting trapped...

On the host, open VMM's preferences, that's Edit>>Preferences, and look at the options especially for defaults under "New VM" and "Console" settings.

Usually when I intervene with someone on a computer my first comment is "Stop clicking stuff!"
Here, start clicking on stuff!

For basic operation of vm's virt-manager can manage everything.

[limotux]

Thanks @CwF
The black screen comes after installation finishes, the last line I could read was saying something like "Booting from Hard Disk" but it never boots.
Even if I force shutdown and start again.. it doesn't boot. Maybe not finding where to boot from or perhaps trying to boot from the iso file (assuming it is a CD or a DVD and try to boot from?!
Edit:
I just thought something, in virt-manager when selecting the OS I have Debian 11 (the highest version in the menu), while the iso I am installing from is Debian 12. Can this be the reason?

[CwF]

Maybe not finding where to boot from or perhaps trying to boot from the iso file

You could check the boot order in the vmm - vm settings? Sound like booting from hard disk is correct and if it fail, the install failed. In case you did a full install with a DM and DE then use the vmm menu to 'Send Key' and try an alternate tty. Usually the initial is tty1, maybe tty2 with a DM, and likely tty7 for the DE - so switch to tty3 and see if you get a prompt, and tty4 may sometimes show error messages. If the console doesn't respond, start over.

Keep in mind the magic of working with virtual machines is infinite retries.

(the highest version in the menu)

Selecting 'Generic' is fine.

[limotux]

Thanks @CwF
Creating another machine.
- selected generic
- I found default RAM 4096GB, so I went with it
- Install screen OK
Still same black screen.
Will update you as before.
Update:
This is the only boot from option. /var/lib/libvirt/images/linux2022.qcow2
In virtual machine details I checked the enable boot menu checkbox (no luck)
In virtual machine details in CPU, I checked the copy host CPU configuration (got error: insupported coniguration)
Still, even VirtualBox after installation not working properly and can't install anything!
Something wrong with me Debian installation?
I installed from the iso file and just followed defaults!