Activity

I'm escalating this issue, because a side effect keeps vms from starting. If you create a vpc with 1 vm, then stop the vm for a bit, the NIC/network gets cleaned up. Then the VM won't start because it's nic no longer has a broadcast URI.

Marcus Sorensen
added a comment - 18/Jun/13 01:28 I'm escalating this issue, because a side effect keeps vms from starting. If you create a vpc with 1 vm, then stop the vm for a bit, the NIC/network gets cleaned up. Then the VM won't start because it's nic no longer has a broadcast URI.

Network GC thread shuts down the network if it doesn't have running user vms for some time (network gc thread is controlled by network.gc.wait and network.gc.interval global configs). As a result of network shutdown, the nic associated with the guest network, is being unplugged from the VR (and corresponding nic is being removed). So this is by design.

So the bug here is - the removed nics should't be returned as a part of listRouters call as well as those nics should never be considered for cleanup once they are removed.

Alena Prokharchyk
added a comment - 18/Jun/13 23:32 Network GC thread shuts down the network if it doesn't have running user vms for some time (network gc thread is controlled by network.gc.wait and network.gc.interval global configs). As a result of network shutdown, the nic associated with the guest network, is being unplugged from the VR (and corresponding nic is being removed). So this is by design.
So the bug here is - the removed nics should't be returned as a part of listRouters call as well as those nics should never be considered for cleanup once they are removed.

Min, can you please take a look at this bug. Its related to the view system you've introduced for the VR. Although the VR's nic is removed, the entry for this nic is still present in the view table, so the API returns it back to the user - bug.

In the VPC the nics on the VR are dynamic, and can change with the time. The view should reflect those changes.

2) Marcus, the problem with the VPC removal (NPE for the VLAN) is caused by diff problem introduced by commit a49261c3b1f2d52d637f481e0bcff4b0d58d7b56. This commit changed getNicInNetwork in NetworkModelImpl to return nics that were marked as removed. So when we tried to remove the VPC, we've tried to access the removed nic entry. The problem was fixed with c1ad3b7974449f457a1cc4e50fe7af260d1c5bf6

3) I don't see the problems with the VM start after the network was initially shutdown, in the latest build. After the network is shutdown (remember, shutdown happens only when there are no running user vms in the system), and re-implemented again with the new vlan as a part of new user vm start, both user vm and vr nics were configured with the new vlan.