On Tue, Oct 04, 2005 at 10:23:26AM +0200, Matteo wrote:
> That would be a very good idea. I've always thought of installing vde or
> any other application to make a network of VMs painfull.
Well, i find that a qemu_switch would be more convient as you could set up
the network at boot time (like i
Le lundi 03 octobre 2005 à 20:29 +0200, Fabrice Bellard a écrit :
> Another point is that I am very tempted to integrate a feature to
> connect several qemu without needing an external program such as VDE. I
> am thinking of it because it would be relatively easy to add to the
> existing user-ne
Christian MICHON a écrit :
no vde for windows hosts :(
Have you tryed ? Because the VDE code don't interract to mutch with the
system (only require POSIX OS) and contains a lot of "win32" test as you
can see in the attachement. But there is no document how to compile
that. Since there are "w
no vde for windows hosts :(
On 10/3/05, Jean-Christian de Rivaz <[EMAIL PROTECTED]> wrote:
> Christian MICHON a écrit :
> > to do so, does that mean we would need to launch a 1st qemu
> > instance which would contain the dhcp server, and next qemu
> > instances would connect to it ?
> >
> > if so,
On Mon, Oct 03, 2005 at 08:29:13PM +0200, Fabrice Bellard wrote:
> Hi,
>
> Sorry for the lack of comment. I mostly use the 'user-net' networking so
> I never bothered much about TUN/TAP.
>
> What I can say is that the '-net xxx' option will be implemented to
> solve the existing issues. My only
Christian MICHON a écrit :
to do so, does that mean we would need to launch a 1st qemu
instance which would contain the dhcp server, and next qemu
instances would connect to it ?
if so, 'qemu -server' and 'qemu -client -connect_to server' could
be useful...
As I understand and with what I know
to do so, does that mean we would need to launch a 1st qemu
instance which would contain the dhcp server, and next qemu
instances would connect to it ?
if so, 'qemu -server' and 'qemu -client -connect_to server' could
be useful...
On 10/3/05, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
Hi,
Sorry for the lack of comment. I mostly use the 'user-net' networking so
I never bothered much about TUN/TAP.
What I can say is that the '-net xxx' option will be implemented to
solve the existing issues. My only concern is about ensuring backward
compatibility (if no one needs it then i
On Mon, Oct 03, 2005 at 02:54:42PM +0200, Henrik Nordstrom wrote:
>
> On Sun, 2 Oct 2005, Jim C. Brown wrote:
> >What it really boils down to is cleaning up the command line options for
> >the
> >network interface(s), which up to now have been added in a hackish,
> >piece-wise
> >manner.
>
> And
On Mon, Oct 03, 2005 at 03:01:08PM +0200, Henrik Nordstrom wrote:
> On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
> >>In fact, if qemu supported both these things, then I don't see a reason
> >>for
> >>-tun-fd at all (except for something like VDE).
> >
> >Agree, and a -vde option will go for
On Mon, Oct 03, 2005 at 03:07:02PM +0200, Henrik Nordstrom wrote:
> On Sun, 2 Oct 2005, Jim C. Brown wrote:
> Only objection is that for the tunfd case I would use
>
> -net tap,fd=10,macaddr=...
>
Since it doesn't have to be a tap device, how about this?
-net socket,fd=10,macaddr=...
> >
Henrik Nordstrom a écrit :
On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
It's already the case with at least my proposed patch. I have't tested
the patch written by Henrik Nordstrom or Lars Munch but it's likly
that there work the same way since this feature come from the Linux
kernel tu
Henrik Nordstrom a écrit :
On Mon, 3 Oct 2005, Jean-Christian de Rivaz wrote:
The idea of the "-vde" option is to have in parameter the VDE socket
(default to "/tmp/vde.ctl") an act like vde_plug so it don't need any
other code to work. Just start a "vde_switch" and as many "qemu -vde"
you wa
Henrik Nordstrom a écrit :
The proposal by Fabrice looks better to me
-net usernet,macaddr=00:11:a:0:2:19 -net tunfd=10,macaddr=00:11:a:0:1:19
this way the syntax can easily be extended with new options as needed,
and the exact order of things is not important (you just specify the net
param
On Mon, 3 Oct 2005, Jim C. Brown wrote:
One potential issue is that the vde code is under the GPL, while qemu (at
least the part that we're talking about) is under the BSD license.
Not really. None of the VDE code is needed to connect to VDE. The protocol
used for VDE connection management is
On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
It's already the case with at least my proposed patch. I have't tested the
patch written by Henrik Nordstrom or Lars Munch but it's likly that there
work the same way since this feature come from the Linux kernel tun code.
Indeed. It is impos
Jim C. Brown a écrit :
The idea of the "-vde" option is to have in parameter the VDE socket
(default to "/tmp/vde.ctl") an act like vde_plug so it don't need any
other code to work. Just start a "vde_switch" and as many "qemu -vde"
you wants to create a complete virtual nework (1 switch and n
On Sun, 2 Oct 2005, Jim C. Brown wrote:
vdeq works the way it does because the odds of getting a special "-vde-socket"
option in qemu were moot. And perhaps so the author of VDE could have control
over what options vdeq supported. (In the case of vdeq, its a clever hack: both
tuntap devices and
On Sun, 2 Oct 2005, Jim C. Brown wrote:
So while we're at it, we should redesign the interface for qemu. For each nic,
we'd have -net type[,macaddr] where type is "tap" or "user" or "dummy" and
the macaddr is an (optional) parameter that replaces -macaddr. Number of nics
would depend on number o
On Mon, 3 Oct 2005, Jean-Christian de Rivaz wrote:
The idea of the "-vde" option is to have in parameter the VDE socket (default
to "/tmp/vde.ctl") an act like vde_plug so it don't need any other code to
work. Just start a "vde_switch" and as many "qemu -vde" you wants to create a
complete vir
On Mon, Oct 03, 2005 at 11:46:57AM +0200, Jean-Christian de Rivaz wrote:
> Ok for "-tuntap" long option. Can I propose "-t" for a short option ?
>
Makes sense.
> The idea of the "-vde" option is to have in parameter the VDE socket
> (default to "/tmp/vde.ctl") an act like vde_plug so it don't n
I'd argue that it should be "-tap" or "-tuntap" instead of "-tun", since using
tun would confuse users who knew the distinction between tun devices and tap
devices.
Ok for "-tuntap" long option. Can I propose "-t" for a short option ?
I'm not sure if a "-vde" option is necessary or a good id
On Sun, Oct 02, 2005 at 10:23:41PM +0200, Jean-Christian de Rivaz wrote:
> VDE is a very useful code to complete project like qemu. It requiere
> special code to connect to the vde_switch, but this not a complexe code
> (see how vde_plug make that). Since VDE is higly likly used with qemu, I
> s
Jim C. Brown a écrit :
On Sun, Oct 02, 2005 at 01:45:16PM -0500, Anthony Liguori wrote:
I don't understand, why is this patch needed?
It makes qemu easier to use.
A lot easier to use a persistent tap by doing "qemu -use-already-open-tap tap1"
instead of hacking around with persistenttapdev
Jim C. Brown a écrit :
On Sun, Oct 02, 2005 at 07:50:29PM +0200, Jean-Christian de Rivaz wrote:
Is there any guideline about the network script ? Or should we add an
option to let the choice to the user if the network script is called or
not ?
--
Jean-Christian de Rivaz
If it's persisten
On Sun, Oct 02, 2005 at 07:50:29PM +0200, Jean-Christian de Rivaz wrote:
> Is there any guideline about the network script ? Or should we add an
> option to let the choice to the user if the network script is called or
> not ?
>
> --
> Jean-Christian de Rivaz
>
If it's persistent, the device
On Sun, Oct 02, 2005 at 01:45:16PM -0500, Anthony Liguori wrote:
> I don't understand, why is this patch needed?
>
It makes qemu easier to use.
A lot easier to use a persistent tap by doing "qemu -use-already-open-tap tap1"
instead of hacking around with persistenttapdev.c
> It's a pretty simpl
Jean-Christian de Rivaz wrote:
Henrik Nordstrom a écrit :
On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
Attached is a patch proposition to allow opennig an existing tun
(already configured by root).
This patch can work only on Linux as it make no change into the code
for BSD.
Pleas
Lars Munch a écrit :
On Sun, Oct 02, 2005 at 12:24:53PM +0200, Henrik Nordstrom wrote:
On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
Yes. This is just an update of my first patch posted the 13 january 2005
so it should apply without offset warning.
Maybe can I propose to joint our eff
On Sun, Oct 02, 2005 at 12:24:53PM +0200, Henrik Nordstrom wrote:
> On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
>
> >Yes. This is just an update of my first patch posted the 13 january 2005
> >so it should apply without offset warning.
> >
> >Maybe can I propose to joint our effort ?
>
>
On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote:
Yes. This is just an update of my first patch posted the 13 january 2005 so
it should apply without offset warning.
Maybe can I propose to joint our effort ?
What remains to make it complete is the command line parser, allowing
network opti
Henrik Nordstrom a écrit :
On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
Attached is a patch proposition to allow opennig an existing tun
(already configured by root).
This patch can work only on Linux as it make no change into the code
for BSD.
Please make open comment about this to
On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
Attached is a patch proposition to allow opennig an existing tun (already
configured by root).
This patch can work only on Linux as it make no change into the code for BSD.
Please make open comment about this to improve it or to let my know w
On Sat, 1 Oct 2005, Jim C. Brown wrote:
Depends on how intellegent the switch is. (Forwarding back only those packets
which are addressed to the host itself wouldn't necessarily cause an infinite
loop. Tho the switch would probably be smarter if it dropped such packets
outright.)
Imagine havin
Jim C. Brown a écrit :
On Sat, Oct 01, 2005 at 10:24:03PM +0200, Jean-Christian de Rivaz wrote:
And qemu already supports that, via the -tun-fd option.
Can you please give me an exemple how to use the -tun-fd option to open
an existing tun (i.e: tun-alice) ? This option only work for already
On Sat, Oct 01, 2005 at 02:50:59PM +0100, Paul Brook wrote:
> On Saturday 01 October 2005 14:07, Jim C. Brown wrote:
> > On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> > > That means it would work if the host NIC is connected to a switch? Then
> > > the switch would send packets
On Sat, Oct 01, 2005 at 10:24:03PM +0200, Jean-Christian de Rivaz wrote:
> >And qemu already supports that, via the -tun-fd option.
>
> Can you please give me an exemple how to use the -tun-fd option to open
> an existing tun (i.e: tun-alice) ? This option only work for already
> opened tap/tun
Attached is a patch proposition to allow opennig an existing tun
(already configured by root).
This patch can work only on Linux as it make no change into the code for
BSD.
Please make open comment about this to improve it or to let my know why
this if not a good thing...
--
Jean-Christian
Henrik Nordstrom a écrit :
On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
You point the real question: why it has been impossible to get
accepted any patch that fixed this. I has proposed one myself and I
get no comment at all. I see similar effort from others and obviousely
there failed
You point the real question: why it has been impossible to get accepted
any patch that fixed this. I has proposed one myself and I get no
comment at all. I see similar effort from others and obviousely there
failed almost the same way. No getting any valuable comment about why a
idea proposed
On Sat, 1 Oct 2005, Oliver Gerlich wrote:
That means it would work if the host NIC is connected to a switch? Then
the switch would send packets from the guest which are meant for the
host back to the host NIC and everything's fine! Or did I misunderstand
that now?
In this kind of setup you wil
On Sat, 1 Oct 2005, Jean-Christian de Rivaz wrote:
You point the real question: why it has been impossible to get accepted any
patch that fixed this. I has proposed one myself and I get no comment at all.
I see similar effort from others and obviousely there failed almost the same
way. No gett
On Saturday 01 October 2005 14:07, Jim C. Brown wrote:
> On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> > That means it would work if the host NIC is connected to a switch? Then
> > the switch would send packets from the guest which are meant for the
> > host back to the host NIC
On Sat, Oct 01, 2005 at 01:30:06PM +0200, Oliver Gerlich wrote:
> That means it would work if the host NIC is connected to a switch? Then
> the switch would send packets from the guest which are meant for the
> host back to the host NIC and everything's fine! Or did I misunderstand
> that now?
>
>
On Sat, Oct 01, 2005 at 10:12:41AM +0200, Jean-Christian de Rivaz wrote:
> Jim C. Brown a ?crit :
>
> >Typically, tapX (tap0, tap1, etc) names are reserved for tap devices
> >(ethernet
> >frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP
> >frames).
> >
> >qemu breaks those rul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim C. Brown schrieb:
> On Fri, Sep 30, 2005 at 03:13:21PM -0700, Don Kitchen wrote:
>
[...]
>
>>I'm interested in the handling of ethernet frames because I haven't been
>>able to get the bridge to pass packets between added interfaces (yes,
>>they'r
Jim C. Brown a écrit :
Typically, tapX (tap0, tap1, etc) names are reserved for tap devices (ethernet
frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP frames).
qemu breaks those rules and calls the tap device that it creates tun0. This is
done for reasons that Fabrice has not
On Fri, Sep 30, 2005 at 03:13:21PM -0700, Don Kitchen wrote:
> I've used that one "pricey" product at work, but it always seemed a bit
> expensive for home users. But I only knew about some of the other emulators,
> the ones that are so slow you wonder why didn't they warn you not to
> bother downl
> I have some questions about the networking that I hope someone can answer.
> Qemu is able to use tun & tap devices. I've taken the tundev.c program,
> which opens a tun device and passes the fd to qemu, and compared it to
> the tapdev.c program (which qemu is also able to use) and there's very
>
On Fri, 30 Sep 2005, Don Kitchen wrote:
I have some questions about the networking that I hope someone can answer.
Qemu is able to use tun & tap devices. I've taken the tundev.c program,
which opens a tun device and passes the fd to qemu, and compared it to
the tapdev.c program (which qemu is al
I'm very pleased with qemu's price/performance ratio.
I've used that one "pricey" product at work, but it always seemed a bit
expensive for home users. But I only knew about some of the other emulators,
the ones that are so slow you wonder why didn't they warn you not to
bother downloading the thi
51 matches
Mail list logo
