----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Alona Kaplan" <alkaplan@redhat.com> Cc: "Simon Grinberg" <simon@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, November 20, 2012 8:57:20 AM Subject: Re: [Engine-devel] Network Wiring
On 18/11/12 17:06, Alona Kaplan wrote:
<snip>
> purge a network while it is connected to VMs: Link-Down on > all > nics > and connect to the empty/no network. (Yes I know, it's not > par > of > the > feature, but you know someone will ask for it soon :))
It should not be hard to implement; In http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API I suggest passing no 'network' element to mean "connected to nothing".
I don't really understand why changing the link state to down is not enough? What is the added value of connecting "unwired" nic to a none network?
It is not a big deal of a difference, but the semantics of having no network is clear: you can run the VM if networks are missing, you can remove a network when the VM is running. When a VM is associated to a network, but its link state is down, the "right" semantics is more vague.
Indeed :)
Plus consider the use case of hooks providing the networking - they still need the engine to assign the MAC and type (like the CISCO hook). If you force a logical network on each nic, it means you have to invent a dummy LN and define it as non-required and set the global config to allow VMs to run on hosts that do not have this networks - Too messy. Though sometimes desirable since the network name may be a hint to the hook, there are cases it's not.
-> No LN means this VM can run on any host! with implicit assumption that someone else takes care of connecting it to the proper network.
Note that in this case you may still want the network with link state up and be allowed to bring the link up/down so it's for sure not the case as 'unwired/link down but connected to arbitrary network'
I"ve added "none" network option to the wiki. Any more comments? Do we have green light to start working on the feature?
+1 for the high level design naming and behavior.
+1 as well, I think we've converged here.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel