Skip to content

Feature: Hardware Devices

Marek Libra edited this page Sep 14, 2016 · 9 revisions

Feature: Hardware Devices

Goal:

HW Devices basic management.

User stories

Adam is an IT administrator in a mid-size company. He is part of a small team responsible for the company IT infrastructure, including Linux setup and performing server/workstation HW upgrades which usually consist of adding or replacing devices like graphics/network cards or hotplug/unplug disks. Once HW device is installed or removed, he checks whether this change is recognized by OS using command-line utilities. His wish is to have a nice-looking graphical tool listing devices for this verification.

Frank is Virtualization System Administrator in a large enterprise, responsible for oVirt environment. Part of his job is to manage VMs with host device passthrough via IOMMU Groups. To properly assign IOMMU Group to a VM, he needs to understand IOMMU Group particular devices belongs to.

James works in the same team as Frank. He's requested to reuse the host machine for other tasks then just virtualization but is not allowed to reboot it. He knows, devices used by a VM are associated to the VFIO driver (either manually or by oVirt, e.g.). So to fulfill his task he needs to unbind the device (like i915 graphics card) from the VFIO and bind it to it's corresponding driver so the device can start operate normally for other applications.

Suzan is the newest Frank's and James colleague. The company bought new servers to host virtual machines. The servers are equipped by SR-IOV devices, esp. network cards. As a part of the new host setup, she needs to spawn multiple virtual functions on these devices. Recently, she uses command-line utilities but she would prefer graphical interface to configure virtual functions. She would appreciate an easy way to see allowed maximum value as well. She performs similar task for vGPU.

B.J. works as Senior Virtualization Administrator in an investment company. The company runs high-performance VMs usually requiring access to specialized HW. For high performance computing is crucial to allign the VM topology with the topology of underlying host. The devices are associated to VM by IOMMU Groups, each of them belonging to a NUMA node or particular CPU. B.J. is responsible for fine-tuning of the computational environment. To properly pin pareticular VM in a virt management console to one or more NUMA nodes, B.J. needs to understand it's topology well.

Some of the tools used so far:

  • lspci, hwloc, lshw, lstopo, modinfo
    • tool for graphical representation, incl. interconnection of recent tooling output, is missing

Use Cases

By Adam: Review attached HW devices from OS perspective (Read-only) Prior: add/remove HW device (either hot (un)plug or with cold reboot)

  • see list of available devices
  • search for the [added|removed] device
  • if found:
    • verify (see) device details (bus, address, name, vendor, product, driver, IOMMU Group etc)
    • see what other devices are associated with the driver

By Frank: Review IOMMU Group(s) (Read-only)

  • select IOMMU Group
  • check list of it's devices
  • check details for particular device - driver, address, type, etc.
    • see what other devices belong to IOMMU Group

By James: Change device driver

  • select a device by it's class
  • review device's details, esp. driver
  • unbind from the driver
  • bind to new driver
    • TBD: automatic matching device-driver would be nice
    • if automatic driver preselection is not possible, user selects one from all available drivers

By Suzan: Configure device-specific functions

  • select a device
  • device type-specific operation is allowed, means:
    • Enter count of Virtual Functions to be spawned for SR-IOV
    • Enter count of vGPUs
    • TBD: other type-specific operations

By B.J.: Review the NUMA topology

  • In Cockpit: understand the HW NUMA topology (nodes, CPUs, IOMMU Groups, devices), Read Only
    • see available NUMA Nodes
    • see CPUs associated to particular node
    • see what IOMMU Groups are associated with the node
    • see what devices are in an IOMMU Group
  • Outside Cockpit:
    • pin a VM to particular node(s)

Design

The design will be similar to the 'Services' screen, it means:

  • On top of the page, exactly 1 bus can be selected to be displayed (PCI, USB, SCSI, ...)
    • Bus-specific view is rendered, for
    • PCI: The Group-By Selector (Options: Class | IOMMU Group | NUMA Topology)
      • by Class: panels listing basic device classes of >0 device count (like 'Network controller (3)' or 'Display controller (1)') panel body lists all devices of the class with details and buttons
        • expanding row to see further details special class reserved for the Unclassified devices (might happen)
      • by IOMMU Group:
        • table with sorting and searching, sorted by IOMMU Group by default
        • on row click: display detail
      • by NUMA Topology:
        • grid of cards for NUMA Nodes with basic stats (Count of CPUs, and devices)
        • on NUMA Node click, detail is displayed:
          • Tree of CPUs and IOMMU Groups
          • on IOMMU Group click:
            • IOMMU Group detail is displayed
    • other buses:
      • TBD: but the presentation will be bus-specific

Screenshots: TBD

Data Example

  • Device Class: Network controller, Display controller
  • IOMMU Group: numeric 0, 1, 2, ...
  • Device: RTL-8100/8101L/8139 PCI Fast Ethernet Adapter
  • Device Detail: vendor, product, driver, iommu group, class, pci address, capabilities or more

How To

  • sysfs as primary datasource
  • react/redux, probably no other libs are needed
  • new cockpit plugin will be added - accessed by 'Devices' from Cockpit's main menu
  • refresh TBD:
    • by effective polling
      • every N (like 10) secs check for added/removed
      • every X (like 60) secs reload details
    • or via udev
      • TBD: more research needed
      • DBUS, udevadm, udev filters

Implementation Roadmap

  • list of pci devices in the by-Class hierarchy
  • add IOMMU Group view for pci devices
  • add active actions, namely detach/reattach to a driver
  • add support for other buses (like usb or scsi)
  • add NUMA Topology view
Clone this wiki locally