[Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Asheesh Laroia]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1232 bytes --]

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:

 	paulproteus@sf:~/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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=ten-dot-three.patch, Size: 1881 bytes --]

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"

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Jonathan Kalbfeld]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

You can always do what I do --- run openvpn between my QEMU sessions and set
up private networks that way ;)

On Feb 4, 2008 4:24 PM, Asheesh Laroia <asheesh@creativecommons.org> wrote:

> 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:
>
>        paulproteus@sf:~/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
>



-- 
--
Jonathan Kalbfeld
ThoughtWave Technologies LLC
www.thoughtwave.com
+1 424 354 1814

[-- Attachment #2: Type: text/html, Size: 2123 bytes --]

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Samuel Thibault]

Mmm, actually, shouldn't qemu use a more "private" network like a
RFC1918 172.16.0.0/12 network?
(see http://www.ucam.org/cam-grin/)

Samuel

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Andreas Schwab]

Samuel Thibault <samuel.thibault@eu.citrix.com> writes:

> Mmm, actually, shouldn't qemu use a more "private" network like a
> RFC1918 172.16.0.0/12 network?

In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Samuel Thibault]

Andreas Schwab, le Tue 05 Feb 2008 11:32:30 +0100, a écrit :
> Samuel Thibault <samuel.thibault@eu.citrix.com> writes:
> 
> > Mmm, actually, shouldn't qemu use a more "private" network like a
> > RFC1918 172.16.0.0/12 network?
> 
> In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8?

Precisely thanks to the reservation page I mentioned.

Samuel

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Ian Jackson]

Andreas Schwab writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> Samuel Thibault <samuel.thibault@eu.citrix.com> writes:
> > Mmm, actually, shouldn't qemu use a more "private" network like a
> > RFC1918 172.16.0.0/12 network?
> 
> In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8?

It isn't.  There is no particular reason to choose one rather than
another so in that sense I disagree with Samuel.

However, there are two things wrong with the current qemu
arrangements.  The first is that the range isn't configurable without
recompiling.  I agree with Johannes Schindelin that it should be.

The second is that addresses chosen from RFC1918 space should be
chosen randomly.  Quoting the RFC:

   If two (or more) organizations follow the address allocation
   specified in this document and then later wish to establish IP
   connectivity with each other, then there is a risk that address
   uniqueness would be violated.  To minimize the risk it is strongly
   recommended that an organization using private IP addresses choose
   randomly from the reserved pool of private addresses, when allocating
   sub-blocks for its internal allocation.

I don't believe that 10.0.2.0/24 was chosen randomly :-).  It would be
better for qemu's default range to be a randomly chosen one.

The URL Samuel quotes, www.ucam.org/cam-grin, is a personal project of
mine which helps choose random addresses and which can also be used
for documenting one's usage.

So while this setup is being made configurable, I think it would
probably be best for qemu's range to be changed to a random range.  I
would suggest 172.30.206.0/24 which is already used as a default for
some regression testing in Xen; since Xen's and qemu's management
setups are best regarded as alternatives, there is less problem with
clashes.  As an alternative, a new range can be chosen randomly quite
easily.

I think it would also be good for one of the qemu maintainers to
document qemu's use in my registry.

Ian.

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Andreas Färber]

Am 05.02.2008 um 12:30 schrieb Ian Jackson:

> I don't believe that 10.0.2.0/24 was chosen randomly :-).  It would be
> better for qemu's default range to be a randomly chosen one.

Please don't randomly choose a default subnet; knowing that QEMU uses  
10.0.2.x allows to adapt to this. If however QEMU starts randomly  
assigning addresses we will also get random conflicts.

Please stick with a default like the current and simply make it  
statically configurable.

Andreas

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Warner Losh]

From: Andreas Färber <andreas.faerber@web.de>
Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Date: Tue, 5 Feb 2008 13:58:28 +0100

> 
> Am 05.02.2008 um 12:30 schrieb Ian Jackson:
> 
> > I don't believe that 10.0.2.0/24 was chosen randomly :-).  It would be
> > better for qemu's default range to be a randomly chosen one.
> 
> Please don't randomly choose a default subnet; knowing that QEMU uses  
> 10.0.2.x allows to adapt to this. If however QEMU starts randomly  
> assigning addresses we will also get random conflicts.
> 
> Please stick with a default like the current and simply make it  
> statically configurable.

I think that the suggestion is that qemu picks, one time, a new
default.  This new default would be selected at random, and would be
the same on all new versions of qemu.

I don't think that the suggestion is to pick a random address every
time qemu starts.

Warner

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Eddie Kohler]

Warner Losh wrote:
> From: Andreas Färber <andreas.faerber@web.de>
> Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
> Date: Tue, 5 Feb 2008 13:58:28 +0100
> 
>> Am 05.02.2008 um 12:30 schrieb Ian Jackson:
>>
>>> I don't believe that 10.0.2.0/24 was chosen randomly :-).  It would be
>>> better for qemu's default range to be a randomly chosen one.
>> Please don't randomly choose a default subnet; knowing that QEMU uses  
>> 10.0.2.x allows to adapt to this. If however QEMU starts randomly  
>> assigning addresses we will also get random conflicts.
>>
>> Please stick with a default like the current and simply make it  
>> statically configurable.
> 
> I think that the suggestion is that qemu picks, one time, a new
> default.  This new default would be selected at random, and would be
> the same on all new versions of qemu.
> 
> I don't think that the suggestion is to pick a random address every
> time qemu starts.

I already have some scripts that depend on the 10.0.2.x default -- probably 
others do too.  Would changing to a different subnet by default really make 
that much difference?  10.0.2.x is, after all, a possible "random" choice :)

Eddie

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Ben Taylor]

---- Warner Losh <imp@bsdimp.com> wrote: 
> From: Andreas Färber <andreas.faerber@web.de>
> Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
> Date: Tue, 5 Feb 2008 13:58:28 +0100
> 
> > 
> > Am 05.02.2008 um 12:30 schrieb Ian Jackson:
> > 
> > > I don't believe that 10.0.2.0/24 was chosen randomly :-).  It would be
> > > better for qemu's default range to be a randomly chosen one.
> > 
> > Please don't randomly choose a default subnet; knowing that QEMU uses  
> > 10.0.2.x allows to adapt to this. If however QEMU starts randomly  
> > assigning addresses we will also get random conflicts.
> > 
> > Please stick with a default like the current and simply make it  
> > statically configurable.
> 
> I think that the suggestion is that qemu picks, one time, a new
> default.  This new default would be selected at random, and would be
> the same on all new versions of qemu.
> 
> I don't think that the suggestion is to pick a random address every
> time qemu starts.

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).

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.

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.

Ben

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Asheesh Laroia]

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

[Ben Taylor]

---- Asheesh Laroia <asheesh@creativecommons.org> wrote: 
> 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've run into that before too..

> > 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, 

It is.

> 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.

Eventually the guest gets a local network that won't conflict with the user's
network infrastructure.

Obviously, if you have a 10.0.x.x, a 172.16.x.x and a 192.168.x.x network,
having a configurable guest network is probably loads simpler.

Ben

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Paul Brook]

> > 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.

Paul

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Asheesh Laroia]

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

[Jernej Simončič]

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).

-- 
< Jernej Simončič ><><><><>< http://deepthought.ena.si/ >

In specifications, Murphy's Law supersedes Ohm's.
       -- Klipstein's Law of Specifications

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Asheesh Laroia]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1253 bytes --]

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!

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Jamie Lokier]

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.

If it _doesn't_ guess, i.e. uses the fixed default of 10.0.2.x (or any
other), then it's _not_ host independent.

VM images which run perfectly on many hosts will breaks on some hosts,
which happen to use a conflicted subnet on their host interfaces.

That's not host independence.

Whereas if it does the auto-selection suggested (I don't regard "pick
an address not used already by the host" as guesswork), then many
VM images will run without change on more hosts.

It makes sense to have a configuration option to statically set the
subnet used by Qemu, of course.

Auto-selection seems like it would be useful for some things -
especially VM images which are shipped with "run Qemu with these
options to use this image".

-- Jamie

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Paul Brook]

On Wednesday 06 February 2008, Jamie Lokier wrote:
> 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.
>
> If it _doesn't_ guess, i.e. uses the fixed default of 10.0.2.x (or any
> other), then it's _not_ host independent.

Well, obviously anything that involves talking to the host or the outside 
world is never going to completely host independent.  Your case will also 
break if you run it on a machine with no internet connection.

The environment inside qemu is consistent.

If you have qemu automagically guess things then the gust OS also has to be 
capable of coping with things changing underneath it.

Paul

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Ian Jackson]

Warner Losh writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> I think that the suggestion is that qemu picks, one time, a new
> default.  This new default would be selected at random, and would be
> the same on all new versions of qemu.

Yes.

> I don't think that the suggestion is to pick a random address every
> time qemu starts.

Indeed, that would be insane.


Ben Taylor writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> 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).

Yes, that's exactly the problem.

Using a (once) randomly-chosen default greatly reduces the odds of
that happening.  Many many people foolishly choose 10.0.{0,1,2,3}.x.
Many fewer choose (say) 172.30.206.x.  So the fixed qemu default
should be 172.30.206.x, or some other range also chosen at random.

(This is why it's worth changing: of course if you choose randomly you
sometimes get 10.0.2.x.  But if you knew you were trying to choose
randomly and your RNG gave you 10.0.2.x you'd probably roll the dice
again - because 10.0.2.x is already overused..)

> 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.

This is a bad idea.  That makes the behaviour very difficult to
predict and debug.  For example, the addresses used by qemu might
depend on whether the boot scripts which start a guest happen to run
before or after an external dhcp server manages to give the host an
address.

