Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
On Tue, 5 Feb 2008, Ben Taylor wrote: It seems to me that there is a corner case where the local host has a 10.0.2.x or 10.0.x.x address which would cause a qemu guest problems that has a 10.0.2.15 address (for -net user only). That's right - that's the issue that I faced. I think the default should be left at 10.0.2.x, and if the localhost has a 10.0.x.x address, then one of the other ranges (172.16.x.x or 192.168.x.x) could be used. I would go one step further: Make the default *always* 10.0.2.x, but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. For the most part, it doesn't make any difference to the host because you don't use the 10.0.2.x address from the host, and only the guest is affected IFF running DHCP. *nod* -- Asheesh. -- We all know Linux is great... it does infinite loops in 5 seconds. - Linus Torvalds about the superiority of Linux on the Amsterdam Linux Symposium
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
On Tue, 5 Feb 2008, Paul Brook wrote: but make it configurable on the command line. That way, there are no surprises ever. The rare people like me with an issue can just pass a command-line parameter in. The point I was trying to make is that qemu could easily arbitrate the guest network based on how the host is configured. If the host has a 10.0.x.x network (and I suppose if we want to be thorough, a 10.0.x.x route), then it punts to 172.16.x.x (and does the same check) and then tries a couple of 192.168.x.x networks. I really dislike this kind of guesswork. It makes it very hard to debug/reproduce problems, and means you're never really sure what qemu is going to do. IMHO One of the really nice features of qemu is that it is host independent. I agree with this - guesswork and invisible options can be confusing. That's why I suggest what I think is the simplest solution: Just let this be overridable on the command line. -- Asheesh. -- Don't suspect your friends -- turn them in! -- Brazil
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
On Tue, 5 Feb 2008, Jernej Simončič wrote: On Tuesday, February 5, 2008, 22:34:04, Asheesh Laroia wrote: I agree with this - guesswork and invisible options can be confusing. That's why I suggest what I think is the simplest solution: Just let this be overridable on the command line. Isn't the user-net IP irrelevant to the outside? AFAIK, it just causes Qemu to act as a normal TCP/IP client to the OS it's running on, and the guest OS simply can't accept incoming connections (nobody actually knows that the program issuing the connections is actually hosting an OS inside). The problem I stated in the original message in the thread http://lists.gnu.org/archive/html/qemu-devel/2008-02/msg00109.html is that I want to connect from the *guest* to the *host*. Since the host and the guest are on the same subnet, only inside the guest the subnet is fake, the guest cannot e.g. ssh to the host. So I patched qemu so that the guest would have a different internal IP range, and then the guest can e.g. ssh to the host. I hope that clears things up. Let me know if further clarification is necessary. -- Asheesh. -- When a camel flies, no one laughs if it doesn't get very far!
[Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
I'm running qemu (really, KVM) in a LAN that uses 10.0.2.x as the IP address block for workstations. So naturally when I booted a guest, it couldn't access machines inside the LAN. I tried the simplest thing that could possibly work: [EMAIL PROTECTED]:~/dnlds/qemu/qemu $ replace 10.0.2 10.0.3 -- `find -type f | grep -v -i CVS ` Booting that resulted in a virtual machine that, as I had hoped, used 10.0.3.15 and could therefore successfully talk to my 10.0.2.x IPs on the LAN. I've attached a 'cvs diff' against HEAD that results from the above command. Out of curiosity, are there plans to make the user-space networking stack IP range configurable at run-time rather than compile time? I'm not suggesting that this patch I attached become part of CVS HEAD necessarily; what I do hope is that this will inspire someone else on the list to make the handling of this more flexible, knowing now that it's fairly easy to do. (-: Even if not, this serves as a report to others that this trivial patch actually does what you'd hope/expect! -- Asheesh. -- It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley Index: qemu-doc.texi === RCS file: /sources/qemu/qemu/qemu-doc.texi,v retrieving revision 1.186 diff -r1.186 qemu-doc.texi 657c657 usual 10.0.2.2. --- usual 10.0.3.2. 676c676 10.0.2.4 smbserver --- 10.0.3.4 smbserver 692c692 is not specified, its value is 10.0.2.15 (default address given by the --- is not specified, its value is 10.0.3.15 (default address given by the 1497c1497 | (10.0.2.2) --- | (10.0.3.2) 1499c1499 DNS server (10.0.2.3) --- DNS server (10.0.3.3) 1501c1501 SMB server (10.0.2.4) --- SMB server (10.0.3.4) 1507c1507 to the hosts starting from 10.0.2.15. --- to the hosts starting from 10.0.3.15. 1510,1511c1510,1511 the address 10.0.2.2 and verify that you got an address in the range 10.0.2.x from the QEMU virtual DHCP server. --- the address 10.0.3.2 and verify that you got an address in the range 10.0.3.x from the QEMU virtual DHCP server. 1515c1515 router (10.0.2.2). --- router (10.0.3.2). Index: vl.c === RCS file: /sources/qemu/qemu/vl.c,v retrieving revision 1.403 diff -r1.403 vl.c 3773c3773 pstrcpy(buf, sizeof(buf), 10.0.2.15); --- pstrcpy(buf, sizeof(buf), 10.0.3.15); Index: slirp/ctl.h === RCS file: /sources/qemu/qemu/slirp/ctl.h,v retrieving revision 1.1 diff -r1.1 ctl.h 6,7c6,7 #define CTL_SPECIAL 10.0.2.0 #define CTL_LOCAL 10.0.2.15 --- #define CTL_SPECIAL 10.0.3.0 #define CTL_LOCAL 10.0.3.15
