Authors:

avatar of Dan Kenigsberg

Dan Kenigsberg

Feature pages are design documents that developers have created while collaborating on oVirt.

Most of them are outdated, but provide historical design context.

They are not user documentation and should not be treated as such.

Documentation is available here.

Unrestricted Network Names

Summary

Let users give any name to their network

Owner

  • Name: Dan Kenigsberg (Danken)

Detailed Description

Currently, oVirt limits the names of its networks to 15 alphanumeric characters. This limitation dates back to the ages where all networks were VM network, all were implemented by a Linux bridge, and the same name was used to identify the network and the Linux bridge implementing it on each host.

That has to change. 15 characters are not enough for humans; spaces, and other special characters are visually useful, and non-English speaking users would love to use their native alphabet in network names.

Benefit to oVirt

  • The limitations on network names seem arbitrary and annoy users.
  • When importing a network from Neutron, we’d like to refer to it with its Neutron-native name, not some partly-legible shorthand.
  • It’s plain wrong to expose Linux’s IFNAMSIZ all the way up to the GUI.

Dependencies / Related Features

Currently, the Engine/Vdsm API hinges on the network name, and assumes that (for VM networks) the created bridge would be named just like its network. Any solution must allow migration of VMs from existing hosts to hosts with this new feature enabled, as well as a seamless upgrade from an old clusterLevel to a clusterLevel supported unrestricted names.

Suggested Solution

We will make no change in the Engine/Vdsm API. This makes backward compatibility with running Vms and in upgraded hosts a non-issue.

A new field, “vdsm_name”, is to be added to the network entity. When a new network is added, its existing “name” has to be provided by the human actor. “name” is to be editable by the end user, and exposed as the name of the network over REST (as it is today); “vdsm_name” would be immutable once the network is attached to a host (similarly to “name”) and to be used only for Engine/Vdsm communication.

The new “vdsm_name” will match “name”, if “name” doesn’t exceed IFNAMSIZ and only contains ASCII characters (to ease debugging and backwards compatibility). Otherwise, the new “vdsm_name” is to be auto-generated by Engine according to a pattern

  onXXXXXXXXXXXXX

where XXXXXXXXXXXXX are 13 hexadecimal characters extracted from the UUID of the network.

As aforementioned, Engine/Vdsm communication will now be made via “vdsm_name”, while all intra Engine communication will remain via “name”. The discrepancy will be filled by using a “name” and “vdsm_name” mapping; communication to Vdsm from Engine will be preceded with looking up the relevant “vdsm_name” using “name”, and vice versa.

Upgrade

On upgrade, the “name” of existing networks would be copied into their “vdsm_name”. REST-based scripts and GUI users would not see a difference. However, they could now edit “name” with no Linux-based limitations.

UI considerations

The user interface currently takes advantage of the narrow name field for networks. Once we lift the restrictions, and allow names in languages such a Japanese which commonly requires wide text columns, we would have to make some UI adjustments. Possible tricks are: tooltip showing the complete name, adjustable tables, in-UI limitation on name lengths.

This would affect anywhere a network name shows up, and in particular:

  • the setup networks dialog
  • host interfaces sub-tab and vm interfaces sub tab
  • the Add/Edit vm dialog
  • the vm’s boot sequence dialog.
  • …

Debuggability Drawback

Currently, if a user has a connectivity issue regarding a network FOO on one of his hosts, he can easily look FOO up in Engine. Now this would become more difficult, as the host is no longer exposed to a human-legible name. We should supply means to alleviate this:

  1. A dedicated script (…ovirt-engine/bin/vdsm_to_network_name_map) that lists vdsm_name name per each network.
  2. Make it possible to look a network up based on its vdsm_name (onXXXXXXXXXXXXX) in the network tab and in via the search box
  3. Let users control vdsm_name of a network before any running VM is using it. The user may choose a more human-friendly name for the bridge.
  4. Another possible remedy is to expose visible_name to the host when setting or changing a network via setupNetwork. The human-visible name would be persisted as comments on the local host, and would be available for inspection by debuggers.

Documentation / External references