qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ian Jackson
Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Date: Tue, 5 Feb 2008 11:30:45 +0000

Andreas Schwab writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not 
10.0.2.x"):
> Samuel Thibault <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]