This kind of `helpful' behaviour is a recipe for pain.  The addresses
used should be fixed in each particular installation, but configurable,
with a well-chosen default.


andrzej zaborowski writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> This rfc talks about organisations and networks that are real, not
> about the network inside qemu which doesn't have connectivity with
> another qemu network.

Address clashes are still a problem even if the two networks don't
exchange packets, if there is any system which needs to be on both
networks.  And of course in the qemu case the host is on both
networks.

So the addresses used by the guest networks must be distinct from any
addresses of other systems outside the host that the host might need
to talk to.


Ian.

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[andrzej zaborowski]

On 06/02/2008, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> andrzej zaborowski writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> > This rfc talks about organisations and networks that are real, not
> > about the network inside qemu which doesn't have connectivity with
> > another qemu network.
>
> Address clashes are still a problem even if the two networks don't
> exchange packets, if there is any system which needs to be on both
> networks.  And of course in the qemu case the host is on both
> networks.

Right, but this happens so rarely (and there are no obvious symptoms
when it happens) that it's okay for the user to set up non-user-net
networking or issue this one line grep command posted in the original
message. A more useful addition would perhaps be a simple warning from
qemu when the host is in a network containing 10.0.2.0/8.

Indeed when you google "10.0.2.2 ip" half of the hits relate to qemu/kvm/vbox.

Regards

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Ian Jackson]

andrzej zaborowski writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> Right, but this happens so rarely (and there are no obvious symptoms
> when it happens)

The symptoms are generally that the host loses its network connection
to those parts of the outside world, or that it can't reach the guests
at all.

>  that it's okay for the user to set up non-user-net
> networking or issue this one line grep command posted in the original
> message. A more useful addition would perhaps be a simple warning from
> qemu when the host is in a network containing 10.0.2.0/8.

I think a warning if a clash is detected is fine.

> Indeed when you google "10.0.2.2 ip" half of the hits relate to
> qemu/kvm/vbox.

... and the other half to people whose setups this range will break !


Gerd Hoffmann writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> A few years back I've worked for a web company, wrote the border router
> firewall rules, had some rules in there to catch packages with
> rfc1918-private addresses in public network.  Watching the statistics
> showed that the 172.16/12 range was _much_ less used than 10/8 and
> 192.168/16.

Exactly.

> I think 10/8 to be used by companies alot.  192.168.$smallnumber.0/24
> seems to be a quite common default for DSL routers and the like.

Indeed.

> Thus picking a random /24 network from 172.16/12 as new default value
> has a pretty good chance to vastly reduce the number of clashes with
> existing setups.

Exactly.


Ian.

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Gerd Hoffmann]

  Hi,

> Using a (once) randomly-chosen default greatly reduces the odds of
> that happening.  Many many people foolishly choose 10.0.{0,1,2,3}.x.
> Many fewer choose (say) 172.30.206.x.  So the fixed qemu default
> should be 172.30.206.x, or some other range also chosen at random.

A few years back I've worked for a web company, wrote the border router
firewall rules, had some rules in there to catch packages with
rfc1918-private addresses in public network.  Watching the statistics
showed that the 172.16/12 range was _much_ less used than 10/8 and
192.168/16.

I think 10/8 to be used by companies alot.  192.168.$smallnumber.0/24
seems to be a quite common default for DSL routers and the like.

Thus picking a random /24 network from 172.16/12 as new default value
has a pretty good chance to vastly reduce the number of clashes with
existing setups.

HTH,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[andrzej zaborowski]

On 05/02/2008, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Andreas Schwab writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x"):
> > Samuel Thibault <samuel.thibault@eu.citrix.com> writes:
> > > Mmm, actually, shouldn't qemu use a more "private" network like a
> > > RFC1918 172.16.0.0/12 network?
> >
> > In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8?
>
> It isn't.  There is no particular reason to choose one rather than
> another so in that sense I disagree with Samuel.
>
> However, there are two things wrong with the current qemu
> arrangements.  The first is that the range isn't configurable without
> recompiling.  I agree with Johannes Schindelin that it should be.
>
> The second is that addresses chosen from RFC1918 space should be
> chosen randomly.  Quoting the RFC:

That would break all the simplicity that user-net brings. If you want
anything more complex, don't use user-net. The idea is that you don't
even have to have dhcp in the guest.

This rfc talks about organisations and networks that are real, not
about the network inside qemu which doesn't have connectivity with
another qemu network. But even on real networks static IPs usually
simplify more than they break. (For example hardware that by default
assumes that 192.168.0.1 is the gateway and if that's the case, works
without configuration).

I don't think an option to change the default 10.0.2.x addresses for
usernet would be of much use either. A person looking up the option in
the manuals can in the same time figure out how to set up non-user-net
networking, or simply recompile. And the person will only look for it
once they find out about the ip collision (most people won't).

Regards

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Blue Swirl]

I think in VBox the Slirp IP address can be changed. I didn't take
that part to my patch:
http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00470.html
but it should be easy to add.

Currently all NICs share the same subnet.

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Flavio Visentin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Jackson wrote:
> So while this setup is being made configurable, I think it would
> probably be best for qemu's range to be changed to a random range.

The customizable subnet is obviously the preferred choice, but if I had to
choose a subnet I'd choose 192.168.255.0/24.

Someone thinks it's a broadcast subnet ;-)

- --
Flavio Visentin
GPG Key: http://www.zipman.it/gpgkey.asc

There are only 10 types of people in this world:
those who understand binary, and those who don't.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHqNkYusUmHkh1cnoRAsXTAJ44TEWsXvg0o2KPPwLAlAXI+GjiBwCfTlug
+SmdxGnjlDgOhg8BWKuyrVA=
=WBCX
-----END PGP SIGNATURE-----

Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x

[Johannes Schindelin]

Hi,

On Mon, 4 Feb 2008, Asheesh Laroia wrote:

> 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.

And the next guy comes, changing these to 10.0.4.x because he has a net 
which uses 10.0.3.x?

Why not make this configurable with a command line option?

Ciao,
Dscho