Hi Martin,
I work in storage and I'm afraid I don't know that much
about virtualization and its requirements.
I took a look at the output of nodedev-list on my current
storage setup and it was pretty large:
[root@megadeth pydevDAG]# virsh nodedev-list | wc -l
425
My configuration is larger than a personal machine,
but small for a customer setup.
Also, as a storage person I'm pretty biased, to me all those
devices in the output of nodedev-list really only exist
to connect to some physical storage medium :)
So, given that you had, say @400 devices, and you didn't
want to click on all of them, could you give a specific
use case from a virtualization point of view?
I know that you can filter the devices by capability
with nodedev-list and I imagine that would be quite useful
in Cockpit with 400 of them :)
- mulhern
----- Original Message -----
> From: "Martin Polednik" <mpolednik(a)redhat.com>
> To: cockpit-devel(a)lists.fedorahosted.org
> Sent: Tuesday, March 22, 2016 10:22:10 AM
> Subject: idea/rfc: device screen in cockpit
>
> Hello,
>
> 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.
>
> Thanks,
> mpolednik
> _______________________________________________
> cockpit-devel mailing list
> cockpit-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahost...
>