cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: what's the reason for the placeholder nic in VPC/VR?
Date Wed, 09 Oct 2013 20:31:11 GMT
Valid question and concern. Here is the history:

V1.0 No notion of the NaaS yet, no networks/nics tables; guest type and
all network related info - public ip, mac, netmask - for the VR is stored
in domain_router table

V2.1 NaaS added. Although each router has entries in the nics table, and
its possible to retrieve the guest network info from there, network_id
holding guestNetworkId for the VR, was added to the domain_router table. I
can't recall who added it, and the reason why it was done this way, but
most of the code for the VR reads guest network info from
domain_router.network_id. And it's always 1-1 relationship between VR and
guest network. We also continue storing public_ip/netmask/mac_address of
the VR public nic in domain_router table.

V3.0 VPC was added. Now VR can have more than one network, so we created
this table to maintain VR to guest network refs there, and moved
network_id to VR ref from domain_router table to router_network_ref. I
agree the right fix should have been - change all the code reading
network_id info from domain_router, to read it from nics instead. But back
then we just needed the quick fix for VPC to support 1 VR - n guest
networks case, and didn't want to introduce the regressions in existing
code, so we've done it this way.

Following needs to be fixed (DB upgrade too)

* get rid of router_network_ref table and always retrieve guest network
info from nics table.
* vm_instance/domain_router/console_proxy/secondary_storage_vm table - get
rid of 
s fields that exist since 1.0. Again, because all this info can be
retrieved via nics. And right now we just duplicate this data across
vm_instance/domain_router/console_proxy/secondary_storage_vm tables, and
sometimes read it from there, and sometimes from nics. We should always
read it from nics, as this table has the most reliable and current info.


On 10/9/13 12:59 PM, "Darren Shepherd" <> wrote:

>Okay, that makes sense.  Another random question.  Why does
>router_network_ref exist?  Is it not sufficient to just find a
>DomainRouter VM that has a nic attached to the network?  It seems to
>be for RvR?  Is that right?  Still I don't understand why the table is
>On Wed, Oct 9, 2013 at 9:50 AM, Alena Prokharchyk
><> wrote:
>> I've just tested it on the latest master, don't see placeholder nic
>> created for the VPC VR.
>> In addition to the case Murali explained, placeholder nic is being
>> per Shared network case using VR as DHCP provider. Its done to preserve
>> the same ip address for the case when VR is being expunged/re-created
>> during the network restart/Vrdestroy. As a result of expunge VR its nic
>> being cleaned up - and ip released - , so we had to make sure that the
>> VR would get the same ip. More details are in
>> 26b892daf3cdccc2e25711730c7e1efcdec7d2dc, CLOUDSTACK-1771.
>> -Alena.
>> On 10/9/13 2:57 AM, "Murali Reddy" <> wrote:
>>>On 09/10/13 11:33 AM, "Darren Shepherd" <>
>>>>Why is a placeholder nic created before the VRs for the VPC are
>>>Generally place holder nic is used in cases where cloudstack uses a
>>>IP from the guest subnet, but ip is not used for any VM nic's. In most
>>>the external network devices, needs a subnet IP from the guest network
>>>CIDR, cloudstack creates a place holder nic and allocates a subnet ip.

View raw message