Bug 909820 - [engine][networks] Don't block removing/updating network "used" by host
Summary: [engine][networks] Don't block removing/updating network "used" by host
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 3.2.0
Assignee: lpeer
QA Contact: Meni Yakove
URL:
Whiteboard: network
Depends On:
Blocks: 948448
TreeView+ depends on / blocked
 
Reported: 2013-02-11 08:22 UTC by Mike Kolesnik
Modified: 2016-02-10 19:47 UTC (History)
9 users (show)

Fixed In Version: sf13.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Network
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 11968 0 None None None Never
oVirt gerrit 12527 0 None None None Never

Description Mike Kolesnik 2013-02-11 08:22:46 UTC
Description of problem:
Currently it's possible to detach a network that is "used" by a host from the cluster.
Since the network is provisioned on the hosts by name and no other ID, it is possible that the network be detached and become "unmanaged" on the host.

Hence, it makes little sense to block this on the DC level since the user can simply detach the network and then remove it.


Version-Release number of selected component (if applicable):


How reproducible:
100%


Steps to Reproduce:
1. Setup a network on the host
2. Try to remove the network from the DC
3.
  
Actual results:
Removal will fail since the network is "used" by the host


Expected results:
Removal should succeed.


Additional info:

Comment 1 Simon Grinberg 2013-02-12 11:27:59 UTC
Just note this is a complex operation:
1. Remove from DC
2. Remove from all clusters 
3. Remove from the configuration per all the hosts.

Only then it becomes un-managed.

Now for VM-Network which is assigned to VMs it may be even more complex - here we may need to block. 

If we don't then:
If all VMs that are attached to the network are down - remove the network from all  the VMs NICs and make them "None"
If VMs are running, I have no idea how this could be solved. You can do as the above, but I don't see the engine sending re-wire command for each VM moving them to the null network.

Comment 2 Muli Salem 2013-02-12 15:19:39 UTC
(In reply to comment #1)
> Just note this is a complex operation:
> 1. Remove from DC
> 2. Remove from all clusters 
> 3. Remove from the configuration per all the hosts.
> 
> Only then it becomes un-managed.
> 
> Now for VM-Network which is assigned to VMs it may be even more complex -
> here we may need to block. 
> 
> If we don't then:
> If all VMs that are attached to the network are down - remove the network
> from all  the VMs NICs and make them "None"
> If VMs are running, I have no idea how this could be solved. You can do as
> the above, but I don't see the engine sending re-wire command for each VM
> moving them to the null network.

I'm not sure what you mean. When the network is removed from the DC, it is removed from the cluster, but remains on the host as an unmanaged network.

Regarding a network that is assigned to a VM, I agree we should continue blocking network removal.

Comment 3 Simon Grinberg 2013-02-13 12:44:13 UTC
(In reply to comment #2)
> I'm not sure what you mean. When the network is removed from the DC, it is
> removed from the cluster, but remains on the host as an unmanaged network.

Yes, now that you say so, I remember that we do not have 'host configuration' saved in the DB, thus the only indication for managed/un-managed id it's existence in the cluster

The problem is that it's a wrong approach and this is why it takes time for me to account for that.  


> Regarding a network that is assigned to a VM, I agree we should continue
> blocking network removal.

Comment 4 Muli Salem 2013-02-20 15:02:32 UTC
Behaviour of Update network will be modified as well to allow updating a network when network is assigned to a host. The network will simply become unsynced, and admin will be able to sync the network via Setup Networks.

Comment 6 Meni Yakove 2013-04-14 12:41:43 UTC
Verified on rhevm-3.2.0-10.19.beta2.el6ev.noarch

Comment 7 Itamar Heim 2013-06-11 09:40:17 UTC
3.2 has been released

Comment 8 Itamar Heim 2013-06-11 09:40:18 UTC
3.2 has been released

Comment 9 Itamar Heim 2013-06-11 09:53:44 UTC
3.2 has been released


Note You need to log in before you can comment on or make changes to this bug.