Hi,
I would like to renew the effort on Host Devices for Cockpit [1].
To move forward, let's implement it step by step while opening brand new PR picking just a subset of the already implemented functionality [1] while adjusted to generally acceptable form.
Initial implementation would meet: - PCI support only - initially read-only: just the List of devices by their Class (according to [2]) - example: by Audio device, Ethernet Controller, etc
- data source: sysfs - make use of backward-compatible lspci for data preprocessing (especially manipulation with HW database) - monitor for changes by listening kernel uevents
Follow-ups will lead to [3] scope: - for pci, active actions are allowed for selected device classes, one PR per each: - (un)bind VFIO driver - configure SR-IOV network cards - vGPU configuration
- additional view by Driver - What devices is the driver bound to?
- additional view by IOMMU Groups - For server fine-tuning, what devices are within single IOMMU Group?
- support for other buses, i.e. USB or SCSI - their views are independent on each other due to fundamental differences
Please let me know your thoughts. Thanks, Marek
[1] https://github.com/cockpit-project/cockpit/pull/5523 [2] http://pci-ids.ucw.cz/ [3] https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-Devices
On 2017-10-19 11:44, Marek Libra wrote:
Hi,
I would like to renew the effort on Host Devices for Cockpit [1].
To move forward, let's implement it step by step while opening brand new PR picking just a subset of the already implemented functionality [1] while adjusted to generally acceptable form.
Initial implementation would meet:
- PCI support only
- initially read-only: just the List of devices by their Class
(according to [2]) - example: by Audio device, Ethernet Controller, etc
Hi, and sorry it took a while before I replied. I agree that this is a good initial scope, and it's better to start small and grow it as we go. I went over a bunch of internal support tickets regarding hardware detection. One common problem seems to be to figure if a slot is used or not, and what network card is using what slot. I must admit I'm having the same issue with my own wardrobe server. I literary would need to open it and look today. I have no idea exactly how to parse the cli commands. So what do you think about this use case: "As a sysadmin, I want to know if my server has the capability for another network card."
(and the more detailed version) "John needs to spin up a new VM to host a database. He expect the network traffic to the VM to be rather heavy, so he wants to dedicate a network card just for this VM. Problem is that all the network cards in the server are already in use by other VMs. He will have to buy a new card for that, but the server is in the server room, in the basement of the other office building, and he would rather not run over there and open the machine to find out. Hence he wants to check it remotely, but he's not seasoned enough with Linux to know what CLI command to use, or how to use it."
- Andreas
On 22.11.2017 06:31, Andreas Nilsson wrote:
On 2017-10-19 11:44, Marek Libra wrote:
Hi,
I would like to renew the effort on Host Devices for Cockpit [1].
To move forward, let's implement it step by step while opening brand new PR picking just a subset of the already implemented functionality [1] while adjusted to generally acceptable form.
Initial implementation would meet:
- PCI support only
- initially read-only: just the List of devices by their Class
(according to [2])
- example: by Audio device, Ethernet Controller, etc
Hi, and sorry it took a while before I replied. I agree that this is a good initial scope, and it's better to start small and grow it as we go. I went over a bunch of internal support tickets regarding hardware detection. One common problem seems to be to figure if a slot is used or not, and what network card is using what slot. I must admit I'm having the same issue with my own wardrobe server. I literary would need to open it and look today. I have no idea exactly how to parse the cli commands. So what do you think about this use case: "As a sysadmin, I want to know if my server has the capability for another network card."
(and the more detailed version) "John needs to spin up a new VM to host a database. He expect the network traffic to the VM to be rather heavy, so he wants to dedicate a network card just for this VM. Problem is that all the network cards in the server are already in use by other VMs. He will have to buy a new card for that, but the server is in the server room, in the basement of the other office building, and he would rather not run over there and open the machine to find out. Hence he wants to check it remotely, but he's not seasoned enough with Linux to know what CLI command to use, or how to use it."
These are good use cases. I'll imagine we'll tackle them after the initial basic support is in? Getting the initial support for something in, allows others to then contribute more easily.
Stef
On 2017-11-23 14:13, Stef Walter wrote:
These are good use cases. I'll imagine we'll tackle them after the initial basic support is in? Getting the initial support for something in, allows others to then contribute more easily.
Well, I think the first PR needs to solve a problem for someone. I'm happy to change the use case to something else, but it needs to be a use case. Otherwise it's just a listing of PCI devices, because we can list PCI devices... If mapping an extension card to it's bus is too hard to do, then we could focus the story around figuring out the PCI Address and Hardware Address, before adding them to the hosts GRUB configuration as the vfio-pci.ids flag to enable PCI passthrough to a VM. So it would become "As a sysadmin, I need to figure out the address to a network card, so I can tweak the boot loader of the host, in order to give a VM direct access to that device" You can get _a lot_ of information out of the PCI listing, so knowing what the end goal is helps with deciding exactly what to show greatly. - Andreas
On 2017-11-24 14:17, Andreas Nilsson wrote:
So it would become "As a sysadmin, I need to figure out the address to a network card, so I can tweak the boot loader of the host, in order to give a VM direct access to that device"
So I'm still a bit uncertain about the exact goal, but I put this design together, for answering the most basic case of "What devices are on my system". https://raw.githubusercontent.com/cockpit-project/cockpit-design/2dcca8634b4... It only does a straight down, simple listing of PCI devices. Let me know what you think! - Andreas
Andreas, thanks for that!
So far it makes sense for me. Tthe covered use-case is really bare minimum anyway - we will definitely need to go farther.
Seems like we agreed on the classification according to [2].
I'm just contemplating positioning the page under the System >> Hardware link. It might be difficult for newbies to find it. I am not against it - just thinking aloud. What are the +/- of putting it as a new item in the left-side menu?
Secondly, due to expected amount of devices within single host, I still think we should filter by class. Either via expandable lists (by class) or by filtering/sorting.
Just to know where we are heading to in follow-ups, what will be future use cases? My vision:
- additional details of a device - will be selected upon use-cases - (un)bind VFIO driver - configure SR-IOV network cards - vGPU configuration - USB bus - SCSI bus
Marek
On Wed, Dec 13, 2017 at 4:25 PM, Andreas Nilsson lists@andreasn.se wrote:
On 2017-11-24 14:17, Andreas Nilsson wrote:
So it would become "As a sysadmin, I need to figure out the address to a network card, so I can tweak the boot loader of the host, in order to give a VM direct access to that device"
So I'm still a bit uncertain about the exact goal, but I put this design together, for answering the most basic case of "What devices are on my system". https://raw.githubusercontent.com/cockpit-project/cockpit-de sign/2dcca8634b4b0ec5f9ff7254b29cc6578fda0fcd/devices/devices.png It only does a straight down, simple listing of PCI devices. Let me know what you think!
- Andreas
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org
Andreas, does this use the listing view, so that once additional features (perhaps even per device) can be added when expanding or navigating to the view of a device?
Stef
On 14.12.2017 03:05, Marek Libra wrote:
Andreas, thanks for that!
So far it makes sense for me. Tthe covered use-case is really bare minimum anyway - we will definitely need to go farther.
Seems like we agreed on the classification according to [2].
I'm just contemplating positioning the page under the System >> Hardware link. It might be difficult for newbies to find it. I am not against it - just thinking aloud. What are the +/- of putting it as a new item in the left-side menu?
Secondly, due to expected amount of devices within single host, I still think we should filter by class. Either via expandable lists (by class) or by filtering/sorting.
Just to know where we are heading to in follow-ups, what will be future use cases? My vision:
- additional details of a device
- will be selected upon use-cases
- (un)bind VFIO driver
- configure SR-IOV network cards
- vGPU configuration
- USB bus
- SCSI bus
Marek
On Wed, Dec 13, 2017 at 4:25 PM, Andreas Nilsson <lists@andreasn.se mailto:lists@andreasn.se> wrote:
On 2017-11-24 14:17, Andreas Nilsson wrote: So it would become "As a sysadmin, I need to figure out the address to a network card, so I can tweak the boot loader of the host, in order to give a VM direct access to that device" So I'm still a bit uncertain about the exact goal, but I put this design together, for answering the most basic case of "What devices are on my system". https://raw.githubusercontent.com/cockpit-project/cockpit-design/2dcca8634b4b0ec5f9ff7254b29cc6578fda0fcd/devices/devices.png <https://raw.githubusercontent.com/cockpit-project/cockpit-design/2dcca8634b4b0ec5f9ff7254b29cc6578fda0fcd/devices/devices.png> It only does a straight down, simple listing of PCI devices. Let me know what you think! - Andreas _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org <mailto:cockpit-devel@lists.fedorahosted.org> To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org <mailto:cockpit-devel-leave@lists.fedorahosted.org>--
Marek Libra
senior software engineer
Red Hat Czech
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org
On 2017-12-14 09:05, Marek Libra wrote:
Andreas, thanks for that!
So far it makes sense for me. Tthe covered use-case is really bare minimum anyway - we will definitely need to go farther.
Seems like we agreed on the classification according to [2].
I'm just contemplating positioning the page under the System >> Hardware link. It might be difficult for newbies to find it. I am not against it - just thinking aloud. What are the +/- of putting it as a new item in the left-side menu?
Yeah, I'm not sure what solution is best here. During the usability testing of the Software Updates that we did this summer, we noticed that some participants started having issues finding things in the sidebar when we had more than 15+ items in it. But, as you say, only having the System >> Hardware link could pose a problem with discoverability as well. I think the easiest solution is to do some more usability testing once we have the Hardware page in, so we'll see what solution is best. Provided it's easy to move, coding-wise.
Secondly, due to expected amount of devices within single host, I still think we should filter by class. Either via expandable lists (by class) or by filtering/sorting.
Filtering sounds like a good idea to me! I'll add it
Just to know where we are heading to in follow-ups, what will be future use cases? My vision:
- additional details of a device
- will be selected upon use-cases
- (un)bind VFIO driver
- configure SR-IOV network cards
- vGPU configuration
- USB bus
- SCSI bus
Those are all related to visualization and host-passthrough, right? If so, let's build cases around that, making each case solve a problem at a time. For server hardware, my assumption would be that SCSI bus passthrough is more critical than USB passthrough, but please correct me if I'm wrong.
Outside of virtualization, the things I've seen generating most support issues have been: * How do I find out which PCI slots are in use? (useful for asserting if there is space in a machine for new hardware) * How do I find the model and serial number of my system? (useful when being in contact with hardware support) * How do I map physical slots to specific devices? (useful for when I need to replace hardware and knowing what card to physically replace)
- Andreas
Hello Marek,
Marek Libra [2017-10-19 11:44 +0200]:
I would like to renew the effort on Host Devices for Cockpit [1].
Indeed, sorry that this got dragged for so long.
To move forward, let's implement it step by step while opening brand new PR picking just a subset of the already implemented functionality [1] while adjusted to generally acceptable form.
Agreed. Garrett did some initial design mockups [1] and a feature page [2] recently. The per-bus table details seem a bit questionable to me still, but we can discuss/iterate on that.
[1] http://garrettlesage.com/cockpit-mockweb/hardware/ [2] https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-View
Initial implementation would meet:
- PCI support only
- initially read-only: just the List of devices by their Class (according
to [2])
example: by Audio device, Ethernet Controller, etc
data source: sysfs
make use of backward-compatible lspci for data preprocessing (especially
manipulation with HW database)
What do you mean by this? I. e. why should we call lspci instead of reading this from udev's database? udevadm info's output is more machine readable, contains other device classes as well, and hwdb uses the same ID databases than lspci/lsusb. But I might be missing something?
- monitor for changes by listening kernel uevents
That sounds good to me as a first milestone, and then this can hit some user testing and feedback. As a finger exercise I did some code cleanup/generalization [3] and put up an initial WIP for showing the system-global data (Machine type/name, BIOS, CPU type) [4].
[3] https://github.com/cockpit-project/cockpit/pull/8491 [4] https://github.com/cockpit-project/cockpit/pull/8501
Thanks,
Martin
cockpit-devel@lists.fedorahosted.org
-
Andreas Nilsson -
Marek Libra -
Martin Pitt -
Stef Walter