4:44 a.m.
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
--
Marek Libra
senior software engineer
Red Hat Czech
<https://www.redhat.com>
5:31 a.m.
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
7:13 a.m.
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
7:17 a.m.
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
9:25 a.m.
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/2dcca863...
It only does a straight down, simple listing of PCI devices. Let me know
what you think!
- Andreas
2:05 a.m.
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(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org
--
Marek Libra
senior software engineer
Red Hat Czech
<https://www.redhat.com>
2:57 a.m.
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(a)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/2dcca863...
<https://raw.githubusercontent.com/cockpit-project/cockpit-design/2dcca863...
It only does a straight down, simple listing of PCI devices. Let me
know what you think!
- Andreas
_______________________________________________
cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
<mailto:cockpit-devel@lists.fedorahosted.org>
To unsubscribe send an email to
cockpit-devel-leave(a)lists.fedorahosted.org
<mailto:cockpit-devel-leave@lists.fedorahosted.org>
--
Marek Libra
senior software engineer
Red Hat Czech
<https://www.redhat.com>
_______________________________________________
cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org
4:56 a.m.
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
2:28 a.m.
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
2280
days inactive
2380
days old
cockpit-devel@lists.fedorahosted.org
8 comments
4 participants
participants (4)
-
Andreas Nilsson -
Marek Libra -
Martin Pitt -
Stef Walter