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.
> 


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
cockpit-devel mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]

Reply via email to