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
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
34 matches
Mail list logo
