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, 'qemu
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
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 idea, though.
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 need any
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 virtual
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 of
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 hosts).
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
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 wants to
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
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=...
For
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 forward in this
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 persistent
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
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
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
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
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 ?
What
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 simple C
-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're all up
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 rules and calls
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 and
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
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
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
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
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
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, 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
29 matches
Mail list logo
