Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Jun 2007 23:31:47 +0200 (CEST)
From:      Per Hedeland <per@hedeland.org>
To:        scottro@nyc.rr.com
Cc:        freebsd-emulation@freebsd.org
Subject:   Re: Running "Windows Emulation" headless ... possible?
Message-ID:  <200706012131.l51LVlKU005235@pluto.hedeland.org>
In-Reply-To: <20070601194018.GB88270@uws1.starlofashions.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Scott Robbins <scottro@nyc.rr.com> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706012131.l51LVlKU005235>