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

Reply via email to