1:53 p.m.
Hi,
First of all i would like to understand the exact meaning of the vm_network,
from the wiki [1] - "a "Vm network" is implemented over a bridge, otherwise
bridgeless",
if so, why not calling network property <bridged>true|false</bridged>?
from the other hand i understand that this is only current implementation and it
may change in a future,
anyway adding <vm_network>true|false</vm_network> property to <network>
entity in api
(as was suggested) doesn't sound good cause vm_network sounds as a network type, but
then
the question is Management/Migration/Storage/Display should be also network's types?
and if single
network can be used for the Management|Migration|Storage|Display simultaneously? if the
answer is
yes, network modelling probably should look like:
<network>
<bridged>true|false</bridged>
<type>Management/Migration/Storage/Display</type>
</network>
or
<network>
<bridged>true|false</bridged>
<designation>Management|Migration|Storage|Display</designation>
</network>
your thoughts?
[1] http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
4:58 p.m.
On 03/15/2012 12:53 PM, Michael Pasternak wrote:
Hi,
First of all i would like to understand the exact meaning of the vm_network,
from the wiki [1] - "a "Vm network" is implemented over a bridge,
otherwise bridgeless",
if so, why not calling network property<bridged>true|false</bridged>?
bridge vs. bridgeless is an implementation detail. some network models
could run without a bridge as well for VMs (though not currently supported).
so the optimization is to not use a bridge for networks that can't run
VMs, but the reverse logic does not apply.
from the other hand i understand that this is only current implementation and it
may change in a future,
anyway adding<vm_network>true|false</vm_network> property to<network>
entity in api
(as was suggested) doesn't sound good cause vm_network sounds as a network type, but
then
the question is Management/Migration/Storage/Display should be also network's types?
and if single
network can be used for the Management|Migration|Storage|Display simultaneously? if the
answer is
yes, network modelling probably should look like:
<network>
<bridged>true|false</bridged>
<type>Management/Migration/Storage/Display</type>
</network>
or
<network>
<bridged>true|false</bridged>
<designation>Management|Migration|Storage|Display</designation>
</network>
that bridged should be replaced with something saying VM_Network (better
name needed).
btw, I wonder if a private network (only for one vm) is also a type, or
just a private case of a vm network.
and that type/designation can have more than one of course.
(and that migration/storage networks are still not supported).
your thoughts?
[1] http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks
10:33 a.m.
On 03/15/2012 03:58 PM, Itamar Heim wrote:
On 03/15/2012 12:53 PM, Michael Pasternak wrote:
>
> Hi,
>
> First of all i would like to understand the exact meaning of the vm_network,
> from the wiki [1] - "a "Vm network" is implemented over a bridge,
otherwise bridgeless",
>
> if so, why not calling network property<bridged>true|false</bridged>?
bridge vs. bridgeless is an implementation detail. some network models could run without
a bridge as well for VMs (though not currently supported).
so the optimization is to not use a bridge for networks that can't run VMs, but the
reverse logic does not apply.
>
> from the other hand i understand that this is only current implementation and it
> may change in a future,
>
> anyway adding<vm_network>true|false</vm_network> property
to<network> entity in api
> (as was suggested) doesn't sound good cause vm_network sounds as a network type,
but then
> the question is Management/Migration/Storage/Display should be also network's
types? and if single
> network can be used for the Management|Migration|Storage|Display simultaneously? if
the answer is
> yes, network modelling probably should look like:
>
> <network>
> <bridged>true|false</bridged>
> <type>Management/Migration/Storage/Display</type>
> </network>
>
> or
>
> <network>
> <bridged>true|false</bridged>
> <designation>Management|Migration|Storage|Display</designation>
> </network>
that bridged should be replaced with something saying VM_Network (better name needed).
the question is Management/Migration/Storage/Display can be non-bridged?, if so,
<bridged>true|false</bridged> makes sense.
btw, I wonder if a private network (only for one vm) is also a type,
or just a private case of a vm network.
<private>true</private> by itself doesn't provide much info and to
complete the picture will require
<network>
<private>true</private>
<designation>VM</designation>
<vm id=xxx>
</network>
having only <designation>VM</designation> also not enough cause it may sound
that this network will be used only for vms and not a single vm.
and that type/designation can have more than one of course.
(and that migration/storage networks are still not supported).
i know, looking forward to take in account all future features.
>
> your thoughts?
>
> [1] http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks
>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
11:21 a.m.
On 03/18/2012 09:33 AM, Michael Pasternak wrote:
the question is Management/Migration/Storage/Display can be
non-bridged?, if so,
<bridged>true|false</bridged> makes sense.
bridge is an implementation detail at host level, hence the discussion
is about abstracting it from users.
a VM network doesn't have to have bridge at host level, for networks
using VMFex or SR-IOV
11:43 a.m.
On 03/18/2012 10:21 AM, Itamar Heim wrote:
On 03/18/2012 09:33 AM, Michael Pasternak wrote:
> the question is Management/Migration/Storage/Display can be non-bridged?, if so,
> <bridged>true|false</bridged> makes sense.
bridge is an implementation detail at host level, hence the discussion is about
abstracting it from users.
a VM network doesn't have to have bridge at host level, for networks using VMFex or
SR-IOV
<network>
<designation>Management|Migration|Storage|Display|VM</designation>
</network>
what do you say about having it as another /designation/ type?
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
11:39 a.m.
On 03/18/2012 10:43 AM, Michael Pasternak wrote:
On 03/18/2012 10:21 AM, Itamar Heim wrote:
> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>> the question is Management/Migration/Storage/Display can be non-bridged?, if so,
>> <bridged>true|false</bridged> makes sense.
>
> bridge is an implementation detail at host level, hence the discussion is about
abstracting it from users.
> a VM network doesn't have to have bridge at host level, for networks using VMFex
or SR-IOV
<network>
<designation>Management|Migration|Storage|Display|VM</designation>
</network>
what do you say about having it as another /designation/ type?
it==VM?
the above looks ok to me.
(I really hope for a better element name than designation though)
11:52 a.m.
On 03/18/2012 10:39 AM, Itamar Heim wrote:
On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> On 03/18/2012 10:21 AM, Itamar Heim wrote:
>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>>> the question is Management/Migration/Storage/Display can be non-bridged?, if
so,
>>> <bridged>true|false</bridged> makes sense.
>>
>> bridge is an implementation detail at host level, hence the discussion is about
abstracting it from users.
>> a VM network doesn't have to have bridge at host level, for networks using
VMFex or SR-IOV
>
> <network>
> <designation>Management|Migration|Storage|Display|VM</designation>
> </network>
>
> what do you say about having it as another /designation/ type?
>
it==VM?
the above looks ok to me.
(I really hope for a better element name than designation though)
I'd avoid using /type/ as type usually applies on single variant,
/assignment/ maybe? nothing batter comes to my mind
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
2:48 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Michael Pasternak" <mpastern(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Sunday, March 18, 2012 10:39:48 AM
Subject: Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> On 03/18/2012 10:21 AM, Itamar Heim wrote:
>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>>> the question is Management/Migration/Storage/Display can be
>>> non-bridged?, if so,
>>> <bridged>true|false</bridged> makes sense.
>>
>> bridge is an implementation detail at host level, hence the
>> discussion is about abstracting it from users.
>> a VM network doesn't have to have bridge at host level, for
>> networks using VMFex or SR-IOV
>
> <network>
> <designation>Management|Migration|Storage|Display|VM</designation>
> </network>
>
> what do you say about having it as another /designation/ type?
>
it==VM?
the above looks ok to me.
(I really hope for a better element name than designation though)
Consider using "purpose" instead of "designation".
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
12:27 p.m.
On 03/18/2012 10:43 AM, Michael Pasternak wrote:
On 03/18/2012 10:21 AM, Itamar Heim wrote:
> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>> the question is Management/Migration/Storage/Display can be non-bridged?, if so,
>> <bridged>true|false</bridged> makes sense.
> bridge is an implementation detail at host level, hence the discussion is about
abstracting it from users.
> a VM network doesn't have to have bridge at host level, for networks using VMFex
or SR-IOV
<network>
<designation>Management|Migration|Storage|Display|VM</designation>
</network>
what do you say about having it as another /designation/ type?
Not sure I understand: Management can be bridge-less, Migration can be
bridge-less, Storage can be bridge-less, Display can be bridge-less, VM
is the only that perhaps today cannot be bridge-less, so I do think that
'<bridged>true|false</bridged>' makes some sense. However, I'd
generalize it to 'attachment' as I believe we'll have other types in the
future (Macvtap, SRIOV and friends), so something like
<attachment>bridge|sriov|macvtap|...</attachment>
Y.
3:31 p.m.
On 03/18/2012 11:27 AM, Yaniv Kaul wrote:
On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> On 03/18/2012 10:21 AM, Itamar Heim wrote:
>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>>> the question is Management/Migration/Storage/Display can be
>>> non-bridged?, if so,
>>> <bridged>true|false</bridged> makes sense.
>> bridge is an implementation detail at host level, hence the
>> discussion is about abstracting it from users.
>> a VM network doesn't have to have bridge at host level, for networks
>> using VMFex or SR-IOV
> <network>
> <designation>Management|Migration|Storage|Display|VM</designation>
> </network>
>
> what do you say about having it as another /designation/ type?
>
Not sure I understand: Management can be bridge-less, Migration can be
bridge-less, Storage can be bridge-less, Display can be bridge-less, VM
is the only that perhaps today cannot be bridge-less, so I do think that
'<bridged>true|false</bridged>' makes some sense. However, I'd
generalize it to 'attachment' as I believe we'll have other types in the
future (Macvtap, SRIOV and friends), so something like
<attachment>bridge|sriov|macvtap|...</attachment>
Y.
attachment would be at physical host level and could vary from host to host.
this is about intended allowed usages of the logical network across the
system
4:31 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Yaniv Kaul" <ykaul(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Sunday, March 18, 2012 2:31:45 PM
Subject: Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 11:27 AM, Yaniv Kaul wrote:
> On 03/18/2012 10:43 AM, Michael Pasternak wrote:
>> On 03/18/2012 10:21 AM, Itamar Heim wrote:
>>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>>>> the question is Management/Migration/Storage/Display can be
>>>> non-bridged?, if so,
>>>> <bridged>true|false</bridged> makes sense.
>>> bridge is an implementation detail at host level, hence the
>>> discussion is about abstracting it from users.
>>> a VM network doesn't have to have bridge at host level, for
>>> networks
>>> using VMFex or SR-IOV
>> <network>
>> <designation>Management|Migration|Storage|Display|VM</designation>
>> </network>
>>
>> what do you say about having it as another /designation/ type?
>>
>
> Not sure I understand: Management can be bridge-less, Migration can
> be
> bridge-less, Storage can be bridge-less, Display can be
> bridge-less, VM
> is the only that perhaps today cannot be bridge-less, so I do think
> that
> '<bridged>true|false</bridged>' makes some sense. However,
I'd
> generalize it to 'attachment' as I believe we'll have other types
> in the
> future (Macvtap, SRIOV and friends), so something like
> <attachment>bridge|sriov|macvtap|...</attachment>
> Y.
>
attachment would be at physical host level and could vary from host
to host.
this is about intended allowed usages of the logical network across
the
system
we should probably have a set of, so called, "usages" and not a single one. It
should give enough
flexibility for future usages with an easy upgrade.
something like:
<network>
<usages>management,display,VM</usages>
<network>
or:
<network>
<usages>
<usage>management</usage>
<usage>display</usage>
<usage>VM</usage>
</usages>
</network>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:54 p.m.
----- Original Message -----
From: "Roy Golan" <rgolan(a)redhat.com>
Sent: Sunday, March 18, 2012 3:31:46 PM
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Yaniv Kaul" <ykaul(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Sunday, March 18, 2012 2:31:45 PM
> Subject: Re: [Engine-devel] Bridgeless Networks api design
>
> On 03/18/2012 11:27 AM, Yaniv Kaul wrote:
> > On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> >> On 03/18/2012 10:21 AM, Itamar Heim wrote:
> >>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
> >>>> the question is Management/Migration/Storage/Display can be
> >>>> non-bridged?, if so,
> >>>> <bridged>true|false</bridged> makes sense.
> >>> bridge is an implementation detail at host level, hence the
> >>> discussion is about abstracting it from users.
> >>> a VM network doesn't have to have bridge at host level, for
> >>> networks
> >>> using VMFex or SR-IOV
> >> <network>
> >>
<designation>Management|Migration|Storage|Display|VM</designation>
> >> </network>
> >>
> >> what do you say about having it as another /designation/ type?
> >>
> >
> > Not sure I understand: Management can be bridge-less, Migration
> > can
> > be
> > bridge-less, Storage can be bridge-less, Display can be
> > bridge-less, VM
> > is the only that perhaps today cannot be bridge-less, so I do
> > think
> > that
> > '<bridged>true|false</bridged>' makes some sense. However,
I'd
> > generalize it to 'attachment' as I believe we'll have other types
> > in the
> > future (Macvtap, SRIOV and friends), so something like
> > <attachment>bridge|sriov|macvtap|...</attachment>
> > Y.
> >
>
> attachment would be at physical host level and could vary from host
> to host.
> this is about intended allowed usages of the logical network across
> the
> system
we should probably have a set of, so called, "usages" and not a
single one. It should give enough
flexibility for future usages with an easy upgrade.
something like:
<network>
<usages>management,display,VM</usages>
<network>
or:
<network>
<usages>
<usage>management</usage>
<usage>display</usage>
<usage>VM</usage>
</usages>
</network>
+1 on the last suggestion for representing network usages.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4623
days inactive
4634
days old
11 comments
6 participants
participants (6)
-
Einav Cohen -
Itamar Heim -
Michael Pasternak -
Oved Ourfalli -
Roy Golan -
Yaniv Kaul