From: Dominik Csapak <d.csapak@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Wolfgang Bumiller <w.bumiller@proxmox.com>,
Filip Schauer <f.schauer@proxmox.com>
Subject: Re: [pve-devel] [PATCH RFC container] Add device passthrough
Date: Fri, 20 Oct 2023 09:51:43 +0200 [thread overview]
Message-ID: <82d37443-ca7f-4cf3-aae0-36444e4769af@proxmox.com> (raw)
In-Reply-To: <elrza7dys6b4gjlppamlx2jb5rudcheykscqhhq4hep54tmigd@llzl6w6rmtqs>
On 10/20/23 09:08, Wolfgang Bumiller wrote:
> On Thu, Oct 19, 2023 at 02:18:56PM +0200, Filip Schauer wrote:
>> Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
>> ---
>> Is it reasonable to add a "dev[n]" argument to the pct.conf, given that
>> device mount points only allow passing through block devices?
>
> Why would they only allow block devices?
>
> Also, Dominik recently added resource mappings for qemu for USB & PCI.
> PCI might be tricky, but for USB we may be able to use these mappings as
> well.
> That said, "raw" `/dev` node pass-through still makes sense as a
> separate thing for containers anyway since raw `lxc....` entries in the
> container config can currently be very inconvenient to deal with
> particularly with unprivileged containers (read on below for why...)
just to chime in here, i don't think it'll be easily possible to reuse
the pci/usb maps as is since we'd have to map from pciid /usb-vendor/device
(or path) to a device node? i don't think thats generally possible, since
the driver does not always make that info easily available
(e.g. multi gpu setup and /dev/dri/cardX, or usb-to-serial adapters
and /dev/ttySX ?) i guess it could work, but we probably would have
to implement that for every driver out there?
what i would like to see however is to integrate a new type of mapping
for container devices specifically so that the ux is the same
(create mappings for whole cluster, assigning privileges, etc)
we still can provide a 'raw' mechanic as well for those who
only ever use root@pam on a single node, but I'd not be
against only using mappings either
next prev parent reply other threads:[~2023-10-20 7:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 12:18 Filip Schauer
2023-10-20 7:08 ` Wolfgang Bumiller
2023-10-20 7:51 ` Dominik Csapak [this message]
2023-10-20 8:29 ` Thomas Lamprecht
2023-10-20 8:39 ` Dominik Csapak
2023-10-24 13:00 ` Filip Schauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82d37443-ca7f-4cf3-aae0-36444e4769af@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=f.schauer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=w.bumiller@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.