Hi Steve,

Thanks for the pointers.

Steve Litt wrote:
> 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

When I run qemu, Ctrl+Alt is the key combination to leave the VM.

The option '-usbdevice tablet' permits the guest to get the
cursor position without grabbing the mouse. In practice, I
can click on other windows and change focus without having
to use Ctrl+Alt.

> 2. Networking doesn't work

"By default QEMU acts as a firewall and does not permit any
incoming traffic. It also doesn't support protocols other
than TCP and UDP. This means that ping and other ICMP
utilities won't work."

For details see:

https://en.wikibooks.org/wiki/QEMU/Networking#User_mode_networking

I believe you can avoid these limitations if you configure QEMU in
bridge mode, which is introduced in the same reference.

HTH,

Joel

> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

--
Joel Roth