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.
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).
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.
Cheers,
Stef
_______________________________________________
cockpit-devel mailing list
cockpit-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahost...