Re : [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
- Message d'origine De : Asheesh Laroia [EMAIL PROTECTED] À : Asheesh Laroia on [qemu-devel] qemu-devel@nongnu.org Envoyé le : Mardi, 5 Février 2008, 23h24mn 42s Objet : 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 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. Couldnt you use a network bridge for this purpose ? Kind regards, Sylvain Petreolle (aka Usurp) Support artists, not multinationals - http://Iwouldntsteal.net Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net Free music you can listen to everywhere : http://www.jamendo.com
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
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
On 06/02/2008, Ian Jackson [EMAIL PROTECTED] 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
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 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
Andreas Schwab, le Tue 05 Feb 2008 11:32:30 +0100, a écrit : Samuel Thibault [EMAIL PROTECTED] 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
Samuel Thibault [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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
Andreas Schwab writes (Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x): Samuel Thibault [EMAIL PROTECTED] 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
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
From: Andreas Färber [EMAIL PROTECTED] 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
Warner Losh wrote: From: Andreas Färber [EMAIL PROTECTED] 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
Warner Losh [EMAIL PROTECTED] wrote: From: Andreas Färber [EMAIL PROTECTED] 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
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 05/02/2008, Ian Jackson [EMAIL PROTECTED] wrote: Andreas Schwab writes (Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x): Samuel Thibault [EMAIL PROTECTED] 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
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
Asheesh Laroia [EMAIL PROTECTED] 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
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
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
-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
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
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
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
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
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 [EMAIL PROTECTED] 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: [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 -- -- Jonathan Kalbfeld ThoughtWave Technologies LLC www.thoughtwave.com +1 424 354 1814
Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
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
