Bug 907469
| Summary: | Nics sorting based on time added | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Jiri Belka <jbelka> | ||||
| Component: | ovirt-engine | Assignee: | Nobody's working on this, feel free to take it <nobody> | ||||
| Status: | CLOSED DEFERRED | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 3.2.0 | CC: | acathrow, dyasny, iheim, lpeer, Rhev-m-bugs, sgrinber, yeylon, ykaul | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | network | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-02-05 15:51:39 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: | |||||||
| Attachments: |
|
||||||
i remember a long thread around this. simon? One little comment: I know very well that supported OSes are RHELs and Windows only but upstream could target more guest OSes. Some OSes (guests) do not have ability to rename your ifaces inside OS (guest) or define your own iface names based on hw addr (iirc BSD systems, maybe Windows too?), thus these OSes by default have ifaces named based on physical location (pci location). Changing mac would shift in fact physical location... (In vSphere changing mac doesn't shift physical location of the nic, IIRC.) (In reply to comment #1) > i remember a long thread around this. simon? We had similar issue with host nics - Bug 883269. And then with logical networks, etc... I can't find the BZ, probably an old BZ, but MAC sorting was done per specific request to avoid randomness while nic names are meaningless. Most customers don't care one way or the other as long as it's persistent and there is no 'right' way to do it. Order based on 'time of adding' required changes to the DB (add insertion date) and it still not unnecessary the correct order to present. Farther more, a change of order will happen more often in this case since changing MAC address requires unplug and plug - and again will raise a question, what is the 'add' date the original date the device had been created or the plug date. Considering that unplug/plug sequence may also change the PCI address (no reservation if I recall correctly) then de-facto it's like a new device so should we change presentation order every plug/unplug even if MAC was not changed? To sum up, unless customers complain I don't see any reason to change behavior. Closing as deferred, please reopen if it become relevant |
Created attachment 692730 [details] nicX - X corresponds to sequential number when I added them Description of problem: I find very strange nics are (auto)sorted based on hw address of the nics. We could discuss hours how sysadmin can change nics listing/order in guest OS, but still on RHEVM level, it is strange that changing hw adress of a nic changes its order in nics list, which means also the order in 'virsh dumpxml $no' (that is virtualized physical location). I would expect same funcionality as when I add disk. In 'virsh dumpxml $no' I see them in the order I added them. Version-Release number of selected component (if applicable): sf5 How reproducible: 100% Steps to Reproduce: 1. Create 3 nics - nic1, nic2, nic3 2. Check order 3. If order was sequential, change mac of nic3 to be from lower mac range then the rest, then check order Actual results: nics order is auto-sorted based on hw address Expected results: nics order is based on time when I add them. Additional info: