Re: [DNG] Devuan on a qemu VM guest
Steve Litt wrote on 2017-03-23 06:02: [snip] NETWORKING DOESN'T WORK --- [snip] I've found it easiest to set up a host "tap", owned by user, for networking, with a couple of iptables rules, and a dnsmasq for dhcp service (not dns) on the tap. Then I can run my qemu VM as user (i.e. not root), with full networking, including ssh into the VM from the host. And when I need multiple qemu VMs concurrently, I rather put a vde_switch on the tap and run the qemu with vde networking instead. The host setup for the tap stays the same. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan on a qemu VM guest
On 170322-18:35-1000, Joel Roth wrote: > 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 I remember I did try, but couldn't get '-usbdevice tablet' to work. Otherwise, I mostly managed to get the mouse working in my tentatives: Devuan image in Qemu https://www.CroatiaFidelis.hr/foss/cap/cap-161015-qemu-devuan/ But I never managed to solve the networking, with stock Devuan in VM that is, in all my tries above! (BTW, I'm stealing time from urgent obligations that I have now, bear with me if I don't reply soon to further discussion.) Not with stock Devuan in VM, but yes, I did solve in with Refracta, I even posted on Refracta forums, from within Refracta in VM: http://refracta.freeforums.org/refractasnapshot-10-0-0-arrived-t615-20.html#p5885 Here's the screencast and the network trace of that which was, for me, a huge success story (I was so happy when I made it!): https://www.CroatiaFidelis.hr/foss/cap/cap-161015-qemu-devuan/#No5 I'm now regularly using Refracta as rescue CD, of course, not from VM. I boot it from USB stick, load it in RAM, and I clone my systems (because I build Gentoo, and will eventually install and build Devuan, in Air-Gapped, and clone my systems btwn two, one Air-Gapped, the other online, same-model-hardware machines: very secure!), and I do other stuff. And as per: > > 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. I do have a network bridge set up, like this: https://wiki.gentoo.org/index.php?title=Network_bridge&oldid=613162 ( that's with my updates, the references there to: https://wiki.gentoo.org/wiki/Netifrc/Brctl_Migration and other stuff, are correctly set, IMO. BTW the bridge and things can be set the new, better way, from sysfs, without brctl, in Devuan as well, can it? ) [I do have a network bridge set up] for that purpose, and it works with Refracta, but I don't know how to get stock Devuan to use it for networking. > > HTH, > > Joel > > > 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 Great to know that you can use dig or elinks. I'll bear it in mind when I need it in the future. Just, you're right, no Schmoog the Schmoogle, thanx a bunch for the world's top spying agency, friends of all the Stasi's of the world, who made all their moneys snitching on everybody! No way! I chose: https://en.wikipedia.org/wiki/OpenNIC and I have, generally, no issues with DNS. > > > > HTH, > > > > SteveT > > > > Steve Litt > > March 2017 featured book: Troubleshooting: Why Bother? > > http://www.troubleshooters.com/twb > > ___ ... > -- > Joel Roth > BTW, I'm also so happy to be on the Debian Escapees list: http://troubleshooters.com/linux/debian_escapees.html 23. Miroslav Rovis: to Devuan, Refracta and Head ;- Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan on a qemu VM guest
Joel Roth wrote: > > 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. That helps with using the pointer to change apps, but key combinations for navigating among windows will be captured when the guest is in focus, needing Ctrl+Alt to escape. -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan on a qemu VM guest
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@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
