From owner-freebsd-emulation@FreeBSD.ORG Fri Jun 1 19:07:55 2007 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DEA016A421 for ; Fri, 1 Jun 2007 19:07:55 +0000 (UTC) (envelope-from per@hedeland.org) Received: from pluto.hedeland.org (1-1-1-13a.mal.sth.bostream.se [82.182.84.27]) by mx1.freebsd.org (Postfix) with ESMTP id DE59913C447 for ; Fri, 1 Jun 2007 19:07:54 +0000 (UTC) (envelope-from per@hedeland.org) Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.13.6/8.13.1) with ESMTP id l51J7mEc002190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 21:07:48 +0200 (CEST) (envelope-from per@pluto.hedeland.org) Received: (from per@localhost) by pluto.hedeland.org (8.13.6/8.13.1/Submit) id l51J7jH2002189; Fri, 1 Jun 2007 21:07:45 +0200 (CEST) (envelope-from per) Date: Fri, 1 Jun 2007 21:07:45 +0200 (CEST) From: Per Hedeland Message-Id: <200706011907.l51J7jH2002189@pluto.hedeland.org> To: bakul@bitblocks.com, freebsd@hub.org In-Reply-To: <20070531220240.82E585B3E@mail.bitblocks.com> X-Scanned-By: MIMEDefang 2.48 on 10.1.1.1 Cc: freebsd-emulation@freebsd.org Subject: Re: Running "Windows Emulation" headless ... possible? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2007 19:07:55 -0000 Bakul Shah wrote: > >> >> Can I run two or more QEMU instances on the same server with different IPs >> ? >> > >> > Yes. But you have to make sure each machine gets its own mac >> > address. >> >> Is that addressed using the tap interface, as Scott mentioned? > >Yes. Hm, maybe I misunderstand the question or the answer, but I disagree.:-) The tap devices get their own MAC addresses, but they're basically irrelevant - what you *do* need to do is give the *qemu* instances their own MAC addresses, e.g. as '-net nic,macaddr=52:54:00:12:34:67' (the default is 52:54:00:12:34:56 - I have no idea if qemu has reserved the 52:54:00 prefix, but I'm sticking to it:-). This is the MAC address that shows up on the interface in the guest, and that everyone else on the same network uses to reach it. > You'd probably want to put tap devices in a bridge (in >/etc/qemu-ifup: ifconfig $1 up; ifconfig bridge0 addm $1). That's what I do, and it works great. Actually I have a setup very similar to what is described by Scott, but none of the problems he seems to run into:-) - running on 6.1-RELEASE, so it's not specific to CURRENT (I believe the description for 6.x that he linked to might possibly be needed on earlier versions - since it's much less convenient, I think it should be avoided). Actually I suspect that Scott's problems might just be general "CURRENTness" rather than having anything to do with qemu - I start and stop qemus all the time, at the moment I have 5 of them bridged together with my physical interface, and though I occasionally encounter some qemu flakiness, the networking is rock solid. Comparing notes, I see these differences in my setup: - I never unload modules - what's the point of that? - I never give an IP address to the bridge interface - this is wrong(tm) IMHO, and in any case there should not be any need for it. - I don't have anything about tap in devfs.conf - but I have the corresponding thing set up via devfs.rules, which I believe is the right place for it to work "dynamically": [localrules=10] add path 'tap*' user per - which correlates to an entry in rc.conf: devfs_system_ruleset="localrules" And not difference, but choice: I create the bridge and add the physical interface to it at boot via rc.conf: cloned_interfaces="bridge0" ifconfig_bridge0="addm bge0 up" - and it stays that way all the time, and my qemu-up is: sudo /sbin/ifconfig $1 up sudo /sbin/ifconfig bridge0 addm $1 Now, I *do* get the error message: ifconfig: BRDGADD tap0: File exists the second and subsequent time a qemu happens to choose tap0 (and ditto for the other tapN of course), but this is totally harmless - the fix is to redirect stderr for the addm line to /dev/null, but one day it might have something important to tell you.:-) >Performance will be worse. But I guess you knew that:-) Only >you can decide if you can live with degraded performance. >You can try running on an SMP machine but I am not sure if >kqemu is SMP safe. I'm using kqemu on SMP (dual core), but that doesn't mean that it's safe:-) - as I wrote, I occasionally see some flakiness, like an unexplainable kernel panic in a Linux guest (though actually that qemu runs with -kernel-kqemu - which I've never found to be reliable to do on more than one qemu at a time btw). It's certainly stable enough for me though, and it has never caused any FreeBSD-host problems. --Per Hedeland