On 23.03.2016 18:37, Martin Polednik wrote:
On 23/03/16 18:03 +0100, Stef Walter wrote:
> On 23.03.2016 15:34, Martin Polednik wrote:
>>>> I have an idea for cockpit, but before thinking it further, I'm
>>>> interested in hearing your opinions. I am oVirt developer mostly
>>>> dealing with system stuff and this is something that could be useful
>>>> in virtualization while also providing utility for administrators
>>>> using cockpit.
>>>>
>>>> The idea is about new tab/plugin (not sure of the terminology) called
>>>> 'devices', that would allow access to (hardware) devices as
exposed by
>>>> sysfs. The interface could be similar to 'Services' tab/plugin,
>>>> showing a list of device names created from their physical location,
>>>> similarly to libvirt's nodedev-list.
>>>>
>>>> After clicking on the name, new screen would be presented, showing
>>>> additional information such as
>>>>
>>>> * physical address,
>>>> * driver in use,
>>>> * special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports,
>>>> vports),
>>>> * iommu group (possibly clickable to reveal all devices in given
>>>> group),
>>>> * vendor, vendor id, product, product id.
>>>>
>>>> Additionally, it makes sense to allow some basic operations:
>>>>
>>>> * unbinding from host driver, binding it to specific one (useful for
>>>> local vfio-pci testing),
>>>> * reattaching it back (one use case is that
>>>> oVirt does not reattach devices automatically due to possible
>>>> issues, needs user intervention),
>>>> * setting numvfs, vports,
>>>> * ... ?
>>>>
>>>> Do you find ideas above reasonable for cockpit? It is mostly in idea
>>>> phase, and builds on development and requirements of oVirt. I
>>>> personally believe that this could be useful for broader audience.
>
> I think this makes a lot of sense. It's the sort of functionality people
> expect when interacting with a specific server.
>
> Is sysfs enough of an API to deliver a decent experience?
Combination of sysfs and udev to be accurate. I haven't dug into
cockpit internals (yet), but as long as bash access is available it is
possible to gather all the required information.
Great. Do these change while running the server much? If so you probably
want to find a way to detect that something has changed, wait a few
seconds, and run things again to update the display.
Example (SR-IOV capable Intel 82576 NIC):
# basic information
# pwd
/sys/bus/pci/devices/0000:05:00.0
# udevadm info $(pwd)
P: /devices/pci0000:00/0000:00:09.0/0000:05:00.0
E: DEVPATH=/devices/pci0000:00/0000:00:09.0/0000:05:00.0
E: DRIVER=igb
E: ID_MODEL_FROM_DATABASE=82576 Gigabit Network Connection (NC362i
Integrated Dual port Gigabit Server Adapter)
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: MODALIAS=pci:v00008086d000010C9sv0000103Csd0000323Fbc02sc00i00
E: PCI_CLASS=20000
E: PCI_ID=8086:10C9
E: PCI_SLOT_NAME=0000:05:00.0
E: PCI_SUBSYS_ID=103C:323F
E: SUBSYSTEM=pci
E: USEC_INITIALIZED=994474b
# SR-IOV control
# ls sriov_*
sriov_numvfs sriov_totalvfs
# cat sriov_numvfs
0
# cat sriov_totalvfs
7
# echo 5 > sriov_numvfs
# cat sriov_numvfs
5
# IOMMU group
# readlink iommu_group
../../../../kernel/iommu_groups/15
# cat vendor
0x8086
# cat device
0x10c9
# driver for unbinding, we have all the required information (sorry,
# I'm using that nic!)
# readlink driver
../../../../bus/pci/drivers/igb
Additionally, the devices are exposed as a tree and can therefore be
displayed that way (I'm not sure about UI/UX in that case).
Once you have a proof of concept working, it would be good to work on
the design. Here's how new features land, in case you haven't seen it:
https://github.com/cockpit-project/cockpit/wiki/New-Features
Stef
This is pretty much what libvirt does when dealing with devices -
making it more than enough to do anything virtualization and device
management requires. Similar information can be gathered about SCSI
and USB devices as far as I know.