On Fri Aug 9, 2024 at 1:51 PM CEST, Christoph Heiss wrote:
> Otherwise, substrings might get replaced, e.g. the replacement
> `proxmox-start-auto-installer` -> `pxmox-start-auto-installer` would be
> done.
>
> Fixes: a02a78a ("fix #4747: pass kernel cmdline parameters to target system")
> Suggested
--- Begin Message ---
>>Alexandre,
>>
>>the statement below is not true for our case. The OpenVMS guest OS is
>>using a PCIE bus, so the virtio-scsi device should be exposed as
>>"modern", but is not. Not sure why not at this point
See Fiona response,
the pci express bridge is present, but the vi
--- Begin Message ---
>>I'm talking about virtio-scsi. Our virtio-network device is working
>>fine
Yes, sorry, I wanted to said virtio-scsi.
All pci devices excluding passthrough devices (with pcie=on flag) are
actually plugged to pci bridge
sub get_pci_addr_map {
$pci_addr_map = {
For non-PVE products, simply use the ZFS defaults (aka. 50%) and leave
unset, if the user never touches that setting.
Signed-off-by: Christoph Heiss
---
Changes v4 -> v5:
* rebased on latest master
* fixed value not persisting across dialog open/close for non-PVE
Changes v3 -> v4:
* rebase
Enables to add an optional placeholder value to `NumericEditView`, which
will be displayed in a different (darker) color and not returned by
`.get_content*()`.
Can be used for having default values in the TUI, but with different
handling in the back.
Signed-off-by: Christoph Heiss
---
Changes v4
For non-PVE products, simply use the ZFS defaults (aka. 50%) and leave
unset, if the user never touches that setting.
Signed-off-by: Christoph Heiss
---
Changes v4 -> v5:
* no changes
Changes v3 -> v4:
* no changes
Changes v2 -> v3:
* rework based on Maximilano's suggestion using Gtk3::Ad
As suggested by Thomas, leaves the ZFS default if the user never touches
the setting in the installer (i.e. not writing a modprobe file).
See also the discussion in v1 [0].
[0] https://lists.proxmox.com/pipermail/pve-devel/2024-February/061659.html
Testing
===
Tested the installation of PVE,
On Thu Jun 6, 2024 at 11:22 AM CEST, Dominik Csapak wrote:
> in a new section about additional options
>
> Signed-off-by: Dominik Csapak
> ---
> no changes
> qm.adoc | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/qm.adoc b/qm.adoc
> index 42c26db..3f4e59a 100644
> --- a/q
Hello,
what I have been trying to tell is that both virtio-scsi and virtio-network
device on Proxmox are both getting configured on PCIE. I do not understand why
you claim that virtio-scsi is not configured on PCIE.
So both virtio-scsi and virtio-network devices on Proxmox are configured as
le
Alexandre,
thank you for your information. On another KVM, the virtio-scsi device has the
hardware id of 0x10481AF4, whereas on Proxmox is has 0x10041AF4, which is a
legacy device.
But after more testing, I do not think that the issue is related to legacy vs
modern device, but rather interrupt
Alexandre,
the statement below is not true for our case. The OpenVMS guest OS is using a
PCIE bus, so the virtio-scsi device should be exposed as "modern", but is not.
Not sure why not at this point
/cmos
___
Christian Moser
Mobile:+358-4
I'm talking about virtio-scsi. Our virtio-network device is working fine
Sent from BlueMail
Get BlueMail for Android
On Aug 14, 2024, 15:22, at 15:22, "DERUMIER, Alexandre"
wrote:
>>>Alexandre,
>>>
>>>the statement below is not true for our case. The OpenVMS guest OS is
>>>using a PCIE bus
12 matches
Mail list logo
