From owner-freebsd-questions@FreeBSD.ORG Thu May 14 11:39:19 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B74E106566C for ; Thu, 14 May 2009 11:39:19 +0000 (UTC) (envelope-from marco.borsatino@poste.it) Received: from relay-pt2.poste.it (relay-pt2.poste.it [62.241.5.253]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7D98FC15 for ; Thu, 14 May 2009 11:39:18 +0000 (UTC) (envelope-from marco.borsatino@poste.it) Received: from poste.it (192.168.44.52) by relay-pt2.poste.it (7.3.122) id 4A0B516F00006163; Thu, 14 May 2009 13:39:17 +0200 Date: Thu, 14 May 2009 13:39:17 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "marco\.borsatino\@poste\.it" To: freebsd-questions@freebsd.org X-XaM3-API-Version: 5.0(R1) X-SenderIP: 79.25.226.154 Cc: nvass9573@gmx.com Subject: virtual network with qemu X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 11:39:19 -0000 First, thank you. You are right, qemu has an internal DHCP server, which should be perfect = for me, becuse I would like to emulate a network without any contact with= external (real) world. The problem is that my virtual PC can't ping the = gateway. For my idea (this is just a way to study a project for a network= without a real network) the communication is intended only among virtual= PCs. But If I can't contact the (virtual) gateway will it be possible to= contact another virtual PC on a different subnet? Or even on the same su= bnet? In my idea I would like to create a little but complex net with one= master controller, a slave controller, a little number of client belongi= ng to different subnets. Maybe with or without a DHCP server. Marco ---------- Original Header ----------- >From : "Nikos Vassiliadis" nvass9573@gmx.com To : "marco.borsatino@poste.it" marco.borsatino@poste.it Cc : freebsd-questions@freebsd.org Date : Thu, 14 May 2009 11:28:59 +0300 Subject : Re: virtual network with qemu > marco.borsatino@poste.it wrote: > > When the installation program asked for information about network con= figuration, as a > > first step, I chose DHCP configuration and, as usualy, the network ha= s been set > > like this: > > IP 10.0.2.15/255.255.255.0 > > If I recall correctly qemu has a built-in DHCP server. > That's the one that served you, not a "real" DHCP server > running on your LAN, that is, you are not in any way connected > to the "real" network. > > > #qemu -L /usr/local/share/qemu -localtime -net nic,macaddr=3D00:15:f2= :44:2d:01 -net socket,mcast=3D230.0.0.1:1234 -hda pc01.img -cdrom /dev/ac= d0 & > > but the network in the guest system does not work. > > It makes sense, that the multicast option will work > between virtual hosts only. That is, it uses multicast > to provide a virtual broadcast domain, which appears to > the host operating system as a ethernet device. > > > ifconfig in the guest system tells: > > #ifconfig -a > > ed0: flags=3D8843 metric 0 mt= u 1500 > > ether 00:15:f2:44:2d:01 > > media: Ethernet 10baseT/UTP > > plip0: ... > > lo0: ... > > If I try: > > #ping 10.0.2.2 (the gateway) > > all packets are lost. For this reason, I've tryed a static IP configu= ration like this: > > IP 10.0.2.4/255.255.255.0 > > gateway 10.0.2.2 > > nameserver 10.0.2.3 > > but the gateway does not respond. So it is useless to try with a seco= nd guest system. > > No, infact it's the exact opposite. This type of device > will work *only* if you add another virtual system. > > To get connected to the "real" network, you must use tap > devices. Correction: > Browsing the qemu's wiki I found out that there is a newer > and simpler approach that I am not familiar with: > http://calamari.reverse-dns.net:980/cgi-bin/moin.cgi/user-net > > So, if you do want internet access, just remove all network > associated options and it will work automagically. If you just > want to connect guest systems together use multicast or socket > or ... > > HTH, Nikos > >