Am 29.01.25 um 16:53 schrieb Filip Schauer:
> Allow users with the VM.Config.HWType privilege to configure VirtIO RNG
> devices on VMs with either /dev/urandom or /dev/random as the entropy
> source.
>
> Further introduce hardware RNG device mapping to be able to selectively
> allow non-root users
Am 29.01.25 um 16:53 schrieb Filip Schauer:
> Signed-off-by: Filip Schauer
> ---
> PVE/QemuServer.pm | 83 +++-
> PVE/QemuServer/Makefile | 1 +
> PVE/QemuServer/RNG.pm | 135
> 3 files changed, 145 insertions(+), 74 deletion
Am 29.01.25 um 16:53 schrieb Filip Schauer:
> +my $map_fmt = {
> +node => get_standard_option('pve-node'),
> +path => {
> + description => "The path to the device node of the entropy source.",
> + type => 'string',
> + pattern => qr/^\/dev\/.+$/,
Style nit: could use | or ! as
Am 29.01.25 um 16:53 schrieb Filip Schauer:
> Allow non-root users with the VM.Config.HWType privilege to configure
> /dev/urandom & /dev/random as an entropy source for a VirtIO RNG device.
> /dev/hwrng remains restricted to the root user.
>
> Signed-off-by: Filip Schauer
> ---
> PVE/API2/Qemu.
Maximiliano Sandoval writes:
>> Instead of relying on the device_change_handler callback (which saves
>> the config) we manually set the text to the right value.
>>
>> Signed-off-by: Maximiliano Sandoval
>> ---
>
> I am not completely sure if this patch series preserves the intentional
> UI fl
Maximiliano Sandoval writes:
> The catalog-{lang}.mo files are generated only with strings that are
> relevant to the proxmox-datacenter-manager instead of the whole
> {lang}.po file. The msgmerge command will produce all strings containing
> in the {lang}.po file but the ones that do not conce
Add a checkbox for marking an iso file as required for booting via the
'essential' drive parameter.
This option is used in the backend to determine if the VM should start
up in case the configured ISO file is not available.
By default this box is not visible and disabled.
Signed-off-by: Daniel H
This patch series addresses bugzilla entry #4225.
Currently VMs refuse to to start if a configured isofile becomes unavailable,
be it a deleted file or an unavailable network storage.
This patch series introduces a new parameter in Drive.pm, called 'essential'.
Depending on whether this parameter
Enables the 'Essential' checkbox for the IsoSelector.
If the parameter `essential` is not set in the configuration,
it will be assumed to be true, to avoid breaking changes.
The box is checked by default for the same reason.
If unchecked, `essential=0` is written to the configuration and the VM
This commit adds a button in the hardware view for quickly ejecting
unnecessary cdroms or ISO files by setting file to 'none'.
Signed-off-by: Daniel Herzig
---
www/manager6/qemu/HardwareView.js | 42 +++
1 file changed, 42 insertions(+)
diff --git a/www/manager6/qemu
The function `eject_nonrequired_isos` checks on whether a cdrom drive is
marked as required for booting the VM or not. If the parameter `essential` is
not
defined, it will assume `essential` to be true and keep the current
behaviour.
If `required` is set to 0, the function 'ejects' the ISO file
This commit add the parameter `essential` to mark a drive as required
for booting the VM.
Signed-off-by: Daniel Herzig
---
PVE/QemuServer/Drive.pm | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuServer/Drive.pm b/PVE/QemuServer/Drive.pm
index 1041c1dd..3813678
This commit puts `eject_nonrequired_isos` into the foreach_volume
section of `config_to_command`.
To ensure successful package-building it also does a few adaptions to
the test framework. Namely these are:
* Mock cifs-store to appear as online against a call from
PVE::Storage::activate_storage.
Add a way to prohibit overriding certain subroutines ("symbols") at
"compile time" -- during Perl's BEGIN phase [1].
This is done by extending the previously introduced plugin loading
machinery with an additional check.
In essence, the new `prohibitOverrideAt` attribute handler can be
added to su
This commit changes how plugins, both inbuilt and custom, are loaded
and registered by the `PVE::Storage` module from the ground up.
This is done for mainly two reasons:
1. Unifying the plugin loading mechanism so that inbuilt and custom
plugins are subjected to (almost) the same checks.
2
RFC: Tighter API Control for Storage Plugins - v1
=
Since this has been cooking for a while I've decided to send this in as
an RFC in order to get some early feedback in.
Note that this is quite experimental and also a little more complex;
I'll try
Check whether a plugin defines a `type` method (as required by
PVE::SectionConfig). Throw and exception if it doesn't.
Also check for the same type being declared more than once.
All this is added to make implementing a plugin a little more
developer-friendly through more expressive error message
The purpose of this module is to separate the handling of the Storage
API's version from the remaining code while also providing additional
mechanisms to handle changes to the Storage API more gracefully.
The first such mechanism is the `pveStorageDeprecateAt` attribute,
which, when added to a sub
For each property that a plugin defines, check if the property is
already defined by another plugin before registering plugins.
This is mostly done for the sake of developer-friendliness. The same
check is made in `PVE::SectionConfig::init()` -- the difference here
is that the plugin which defined
This makes it so that the `get_volume_notes` and `update_volume_notes`
methods use the previously introduced `prohibitOverrideAt` attribute
handler instead of relying on FIXME comments.
Because the comments originally said to "remove on the next APIAGE
reset", the `version` for the two attributes
Am 17.12.24 um 16:23 schrieb Maximiliano Sandoval:
> Otherwise the callback will run once for each NIC.
>
> Signed-off-by: Maximiliano Sandoval
> ---
> proxinstall | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
applied series, thanks!
I expanded the commit message of the third pa
On 1/28/25 15:38, Thomas Lamprecht wrote:
This is a bit worded like that behavior would be a regression, but it
isn't AFAICT as this was always kebab-case from when being added in
commit 6526662 ("fix #5579: auto-installer: add optional first-boot hook
script"); or am I overlooking something?
I
Also clarify the function comment with the original intention for why
this was added in the frontend (the backend cannot know which is
which), see commit fc3a88ad ("ui: qemu wizard: use better boot order
for second cd drive").
Signed-off-by: Fiona Ebner
---
www/manager6/qemu/CreateWizard.js | 7
Am 30.01.25 um 10:11 schrieb Daniel Kral:
> I also like that solution and that is more in line with the motivation
> behind the patch. I could queue up a patch for the next ISO release, so
> that it's indifferent to the user whether they write the config
> parameter names in their answer files i
24 matches
Mail list logo
