Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1315878

Summary:	NICs are presented to the VM in alphabetical ordering (so with 10 NICs and more - nic1, nic10, nic2 ... whereas you'd expect nic1, nic2, ...) - need to natural order them
Product:	[oVirt] ovirt-engine	Reporter:	PeterZ <zsiga09>
Component:	Frontend.WebAdmin	Assignee:	Yevgeny Zaspitsky <yzaspits>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Meni Yakove <myakove>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.6.3.3	CC:	acanan, bugs, danken, mburman, ylavi, zsiga09
Target Milestone:	ovirt-4.1.0-beta	Flags:	rule-engine: ovirt-4.1+
Target Release:	4.1.0.2
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	4.1.0.1-0.4.master.20170119130917.git6eac575	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-02-01 14:41:56 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:

Description PeterZ 2016-03-08 20:58:42 UTC

Description of problem:

Adding 10 nics to a VM makes ovirt presenting them to VMs in alphabetical order. (ie nic1, nic10, nic2, nic3, etc) So on the VM, nic2 actually becomes nic3.

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


How reproducible:
Easy

Steps to Reproduce:
1. Add 10 nics to vm
2. Connect nic2 to networkA on ovirt
3. Configure networkA on the VM on nic3
4. Observe network connectivity on nic3
5. Configure networkA on the Vm on nic2
6. Network connectivity fails

Actual results:
Shouldn't work on nic3 on the VM, and should work with nic2

Expected results:
Connectivity should be available on nic2

Additional info:

Comment 1 PeterZ 2016-03-08 21:02:42 UTC

Actual version is 3.6.3.4, it's just not showing in the dropdown..

Comment 2 Dan Kenigsberg 2016-03-08 22:02:45 UTC

May I ask whether you have a real use case for 10 vnics? Can you elaborate on it?

Comment 3 PeterZ 2016-03-08 22:43:10 UTC

My firewall team said that they have license for 10 interfaces and they don't want to reboot the firewalls for every addition, so let's just provision all of them at once. 
I realize it's an edge case, also for now they're ok with 9nics, so I'm good if you deem this not worthy to fix.

Comment 4 Sandro Bonazzola 2016-05-02 09:55:09 UTC

Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 5 Yaniv Lavi 2016-05-23 13:16:44 UTC

oVirt 4.0 beta has been released, moving to RC milestone.

Comment 6 Yaniv Lavi 2016-05-23 13:23:09 UTC

oVirt 4.0 beta has been released, moving to RC milestone.

Comment 7 Dan Kenigsberg 2016-06-28 15:02:44 UTC

oVirt allocates mac addresses to vNICs based on their alphanumeric order (ReorderVmNicsCommand.java). I think that you can work around this surprising sort by manually editing the nic names (nic1->nic01 etc) when you add the vNICs. 

Would you try that out?

(I am a bit reluctant to add a more complex heuristic for sorting vnics, such as one were if all vnics has nic<number> names they are sorted based on <number>)

Comment 8 Yevgeny Zaspitsky 2017-01-18 10:19:16 UTC

The proposed/implemented solution is sorting vNics in ReorderVmNicsCommand by the natural order. The command could be activated by one of the following flows:
* UI - Add all vNics in the create VM dialog, after VM is created UI doesn't expose an interface to the command, so a subsequent vNic manipulation would not be covered by the change
* REST API - vnics re-order could be activated at any stage prior the VM activation

Comment 9 Michael Burman 2017-01-22 14:29:28 UTC

Verified on -  4.1.0.1-0.1.el7

Comment 10 Red Hat Bugzilla 2023-09-14 03:19:08 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days