On 22/03/16 15:37 -0400, Anne Mulhern wrote:
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.
It is large even for customer setups we have seen over here. :)
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 :)
Good point! Yes, it makes sense to filter them by capability of some
sorts: PCI, USB, SCSI separation is the initial one. I would most
likely think of some search on top of that, by lun, pci address, scsi
host or similar.
The idea and virtualization use case is to really form something like
more interactive lspci and sysfs control. Very specifically, when
using direct device assignment (meaning, assigning *physical* hardware
to *virtual* machine), the device must be bound to specific driver -
vfio_pci in PCI's case. After destroying the machine, we have decided
not to rebind the device back to host's driver due to possible issues
(rebinding GPU can lead to host reboot).
This is where this cockpit extension could help us and our customers -
cloudy management applications don't really want to deal with a single
device on a host. But redirecting user to cockpit interface to handle
the machine - that is more reasonable.
Similar case is SR-IOV or MR-IOV (afaik storage technology :) ). Users
can configure number of virtual functions for physical devices and use
them for direct assignment. SR-IOV is mostly seen in networking
(splitting single NIC between multiple machines), where MR-IOV should
be storage tech (haven't worked with that yet).
The use cases that I know of are mostly focused on PCI devices though,
I'm not sure what SCSI/USB devices offer in sysfs space.
>- 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...
>>
>_______________________________________________
>cockpit-devel mailing list
>cockpit-devel(a)lists.fedorahosted.org
>https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted.org