Linux - Virtualization and CloudThis forum is for the discussion of all topics relating to Linux Virtualization and Linux Cloud platforms. Xen, KVM, OpenVZ, VirtualBox, VMware, Linux-VServer and all other Linux Virtualization platforms are welcome. OpenStack, CloudStack, ownCloud, Cloud Foundry, Eucalyptus, Nimbus, OpenNebula and all other Linux Cloud platforms are welcome. Note that questions relating solely to non-Linux OS's should be asked in the General forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I haven't used networking in QEMU virtual machines for perhaps about a year. Today I need to run stuff in a VM and have it make a TCP connection to outside and it's not working. The options for QEMU have not changed since it worked before. The guest OS configuration looks right for running inside QEMU (10.0.2.15 as the guest IP address and 10.0.2.2 as the route gateway). I am using the "-net nic -net user" options on the QEMU command line, as coded in the script I've used for starting QEMU for over 3 years.
I have even done Ubuntu updates from inside QEMU before, so I know the networking worked for Ubuntu as the guest. I've also had Slackware doing networking as a guest before.
I never did understand just how QEMU makes this work. I suspect it has some kind of NAT+DHCPD running inside the emulator. So I don't really know what to look for to see why it isn't working. Outside QEMU I see no traffic at all for what I'm doing. I suspect it is something changed in the host QEMU is running on, but I have no idea what QEMU needs for this.
I might just go ahead and change the networking method over to another where the guest packets are literally forwarded, since this method "makes sense" and allows using the usual debugging. This would require more privilege to set up, which I'd rather avoid. But before doing that I do want to spend some time to find out what broke. And for that I believe it needs to be based on knowledge of how this kind of networking fakery is done.
Any ideas what I should look for?
PS: It might have been working a few days ago, too. I did an install of Xubuntu 12.04 and during the install it reported there was network access for updates during install. I didn't choose that as I never do. But I think it has checked more than just if a local network is configured. I think I'll try doing that install again.
Still looking for a document that describes just what QEMU does with this kind of network setup. The QEMU manual doesn't say much beyond how to use it, and as far as I can tell from the manual, it should work for TCP to anywhere as long as there is a route to 10.0.2.2 in the guest network config (there is). I can ping 10.0.2.2. I cannot TCP to 10.0.2.2 so I think maybe it's the part that picks up TCP packets and makes new host process connections from them that is failing.
Qemu and almost all vm's offer a virtual router as part of the virtual machine application. This is the IP ranges you see. You have used dhcp in qemu to just get what it offers and they tend to call this NAT as opposed to bridged or local.
We may need to know the version you have and the host OS and settings. From the host it should see a virtual nic of sorts and the host ought to allow it to connect.
The old qemu ballard pages were better. I think you can get that also by running qemu with no options. It should list the read me.
I have the QEMU manual and it's basically the same thing as the linked page. It's telling overall usage concepts, and usage options. Nothing tells me what to look for if it doesn't work.
Note that ping works. But ping is only supposed to work to 10.0.2.2 (or whatever you reconfigure the virtual gateway to be). TCP, even to 10.0.2.2 does not work.
Host is Ubuntu 10.10 with multiple interfaces and multiple IPs per interface, including multiple IPv6 (has been this way for a couple years so it is not a fundamental way to break QEMU). QEMU is 0.12.5+noroms-0ubuntu7.8 as packaged by Ubuntu. Guest varies, including Xubuntu 12.04 amd64 and Slackware64 13.37.
UPDATE ... it works SOMETIMES. I was doing another test and booted an Xubuntu image I installed last week and up popped a notice that I had updates. I believe this checks the repository, so I check the network and this time it is working. I made a few more attempts, and it has worked 3 times now ... and failed about 12 times, mostly as a big run of failures. This is making even less sense. Latent bug that is sometimes trigger by something environmental? Now it does look like time to check for updates of QEMU.
The user option has changed back and forth over the years. It should work fine for this. If it did work at all once then we can assume that the nic is being used correctly.
Leave it out and it should still work I think.
I'd be more tempted to suspect your ISP has some issues or your dns entry in the VM need to be added or updated. Try adding your local router's IP address to it.
Stop using ping. You don't care if you can ping the dhcp virtual server.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.