Open OpenNebulaSupport opened 5 years ago
Yep, agree, it's so crazy
I think we can come up with deferred attaching mechanizm. So if wm can't attach it right now, eg it is PENDING, it will do it later when it will come to RUNNING.
I'm not fully understading the problem, can you please @kvaps describe? My silly understanding is that all instances (I mean HA instances) of single VR should be identical in terms of networks they are configured into. All instances are then configured consistently (hot-attach / detach) via vrouter API, not by directly managing the vrouter's VMs. And, it's possible to hot-attach NIC to vrouter.
(Trying to understand how people use VR)
Hmm, I'm really confused why I left my comment to unrelated issue, mainly this is two different problems.
Problem 1 https://github.com/OpenNebula/one/issues/2921 (original issue): Imagine you have created external network, added there 8 different address ranges /24
, they can even be placed in different bridges. Thus if Virtual Router will use same virtual network but different address ranges, the VRRP protocol will not work.
See https://github.com/OpenNebula/one/issues/1344 for more information why we forced to place different subnets into single virtual network.
Problem 2 https://github.com/OpenNebula/one/issues/2921#issuecomment-462644370 - describes the problem of managing the virtual router, at the time when not all VMs are initialized yet. Eg. you create Virtual Router, instantiate 3 VMs from it, let's imagine that 2 of them scheduled fine but third one still in PENDING state, thus if you try to attach new nic now, you will get an error.
That's why I'm talking about some deferred attaching mechanism to attach/detach the NICs
Description Currently it is impossible to attach a nic to a virtual router vm.
Use case Different virtual router instances can have different networks, but they can share the same floating IP. So this will extend the functionality and won't just be useful for HA.
Interface Changes Core changes.
Progress Status