Bug 1054730

Summary:	Edit VM dialog - NIC selection issues
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Michal Skrivanek <michal.skrivanek>
Component:	ovirt-engine-webadmin-portal	Assignee:	Lior Vernia <lvernia>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Michael Burman <mburman>
Severity:	medium	Docs Contact:
Priority:	low
Version:	3.3.0	CC:	bazulay, ecohen, gklein, iheim, masayag, nyechiel, rbalakri, Rhev-m-bugs, yeylon
Target Milestone:	---
Target Release:	3.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	network
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-17 17:17:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1142923, 1156165

Description Michal Skrivanek 2014-01-17 11:01:10 UTC

in is30
(1)
Edit VM dialog, go to network section in General tab
click on the dropdown
then click outside of the list
first item get selected anyway, but the [+] [-] is not updated and the description text above doesn't change

(2)
if I use the last NIC in the list (e.g. on new VM the line which is there by default), save, reopen the dialog I will see another NIC line added (greyed out).
Looks inconsistent

(3)
I can create a gap in numbering when I have nic1, nic2; then remove nic1. The next available nic added is going to be nic3. Since the NIC name can't be changed in this dialog we should keep it sequential…or maybe just add ordering 1., 2., 3., just so it's clear. 
By default the naming suggests it should be ordered and it looks weird when it's not (order is based on MAC)
or maybe just explain somewhere somehow:)

(4)
dialog assumes the newly added NIC will get higher MAC as it is the last in the list, but it can get lower and on subsequent Edit VM that particular NIC will be placed somewhere else, according to MAC order

(5)
creating nic100 breaks the layout. With longer interface name this gets even more ugly

(6)
Network Interfaces subtab not in sync with changes done in Edit VM until the next subtab refresh. Allows me to edit removed interfaces, add conflicting nics (nic2 added in Edit VM, nic2 suggested as a new name in "New" in Network Interfaces). Ther's error dialog in all cases when tried to save it, not a big deal

Comment 1 Michal Skrivanek 2014-01-17 11:04:45 UTC

(7) in addition to (6) above, there is an issue with out of sync actions, When the NIC is removed in Edit VM and then removed in Network Interfaces before refresh it leads to an event:
	2014-Jan-17, 12:02 Interface <UNKNOWN> (<UNKNOWN>) was removed from VM xyz. (User: mskrivan)

Comment 3 Lior Vernia 2014-01-29 08:15:23 UTC

1. Duplicate of Bug 1042872, should be fixed by now.
2. Pretty much duplicate of Bug 1020861, to be fixed soon.
3. I can't understand if this is an argument against the gap or against the ordering. I'm assuming against the gap, because the ordering is the subject of article 4, in which case I'm not sure how the second paragraph is related. Please verify that I got it right.
4. This is a delicate matter, as I'm sure you're aware. When creating a VM from blank this should be fine now. For other cases I will see if it's possible to sort by MAC or something.
5. Duplicate of Bug 1029973, to be fixed.
6. To be fixed.

Comment 4 Lior Vernia 2014-04-17 13:48:00 UTC

Most articles above have been tended to or will be tended to as part of other bugs. Remaining are:

3. This, in my opinion, is not a bug. It's just the algorithm to suggest new names for NICs, to always take the highest numbering and add one. It's just as correct as taking the lowest free number.

6 & 7. I don't know if can be fixed at the moment. It requires the VM dialog to notify the interfaces subtab that it needs to refresh, but the VM dialog isn't aware of that subtab (as it's opened from the main tab). I don't mind returning this to tjelinek to try to figure out how to do this, but to me it seems low priority.

Comment 5 Lior Vernia 2014-08-24 14:37:30 UTC

I think 6 & 7 have been fixed for a while due to the auto-refresh mechanism implemented by Alexander Wels, so this might be ready to close...

Comment 6 Michael Burman 2014-09-07 11:19:40 UTC

Verified on - 3.5.0-0.10.master.el6ev

Comment 7 Eyal Edri 2015-02-17 17:17:03 UTC

rhev 3.5.0 was released. closing.