[Engine-devel] Bridgeless Networks api design
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
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
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
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
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
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)
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
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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.
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
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message ----- From: "Roy Golan" <rgolan@redhat.com> Sent: Sunday, March 18, 2012 3:31:46 PM
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (6)
-
Einav Cohen -
Itamar Heim -
Michael Pasternak -
Oved Ourfalli -
Roy Golan -
Yaniv Kaul