:: [DNG] Devuan on a qemu VM guest
Top Page
Delete this message
Reply to this message
Author: Steve Litt
Date:  
To: dng
Subject: [DNG] Devuan on a qemu VM guest
Hi all,

By the time you take into account host OS distro and hardware, every
setup is unique. For those whose situation is anything like mine,
running Devuan as a Qemu guest VM is difficult. So let me tell you two
must-know difficulties I've learned, and the workaround for each:

1. Mouse pointer won't leave VM window, even if you press Right+Ctrl
2. Networking doesn't work

MOUSE POINTER WON'T LEAVE VM WINDOW, EVEN IF YOU PRESS RIGHT+CTRL
-----------------------------------------------------------------
This can make your life miserable. Once you click into the VM's window,
you can't move the mouse pointer out. Pressing the right CTRL key, or
whatever you use as a Qemu escape key, doesn't allow you to move the
mouse out or hotkey out. About all you can do is close the VM, and if
you can't do that, you need to do Ctrl+Alt+F3, login to the virtual
terminal, and kill qemu's process.

This problem happens only when you're in Devuan or Refracta logged into
X on the VM that operates off the VM's virtual hard disk. It does not
happen on the live CD image. It doesn't happen with many other distros.
I haven't tested Debian, because using Debian gives me an ugly feeling
in the pit of my stomach.

The workaround is this: use the -show-cursor option right after you
declare your -vga choice. I used -vga std and it worked well.


NETWORKING DOESN'T WORK
-----------------------
This is usually discovered as an apt-get install or apt-get upgrade
failure. The first thing to remember is the following:

***Ping from a Qemu guest to an Internet machine ALWAYS fails***

Always, every time, by design, it fails. Without jumping through a lot
of hoops, you can't send IMCP packets from a Qemu guest all the way to
an Internet host. So save yourself a fortune in time and don't test
with ping. Instead, test with dig and elinks, or equivalents. Start
with the following command:

dig @8.8.8.8 devuan.org

In the preceding, 8.8.8.8 is Google's public DNS. If you refuse to use
Google on principle, substitute another always-good public DNS. The
point is, you're telling dig to send the query to a specific, known
good server on the Internet.

If the preceding quickly responds, giving you an answer section, then
you know you can reach 8.8.8.8 on the Internet, so any problems you
have are your machine's DNS. If it hangs around and eventually times
out, you're not reaching 8.8.8.8, and you have a basic connectivity
problem.

If the problem is only DNS, look at your guest's /etc/resolv.conf. Mine
was fec0::3 and didn't work, so I strongarmed it to 8.8.8.8 and
8.8.4.4, Google's two public DNS servers. Once again, if you don't want
to feed Google's information machine, use IP addresses from another
public DNS. After setting /etc/resolv.conf the way you want it, be sure
to prevent its modification by networkmanger or whatever, by chattr -i.
Or, if you want to do it right, fix your guest's dhcp so it works
correctly, but that's beyond the scope of this document.

If the guest has basic connection problems (can't access 8.8.8.8, and
remember a guest can't ping the Internet), investigate. First, can the
hardware host OS access 8.8.8.8? If not, fix that first. Once the
hardware host can access 8.8.8.8, start looking at firewalls, ip
forwarding, the network options in the qemu command, and the like. A
good start is to see if non-Devuan guest VMs have similar problems. If
so, it's probably a problem on your metal host's iptables or other
config, or something common between the commands that ran the two. If
the non-Devuan VM displays no problems, look at the Devuan VM itself.

HTH,

SteveT

Steve Litt
March 2017 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb