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
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
_______________________________________________
cockpit-devel mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
