Running "Windows Emulation" headless ... possible?
Per Hedeland
per at hedeland.org
Fri Jun 1 19:07:55 UTC 2007
Bakul Shah <bakul at bitblocks.com> 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
More information about the freebsd-emulation
mailing list