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@redhat.com To: cockpit-devel@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@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....