Running "Windows Emulation" headless ... possible?

[Scott Robbins]

On Fri, Jun 01, 2007 at 09:07:45PM +0200, Per Hedeland wrote:
> Bakul Shah <bakul at bitblocks.com> 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