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).