From owner-freebsd-emulation@FreeBSD.ORG Fri Jun 1 21:31:49 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 B386716A41F for ; Fri, 1 Jun 2007 21:31:49 +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 0962813C457 for ; Fri, 1 Jun 2007 21:31:48 +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 l51LVlYH005236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 23:31:47 +0200 (CEST) (envelope-from per@pluto.hedeland.org) Received: (from per@localhost) by pluto.hedeland.org (8.13.6/8.13.1/Submit) id l51LVlKU005235; Fri, 1 Jun 2007 23:31:47 +0200 (CEST) (envelope-from per) Date: Fri, 1 Jun 2007 23:31:47 +0200 (CEST) From: Per Hedeland Message-Id: <200706012131.l51LVlKU005235@pluto.hedeland.org> To: scottro@nyc.rr.com In-Reply-To: <20070601194018.GB88270@uws1.starlofashions.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 21:31:49 -0000 Scott Robbins wrote: > >Recently, as I've managed to break vmware3 on my 6.2 workstation, I'm >running qemu there as well. I basically had to abandon vmware because I needed to run Linux 2.6 as guest, which didn't work in vmware 3. That and the fact that it seemed to require ongoing support to keep up with evolving FreeBSD, and no-one was able/willing to provide that. > I use that acidos howto and it works well for me. I'm sure it works, just that it seems very static - I don't know if it would be possible to diddle that sysctl in qemu-ifup, maybe it is. I do believe I tried to use it when I first started to use qemu, but ran into some problems. > Some of the things I mention in CURRENT are definitely only >workable in CURRENT, at this point. Could you be specific? >> - 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. You don't need to unload the module for that, and it's not possible if you have some qemu instance still running anyway - just 'deletem' the tap interface instead. I've never tried it, but it's the "right" thing to do - if there was a qemu-ifdown I might put it there. >> - 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 Yes, but I suspect that the problem just got fixed as a side effect of your putting an IP address on the interface - e.g. if it lost its UP state, ifconfig would bring it up again if you configured an address, but 'ifconfig bridge0 up' would have sufficed. >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. Hm, from a networking point of view, having the address on the physical *or* the bridge interface is equally "right" - but if Linux *requires* that you have it on the bridge i/f, I would condsider it a bug or at least a limitation. >> 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. If it does kill your networking, I'd (again:-) consider it a bug (and of course CURRENT occasionally has bugs...) - you asked the system to do something, the system said that it couldn't, then things should be just as they were before (at least if you didn't ask ifconfig to do umpteen things on one invocation - making such stuff fully "transactional" is probably hard enough to not be worth trying). --Per Hedeland