From owner-freebsd-emulation@FreeBSD.ORG Fri Jun 1 19:40:23 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 8E7AF16A41F for ; Fri, 1 Jun 2007 19:40:23 +0000 (UTC) (envelope-from scottro@nyc.rr.com) Received: from mail13.simplicato.com (mail13.simplicato.com [207.99.47.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6563A13C447 for ; Fri, 1 Jun 2007 19:40:23 +0000 (UTC) (envelope-from scottro@nyc.rr.com) Received: from mail13.simplicato.com (localhost [127.0.0.1]) by mail13.simplicato.com (Postfix) with ESMTP id 59CA277B309 for ; Fri, 1 Jun 2007 15:40:22 -0400 (EDT) Received: from uws1.starlofashions.com (unknown [12.44.50.124]) by mail13.simplicato.com (Postfix) with ESMTP id C750377B188 for ; Fri, 1 Jun 2007 15:40:20 -0400 (EDT) Received: by uws1.starlofashions.com (sSMTP sendmail emulation); Fri, 1 Jun 2007 15:40:18 -0400 Date: Fri, 1 Jun 2007 15:40:18 -0400 From: Scott Robbins To: freebsd-emulation@freebsd.org Message-ID: <20070601194018.GB88270@uws1.starlofashions.com> Mail-Followup-To: freebsd-emulation@freebsd.org References: <20070531220240.82E585B3E@mail.bitblocks.com> <200706011907.l51J7jH2002189@pluto.hedeland.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706011907.l51J7jH2002189@pluto.hedeland.org> User-Agent: mutt-ng/devel-r804 (FreeBSD) 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:40:23 -0000 On Fri, Jun 01, 2007 at 09:07:45PM +0200, Per Hedeland wrote: > Bakul Shah wrote: > > > > 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. Recently, as I've managed to break vmware3 on my 6.2 workstation, I'm running qemu there as well. I use that acidos howto and it works well for me. Some of the things I mention in CURRENT are definitely only workable in CURRENT, at this point. > > Comparing notes, I see these differences in my setup: > > - I never unload modules - what's the point of that? An anal sense of cleanliness? :) I usually only open qemu to do what I have to do and close it afterwards. Also, to avoid the tap errors you mention below. > > - 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. It probably is, and when Bakul spent a lot of time working with me on this, I believe he also thought it was wrong. However, it was a workaround for a problem at the time--as I say in my howto, I don't really understand bridging very well. If I were constantly running qemu I would also do it as you do, in rc.conf--AND, in rc.conf it was definitely unnecessary to give the bridge an address. Interestingly enough, in Linux, the way to do it (only tried with VirtualBox, not qemu) is to take the address off the interface, eg ifconfig 0.0.0.0 eth0 and give an address to the bridge. (I think that is the accepted method with Linux0. > > - 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" Yes, I think that's just a difference in the way we do things--I'm more used to using devfs.conf. Doing it that way was suggested to me by someone--possibly Bakul, but I honestly don't remember. > > 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.:-) This doesn't seem to be harmless for me, and if I get a chance this weekend, I'll doublecheck that. It seems that it kills the networking, but that might also be due to various errors or differences in my setup. > --Per Hedeland -- Scott Robbins GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6