Re: [pve-devel] [PATCH manager v4 1/3] lxc: show dynamically assigned IPs in network tab
On 07.04.2025 19:46, Thomas Lamprecht wrote:
Am 08.01.25 um 15:38 schrieb Gabriel Goller:
adds a call to /nodes/{node}/lxc/{vmid}/interfaces and merges the
returned data with the existing configuration. This will update the
IPv4 and IPv6 address, as well as the interface name (in case the
container changed it).
Originally-by: Leo Nunner
Signed-off-by: Gabriel Goller
---
www/manager6/lxc/Network.js | 85 ++---
1 file changed, 60 insertions(+), 25 deletions(-)
the network view's grid gets broken here for any container that is not
turned on, and thus cannot have an address configured.
Umm this is kinda tricky, the proxmoxRRDChart has a fixed height of 300,
and changing that probably breakes a lot of stuff. I could make the
GuestView (so the first panel) scrollable, but then additional text or
the "More" button will probably be cut off (when not scrolling).
Using Proxmox.Async and early return/continue to reduce some
indentation level might be good to.
true, will do.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v4 1/3] lxc: show dynamically assigned IPs in network tab
Am 08.04.25 um 12:06 schrieb Gabriel Goller:
> On 07.04.2025 19:46, Thomas Lamprecht wrote:
>> Am 08.01.25 um 15:38 schrieb Gabriel Goller:
>>> adds a call to /nodes/{node}/lxc/{vmid}/interfaces and merges the
>>> returned data with the existing configuration. This will update the
>>> IPv4 and IPv6 address, as well as the interface name (in case the
>>> container changed it).
>>>
>>> Originally-by: Leo Nunner
>>> Signed-off-by: Gabriel Goller
>>> ---
>>> www/manager6/lxc/Network.js | 85 ++---
>>> 1 file changed, 60 insertions(+), 25 deletions(-)
>>>
>>
>> the network view's grid gets broken here for any container that is not
>> turned on, and thus cannot have an address configured.
>
> Umm this is kinda tricky, the proxmoxRRDChart has a fixed height of 300,
> and changing that probably breakes a lot of stuff. I could make the
> GuestView (so the first panel) scrollable, but then additional text or
> the "More" button will probably be cut off (when not scrolling).
There are no RRD graphs in the network view, what are you talking about?
I mean the columns of the network configuration view stop rendering with
these patches starting from the address column rightwards.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH proxmox-i18n] Update italian translation
On Tue, 08 Apr 2025 11:09:18 +0200, Gabriel Goller wrote: > Typos and errors introduced by previous commit. > > Applied, thanks! [1/1] Update italian translation commit: 78f696097f8e4c587a8b6e91afe2e0802b18e993 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server v5 2/4] api: status/current: add display property
Am 07.04.25 um 18:27 schrieb Aaron Lauterer:
> @@ -3048,8 +3058,11 @@ __PACKAGE__->register_method({
>
> $status->{ha} =
> PVE::HA::Config::get_service_status("vm:$param->{vmid}");
>
> + $status->{display}->{type} = 'std';
This is not the correct default in all cases (e.g. aarch64 VM, old
Windows). Please use the get_vga_properties() helper from QemuServer.pm
(you'll need to make it public by dropping its "my" of course).
> if ($conf->{vga}) {
> my $vga = PVE::QemuServer::parse_vga($conf->{vga});
> + $status->{display}->{type} = $vga->{type} if defined($vga->{type});
> +
> my $spice = defined($vga->{type}) && $vga->{type} =~ /^virtio/;
> $spice ||= PVE::QemuServer::vga_conf_has_spice($conf->{vga});
> $status->{spice} = 1 if $spice;
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH esxi-import-tools] listvms: exclude VMs without datastore_name from manifest.json.
Wolfgang Bumiller writes: >> for vm in list_vms(connection): >> +# skip vms with empty datastore_name >> +datastore_name, relative_vmx_path = parse_file_path( >> +vm.config.files.vmPathName >> +) >> +if not datastore_name: > > While this works as a stop-gap, I think we should use the example code > here[1] to test if this is such an embedded(?) vCLS VM, and if it is > *not* such a VM, print a warning to stderr that we're skipping this VM, > so that in the future, if VMs magically disappear, we should see log > messages about this. > > [1] > https://knowledge.broadcom.com/external/article/370219/script-identification-for-embedded-vcls.html I agree -- above is more of a handbrake-solution. I'll see what I can do for proper indentification. Thanks a lot for the link, I missed that there's more focussed identifiers available already. > >> +continue >> try: >> fetch_and_update_vm_data(vm, data) >> except Exception as err: >> -- >> 2.39.5 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH installer] auto: add some error context when loading the first-boot executable
On Tue Apr 8, 2025 at 11:23 AM CEST, Thomas Lamprecht wrote:
> Am 08.04.25 um 11:06 schrieb Christoph Heiss:
>
>> @@ -47,7 +47,9 @@ fn setup_first_boot_executable(first_boot:
>> &FirstBootHookInfo) -> Result<()> {
>> }
>> }
>> FirstBootHookSourceMode::FromIso => {
>> -Some(fs::read(format!("/cdrom/{FIRST_BOOT_EXEC_NAME}"))?)
>> +Some(fs::read(format!("/cdrom/{FIRST_BOOT_EXEC_NAME}")).context(
>> +"failed loading first-boot executable from ISO (was
>> --on-first-boot specified?)",
> Definitively better than the status quo, but as user I would then ask
> myself how I can pass that flag to the installer, so maybe word it
> something like:
>
> "failed loading first-boot executable from ISO (was ISO prepared with
> --on-first-boot specified?"
Definitively sounds better, especially when seeing it from that
perspective!
I tried to keep the message rather short at first, since it is printed
on one line currently. But we could also use "{err:#?}" as format
specifier below, to let anyhow break up the error message over multiple
lines.
I'll send a v2 shortly!
>
> Or is this caught already earlier?
No, currently not. But I already talked with Michael about more
extensive validation in the future, in both the auto-installer and
auto-install-assistant.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v6 3/4] ui: qemu hd edit: allow importing a disk from the import storage
Am 08.04.25 um 09:01 schrieb Dominik Csapak: > On 4/8/25 00:13, Thomas Lamprecht wrote: >> Am 07.04.25 um 12:13 schrieb Dominik Csapak: >>> adds a checkbox 'import image' above the storage selector which: >>> * hides the original storage selector >>> * shows a 'source storage' selector >>> * shows a 'import file' selector >>> * shows a 'target storage' selector >>> >>> Since the wizard and the hd edit share this panel, this also works in >>> the wizard. >> >> Can we disable this for HD Add? IMO that dialogue is already really >> complex as is. >> >> Might be even beneficial if this is always predefined from the call >> or integration side... >> >> And seems I cannot start an import through the import storage content >> view? Feels odd to me, all other imports are triggered there after all. > > ok so if I understand you correctly, you want this in the wizard but not > in the 'add hd' panel ? And you want to have a (probably simplified) hd > add panel from the import storage content panel directly ? Yeah for starters I'd probably just have gone for allowing importing such a disk to an existing VM. That said checking a few reports and rethinking this users might actually want to have it available in the creation process, that feels a bit more natural... Cc'in Aaron for an opinion as he often gets UX feedback a bit more directly in trainings and has a more decisive opinion on these things. > > sounds fine to me, an alternative I could offer would be to > have a separate input panel only for importing, and show in the wizard > another button (e.g. split button on add) that adds that import panel > and for the guests a new entry in the 'add menu' that says 'import' > > (this panel could then also be added to the import storage content, > with an additional vm selector) btw: should this have a fix #2424 ? ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH installer] country.pl: load iso 3166 country codes file as UTF8
This file is UTF-8 encoded and contains Unicode characters for encoding
country names, such as "Åland Islands" for example.
Otherwise, the final locale-info.json that gets shipped with the ISO
might contain wrongly-encoded country names, causing display errors in
(at least) the GTK installer country dropdown.
Reported-by: Maximiliano Sandoval
Signed-off-by: Christoph Heiss
---
country.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/country.pl b/country.pl
index 9e4881a..7401f68 100755
--- a/country.pl
+++ b/country.pl
@@ -88,7 +88,7 @@ my sub parse_zoneinfo {
# country codes from:
my $country_codes_file = "/usr/share/iso-codes/json/iso_3166-1.json";
-my $iso_3166_codes =
from_json(PVE::Tools::file_get_contents($country_codes_file, 64 * 1024));
+my $iso_3166_codes =
from_json(PVE::Tools::file_get_contents($country_codes_file, 64 * 1024), { utf8
=> 1 });
my $country_codes = { map { lc($_->{'alpha_2'}) => $_->{'common_name'} //
$_->{'name'} } @{$iso_3166_codes->{'3166-1'}} };
--
2.48.1
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH installer] country.pl: load iso 3166 country codes file as UTF8
I ran
```sh
make locale-info.json
locales.json
```
then did a diff of the locales.json file before and after this patch. The
resulting diff is:
```diff
@@ -1001,7 +1001,7 @@
"ax": {
"kmap": "",
"mirror": "",
- "name": "Ã
land Islands",
+ "name": "Åland Islands",
"zone": "Europe/Mariehamn"
},
"az": {
@@ -1067,7 +1067,7 @@
"bl": {
"kmap": "",
"mirror": "",
- "name": "Saint Barthélemy",
+ "name": "Saint Barthélemy",
"zone": "America/St_Barthelemy"
},
"bm": {
@@ -1174,7 +1174,7 @@
"ci": {
"kmap": "",
"mirror": "",
- "name": "Côte d'Ivoire",
+ "name": "Côte d'Ivoire",
"zone": "Africa/Abidjan"
},
"ck": {
@@ -1228,7 +1228,7 @@
"cw": {
"kmap": "",
"mirror": "",
- "name": "Curaçao",
+ "name": "Curaçao",
"zone": "America/Curacao"
},
"cx": {
@@ -2037,7 +2037,7 @@
"re": {
"kmap": "",
"mirror": "",
- "name": "Réunion",
+ "name": "Réunion",
"zone": "Indian/Reunion"
},
"ro": {
@@ -2259,7 +2259,7 @@
"tr": {
"kmap": "",
"mirror": "ftp.tr.debian.org",
- "name": "Türkiye",
+ "name": "Türkiye",
"zone": "Europe/Istanbul"
},
"tt": {
@@ -2463,10 +2463,10 @@
"costa rica": "cr",
"croatia": "hr",
"cuba": "cu",
-"curaã§ao": "cw",
+"curaçao": "cw",
"cyprus": "cy",
"czechia": "cz",
-"cã´te d'ivoire": "ci",
+"côte d'ivoire": "ci",
"denmark": "dk",
"djibouti": "dj",
"dominica": "dm",
@@ -2590,8 +2590,8 @@
"romania": "ro",
"russian federation": "ru",
"rwanda": "rw",
-"rã©union": "re",
-"saint barthã©lemy": "bl",
+"réunion": "re",
+"saint barthélemy": "bl",
"saint helena, ascension and tristan da cunha": "sh",
"saint kitts and nevis": "kn",
"saint lucia": "lc",
@@ -2637,7 +2637,7 @@
"turkmenistan": "tm",
"turks and caicos islands": "tc",
"tuvalu": "tv",
-"tã¼rkiye": "tr",
+"türkiye": "tr",
"uganda": "ug",
"ukraine": "ua",
"united arab emirates": "ae",
@@ -2656,7 +2656,7 @@
"yemen": "ye",
"zambia": "zm",
"zimbabwe": "zw",
-"ã
land islands": "ax"
+"åland islands": "ax"
},
"kmap": {
"de": {
```
which seems correct to me.
Thanks for the patch!
Reviewed-by: Maximiliano Sandoval
Tested-by: Maximiliano Sandoval
Christoph Heiss writes:
> This file is UTF-8 encoded and contains Unicode characters for encoding
> country names, such as "Åland Islands" for example.
>
> Otherwise, the final locale-info.json that gets shipped with the ISO
> might contain wrongly-encoded country names, causing display errors in
> (at least) the GTK installer country dropdown.
>
> Reported-by: Maximiliano Sandoval
> Signed-off-by: Christoph Heiss
> ---
> country.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/country.pl b/country.pl
> index 9e4881a..7401f68 100755
> --- a/country.pl
> +++ b/country.pl
> @@ -88,7 +88,7 @@ my sub parse_zoneinfo {
> # country codes from:
> my $country_codes_file = "/usr/share/iso-codes/json/iso_3166-1.json";
>
> -my $iso_3166_codes =
> from_json(PVE::Tools::file_get_contents($country_codes_file, 64 * 1024));
> +my $iso_3166_codes =
> from_json(PVE::Tools::file_get_contents($country_codes_file, 64 * 1024), {
> utf8 => 1 });
>
> my $country_codes = { map { lc($_->{'alpha_2'}) => $_->{'common_name'} //
> $_->{'name'} } @{$iso_3166_codes->{'3166-1'}} };
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v6 3/4] ui: qemu hd edit: allow importing a disk from the import storage
On 4/8/25 10:40, Thomas Lamprecht wrote: Am 08.04.25 um 09:01 schrieb Dominik Csapak: On 4/8/25 00:13, Thomas Lamprecht wrote: Am 07.04.25 um 12:13 schrieb Dominik Csapak: adds a checkbox 'import image' above the storage selector which: * hides the original storage selector * shows a 'source storage' selector * shows a 'import file' selector * shows a 'target storage' selector Since the wizard and the hd edit share this panel, this also works in the wizard. Can we disable this for HD Add? IMO that dialogue is already really complex as is. Might be even beneficial if this is always predefined from the call or integration side... And seems I cannot start an import through the import storage content view? Feels odd to me, all other imports are triggered there after all. ok so if I understand you correctly, you want this in the wizard but not in the 'add hd' panel ? And you want to have a (probably simplified) hd add panel from the import storage content panel directly ? Yeah for starters I'd probably just have gone for allowing importing such a disk to an existing VM. That said checking a few reports and rethinking this users might actually want to have it available in the creation process, that feels a bit more natural... Cc'in Aaron for an opinion as he often gets UX feedback a bit more directly in trainings and has a more decisive opinion on these things. what i currently have (half) working here is basically what i wrote below, the same input panel, but either for creating a new disk or importing, and the caller decides. with another button in the wizard that allows adding such an 'import panel' (should be relatively easy to add that to the hardware panel and import storage content too) sounds fine to me, an alternative I could offer would be to have a separate input panel only for importing, and show in the wizard another button (e.g. split button on add) that adds that import panel and for the guests a new entry in the 'add menu' that says 'import' (this panel could then also be added to the import storage content, with an additional vm selector) btw: should this have a fix #2424 ? you're right, at least a 'partially fixes #2424' since the users also wanted to have definitions uploaded (libvirt xmls?) but not sure if that's even a thing that we want to have.. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-http-server v2 1/1] fix unexpected EOF for client when closing TLS session
Am 08.04.25 um 10:48 schrieb Fabian Grünbichler: >> Fiona Ebner hat am 08.04.2025 09:27 CEST geschrieben: >> I feel like the questions regarding blocking/missing client ack from >> Fabian from v1 are not answered yet: >> >>> If I read the docs right, this could block (would that be an issue here?) >>> and could potentially destroy the handle (so that might need to be >>> rechecked afterwards to prevent spurious warnings?) >>> >>> what happens if we initiate the teardown, and the client never acks it? > > there was some more input in a separate mail: > > https://lore.proxmox.com/pve-devel/mailman.799.1741211155.293.pve-de...@lists.proxmox.com/ Okay, great :) It would be nice if mailman (or something) wouldn't mess up mails/threads from external senders :/ ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH installer] auto: add some error context when loading the first-boot executable
At least to one user in the forum already ran into this IIRC, and most
recently Maximiliano too.
This can happen when e.g. copying example answer files with the
first-boot section, without then passing `--on-first-boot` to
proxmox-auto-install-assistant.
In that case, the user would just get a pretty unhelpful error message:
ERROR: Autoinstaller setup error: No such file or directory (os error 2)
Attach some context, which points the user directly to the corresponding
setting / answer file section.
Reported-by: Maximiliano Sandoval
Signed-off-by: Christoph Heiss
---
proxmox-auto-installer/src/bin/proxmox-auto-installer.rs | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
b/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
index 05d1801..b248dff 100644
--- a/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
+++ b/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
@@ -1,4 +1,4 @@
-use anyhow::{Result, bail, format_err};
+use anyhow::{Context, Result, bail, format_err};
use log::{LevelFilter, error, info};
use std::{
env,
@@ -47,7 +47,9 @@ fn setup_first_boot_executable(first_boot:
&FirstBootHookInfo) -> Result<()> {
}
}
FirstBootHookSourceMode::FromIso => {
-Some(fs::read(format!("/cdrom/{FIRST_BOOT_EXEC_NAME}"))?)
+Some(fs::read(format!("/cdrom/{FIRST_BOOT_EXEC_NAME}")).context(
+"failed loading first-boot executable from ISO (was
--on-first-boot specified?)",
+)?)
}
};
@@ -115,7 +117,7 @@ fn main() -> ExitCode {
let (answer, udevadm_info) = match auto_installer_setup(in_test_mode) {
Ok(result) => result,
Err(err) => {
-error!("Autoinstaller setup error: {err}");
+error!("Autoinstaller setup error: {err:#}");
return ExitCode::FAILURE;
}
};
--
2.48.1
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server v5 2/4] api: status/current: add display property
On 2025-04-08 09:49, Fiona Ebner wrote:
Am 07.04.25 um 18:27 schrieb Aaron Lauterer:
@@ -3048,8 +3058,11 @@ __PACKAGE__->register_method({
$status->{ha} = PVE::HA::Config::get_service_status("vm:$param->{vmid}");
+ $status->{display}->{type} = 'std';
This is not the correct default in all cases (e.g. aarch64 VM, old
Windows). Please use the get_vga_properties() helper from QemuServer.pm
(you'll need to make it public by dropping its "my" of course).
Thanks! Will do
if ($conf->{vga}) {
my $vga = PVE::QemuServer::parse_vga($conf->{vga});
+ $status->{display}->{type} = $vga->{type} if defined($vga->{type});
+
my $spice = defined($vga->{type}) && $vga->{type} =~ /^virtio/;
$spice ||= PVE::QemuServer::vga_conf_has_spice($conf->{vga});
$status->{spice} = 1 if $spice;
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH installer] gui: fall back to first found NIC if no default could be determined
Christoph Heiss writes: > If no DHCP server is configured on the network and/or no DHCP lease and > thus network configuration is retrieved, the installer will also be > unable to determine the default interface, aka. the one with the default > gateway set. > > Fix it by pre-selecting the first found interface. If we *do* have a > default interface, the index will be later overwritten, but ensures that > always *some* interface is pre-selected in the dropdown. > > As it is already checked that the machine has any network interfaces > before starting the installation wizard, it is safe to rely on the fact > that at least one NIC must be present. > > For completeness, all the other network inputs already have (hardcoded) > fallbacks, namely 192.168.100.2/24 as address/netmask, 192.168.100.1 as > gateway and the gateway address as DNS server address. > > Reported-by: Christian Ebner > Signed-off-by: Christoph Heiss I am a bit late here, I tested this patch with either one or three NICs and with and without a working DHCP server. I did not notice any regression. Tested-by: Maximiliano Sandoval ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] Applied: [PATCH installer] country.pl: load iso 3166 country codes file as UTF8
On Tue, 08 Apr 2025 10:47:43 +0200, Christoph Heiss wrote: > This file is UTF-8 encoded and contains Unicode characters for encoding > country names, such as "Åland Islands" for example. > > Otherwise, the final locale-info.json that gets shipped with the ISO > might contain wrongly-encoded country names, causing display errors in > (at least) the GTK installer country dropdown. > > [...] Exactly what I thought it would be when Maximiliano showed me the screenshot of the broken encoding, hindsigth is 20/20 I guess. Applied, thanks! [1/1] country.pl: load iso 3166 country codes file as UTF8 commit: 4b5db269ec8aae689329633a1ebe9546a19490b3 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v5 4/4] ui: console: check on activate if display info for VMs is present
On 2025-04-08 10:10, Dominik Csapak wrote:
On 4/7/25 18:27, Aaron Lauterer wrote:
If we already have the display information for a VM, we can proceed
loading the correct console (noVNC or xtermjs).
This way, we don't need to wait for the callback of the VM's
status/current API call to finish setting up the console.
Signed-off-by: Aaron Lauterer
---
first introduces with v5
www/manager6/VNCConsole.js | 8
1 file changed, 8 insertions(+)
diff --git a/www/manager6/VNCConsole.js b/www/manager6/VNCConsole.js
index 3371c923..60772373 100644
--- a/www/manager6/VNCConsole.js
+++ b/www/manager6/VNCConsole.js
@@ -67,6 +67,14 @@ Ext.define('PVE.noVncConsole', {
activate: function() {
if (me.consoleType !== 'kvm') {
me.loadConsole(me.xtermjs, me.consoleType);
+ } else {
+ let display = me.up().statusStore.getById('display');
+ if (display &&
display.data.value.type?.startsWith('serial')) {
this is the same check done in the other patch, no?
a helper could be good here to make sure the checks stay in sync
Yeah, that thought also crossed my mind since yesterday. I'll change
that to a shared helper.
+ me.xtermjs = true;
+ }
+ if (display) {
+ me.loadConsole(me.xtermjs, me.consoleType);
+ }
}
},
},
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH installer v2] auto: add some error context when loading first-boot executable
At least to one user in the forum already ran into this IIRC, and most
recently Maximiliano too.
This can happen when e.g. copying example answer files with the
first-boot section, without then passing `--on-first-boot` to
proxmox-auto-install-assistant.
In that case, the user would just get a pretty unhelpful error message:
ERROR: Autoinstaller setup error: No such file or directory (os error 2)
Attach some context, which points the user directly to the corresponding
setting / answer file section.
Reported-by: Maximiliano Sandoval
Signed-off-by: Christoph Heiss
---
proxmox-auto-installer/src/bin/proxmox-auto-installer.rs | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
b/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
index 05d1801..a42029f 100644
--- a/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
+++ b/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
@@ -1,4 +1,4 @@
-use anyhow::{Result, bail, format_err};
+use anyhow::{Context, Result, bail, format_err};
use log::{LevelFilter, error, info};
use std::{
env,
@@ -47,7 +47,9 @@ fn setup_first_boot_executable(first_boot:
&FirstBootHookInfo) -> Result<()> {
}
}
FirstBootHookSourceMode::FromIso => {
-Some(fs::read(format!("/cdrom/{FIRST_BOOT_EXEC_NAME}"))?)
+let content = fs::read(format!("/cdrom/{FIRST_BOOT_EXEC_NAME}"))
+.context("failed loading first-boot executable from ISO (was
ISO prepared with `--on-first-boot` specified?)")?;
+Some(content)
}
};
@@ -115,7 +117,7 @@ fn main() -> ExitCode {
let (answer, udevadm_info) = match auto_installer_setup(in_test_mode) {
Ok(result) => result,
Err(err) => {
-error!("Autoinstaller setup error: {err}");
+error!("Autoinstaller setup error: {err:?}");
return ExitCode::FAILURE;
}
};
--
2.48.1
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v5 4/4] ui: console: check on activate if display info for VMs is present
On 4/7/25 18:27, Aaron Lauterer wrote:
If we already have the display information for a VM, we can proceed
loading the correct console (noVNC or xtermjs).
This way, we don't need to wait for the callback of the VM's
status/current API call to finish setting up the console.
Signed-off-by: Aaron Lauterer
---
first introduces with v5
www/manager6/VNCConsole.js | 8
1 file changed, 8 insertions(+)
diff --git a/www/manager6/VNCConsole.js b/www/manager6/VNCConsole.js
index 3371c923..60772373 100644
--- a/www/manager6/VNCConsole.js
+++ b/www/manager6/VNCConsole.js
@@ -67,6 +67,14 @@ Ext.define('PVE.noVncConsole', {
activate: function() {
if (me.consoleType !== 'kvm') {
me.loadConsole(me.xtermjs, me.consoleType);
+ } else {
+ let display = me.up().statusStore.getById('display');
+ if (display &&
display.data.value.type?.startsWith('serial')) {
this is the same check done in the other patch, no?
a helper could be good here to make sure the checks stay in sync
+ me.xtermjs = true;
+ }
+ if (display) {
+ me.loadConsole(me.xtermjs, me.consoleType);
+ }
}
},
},
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH guest-common 2/2] bump version to 5.2.2
Signed-off-by: Fiona Ebner --- debian/changelog | 7 +++ 1 file changed, 7 insertions(+) diff --git a/debian/changelog b/debian/changelog index aa4b6c3..6750624 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +libpve-guest-common-perl (5.2.2) bookworm; urgency=medium + + * correctly depend on recent enough libpve-cluster-perl version for directory +mappings. + + -- Proxmox Support Team Tue, 08 Apr 2025 10:05:42 +0200 + libpve-guest-common-perl (5.2.1) bookworm; urgency=medium * replication: delete job even if it is disabled -- 2.39.5 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v6 3/4] ui: qemu hd edit: allow importing a disk from the import storage
On 4/8/25 00:13, Thomas Lamprecht wrote: Am 07.04.25 um 12:13 schrieb Dominik Csapak: adds a checkbox 'import image' above the storage selector which: * hides the original storage selector * shows a 'source storage' selector * shows a 'import file' selector * shows a 'target storage' selector Since the wizard and the hd edit share this panel, this also works in the wizard. Can we disable this for HD Add? IMO that dialogue is already really complex as is. Might be even beneficial if this is always predefined from the call or integration side... And seems I cannot start an import through the import storage content view? Feels odd to me, all other imports are triggered there after all. ok so if I understand you correctly, you want this in the wizard but not in the 'add hd' panel ? And you want to have a (probably simplified) hd add panel from the import storage content panel directly ? sounds fine to me, an alternative I could offer would be to have a separate input panel only for importing, and show in the wizard another button (e.g. split button on add) that adds that import panel and for the guests a new entry in the 'add menu' that says 'import' (this panel could then also be added to the import storage content, with an additional vm selector) ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager v6 4/4] ui: console: check on activate if display info for VMs is present
If we already have the display information for a VM, we can proceed
loading the correct console (noVNC or xtermjs).
This way, we don't need to wait for the callback of the VM's
status/current API call to finish setting up the console.
Signed-off-by: Aaron Lauterer
---
changes since v5:
* use new helper to check if serial
www/manager6/VNCConsole.js | 8
1 file changed, 8 insertions(+)
diff --git a/www/manager6/VNCConsole.js b/www/manager6/VNCConsole.js
index 3371c923..200145c0 100644
--- a/www/manager6/VNCConsole.js
+++ b/www/manager6/VNCConsole.js
@@ -67,6 +67,14 @@ Ext.define('PVE.noVncConsole', {
activate: function() {
if (me.consoleType !== 'kvm') {
me.loadConsole(me.xtermjs, me.consoleType);
+ } else {
+ let display = me.up().statusStore.getById('display');
+ if
(PVE.Utils.isSerialDisplay(display?.data.value.type)) {
+ me.xtermjs = true;
+ }
+ if (display) {
+ me.loadConsole(me.xtermjs, me.consoleType);
+ }
}
},
},
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server v6 2/4] api: status/current: add display property
This new property returns the configured or default display for a VM.
Instead of a flat property, we use a nested 'type' object that contains
the actual information. This way we can add other properties that belong
to a VM's display in the future without much hassle, to have them all in
one place.
Candidates to be moved into the display property are for example the
spice and clipboard property.
Signed-off-by: Aaron Lauterer
---
Getting all the parameters for get_vga_properties added a bit of
boilerplate. Should be get another external call site to it we could
think about moving the boilerplate into get_vga_properties to handle
missing parameters. But for now I would rather not change the
get_vga_properties itself.
changes since v5:
* use QemuServer::get_vga_properties to determine the default
* properties.
PVE/API2/Qemu.pm | 21 +
1 file changed, 21 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 626cce4..cfe483c 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3074,6 +3074,16 @@ __PACKAGE__->register_method({
enum => ['vnc'],
optional => 1,
},
+ display => {
+ description => "Display settings",
+ type => 'object',
+ properties => {
+ type => {
+ description => "Display type configured",
+ type => 'string',
+ },
+ },
+ },
},
},
code => sub {
@@ -3087,8 +3097,19 @@ __PACKAGE__->register_method({
$status->{ha} =
PVE::HA::Config::get_service_status("vm:$param->{vmid}");
+ my $arch = PVE::QemuServer::Helpers::get_vm_arch($conf);
+ my $kvm_binary = PVE::QemuServer::Helpers::get_command_for_arch($arch);
+ my $kvmver = PVE::QemuServer::Helpers::kvm_user_version($kvm_binary);
+ my $machine_type = PVE::QemuServer::Machine::get_vm_machine($conf,
undef, $arch);
+ my $machine_version = PVE::QemuServer::extract_version($machine_type,
$kvmver);
+ my $winversion =
PVE::QemuServer::Helpers::windows_version($conf->{ostype});
+ my ($default_display, undef) =
PVE::QemuServer::get_vga_properties($conf, $arch, $machine_version,
$winversion);
+
+ $status->{display}->{type} = $default_display->{type};
if ($conf->{vga}) {
my $vga = PVE::QemuServer::parse_vga($conf->{vga});
+ $status->{display}->{type} = $vga->{type} if defined($vga->{type});
+
my $spice = defined($vga->{type}) && $vga->{type} =~ /^virtio/;
$spice ||= PVE::QemuServer::vga_conf_has_spice($conf->{vga});
$status->{spice} = 1 if $spice;
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server, manager v5 0/4] fix #1926 autodetect xtermjs or novnc for VM console
sent a v6 https://lore.proxmox.com/pve-devel/20250408103715.1081055-1-a.laute...@proxmox.com/ On 2025-04-07 18:27, Aaron Lauterer wrote: This version 5 of the series uses a different approach as discussed [0] in the last interation. We add a new property in the VM status/current API result that includes the display configurtion of the VM. This way we can check in the frontend what to do with it. I chose a nested return value, as that makes it easier to add/move additional display properties into it. The first patch just adds the serial property to the API docs as it was missing. So not really related to this series, but I came across it. Patch 2/4 adds the new display property. If not explicitly set in the VM config, it will return the default 'std' value. Patch 3/4 implements the changes in the UI. The final result isn't really a lot simpler on the UI side than in V4 where we had the extra API call to the VM's config directly. Because we still need to wait for the API call to finish when initially navigating to the VM. But we have one fewer call. Patch 4/4 then introduces some changes to make loading of the console faster if we just navigate in the submenu of a VM itself where we already have the current status of a VM already cached. [0] https://lore.proxmox.com/pve-devel/49bcd58f-aba2-4c1e-a6a0-d21828a33...@proxmox.com/ qemu-server: Aaron Lauterer (2): vmstatus_return_properties: add missing serial property api: status/current: add display property PVE/API2/Qemu.pm | 13 + PVE/QemuServer.pm | 5 + 2 files changed, 18 insertions(+) manager: Aaron Lauterer (2): fix #1926 ui: vm console: autodetect novnc or xtermjs ui: console: check on activate if display info for VMs is present www/manager6/VNCConsole.js | 60 ++--- www/manager6/qemu/Config.js | 8 - 2 files changed, 50 insertions(+), 18 deletions(-) ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server v6 1/4] QemuServer: make get_vga_properties and extract_version public
Signed-off-by: Aaron Lauterer
---
newly introduced with v6
PVE/QemuServer.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index ccdceed..b7ef69b 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -1159,7 +1159,7 @@ sub kvm_version {
return $kvm_api_version;
}
-my sub extract_version {
+sub extract_version {
my ($machine_type, $version) = @_;
$version = kvm_user_version() if !defined($version);
return PVE::QemuServer::Machine::extract_version($machine_type, $version)
@@ -3414,7 +3414,7 @@ my sub print_ovmf_drive_commandlines {
return ("if=pflash,unit=0,format=raw,readonly=on,file=$ovmf_code",
$var_drive_str);
}
-my sub get_vga_properties {
+sub get_vga_properties {
my ($conf, $arch, $machine_version, $winversion) = @_;
my $vga = parse_vga($conf->{vga});
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH] add patch to disable elastic_shared_blob to prevent crashing OSDs
reported in our community forum and upstream: https://forum.proxmox.com/threads/164735/ https://tracker.ceph.com/issues/70390 https://github.com/ceph/ceph/pull/62724 fix seems trivial, and the feature is quite new: https://ceph.io/assets/pdfs/events/2024/ceph-days-nyc/Diving%20Deep%20with%20Squid.pdf Signed-off-by: Stoiko Ivanov --- the commit message was re-used for both the patch-file and the commit itself hope that's ok? did not build this - as it'd take quite long. only verified that this setting is set to true (for all OSDs irrespective when they were created) with our current packages: ``` ceph config get osd.5 bluestore_elastic_shared_blobs true ``` (on a testcluster of mine) ...shared_blob-to-prevent-crashing-OSDs.patch | 31 +++ patches/series| 1 + 2 files changed, 32 insertions(+) create mode 100644 patches/0018-disable-elastic_shared_blob-to-prevent-crashing-OSDs.patch diff --git a/patches/0018-disable-elastic_shared_blob-to-prevent-crashing-OSDs.patch b/patches/0018-disable-elastic_shared_blob-to-prevent-crashing-OSDs.patch new file mode 100644 index 0..527df2cd7 --- /dev/null +++ b/patches/0018-disable-elastic_shared_blob-to-prevent-crashing-OSDs.patch @@ -0,0 +1,31 @@ +From Mon Sep 17 00:00:00 2001 +From: Stoiko Ivanov +Date: Tue, 8 Apr 2025 12:13:10 +0200 +Subject: [PATCH] disable elastic_shared_blob to prevent crashing OSDs + +reported in our community forum and upstream: +https://forum.proxmox.com/threads/164735/ +https://tracker.ceph.com/issues/70390 +https://github.com/ceph/ceph/pull/62724 + +fix seems trivial, and the feature is quite new: +https://ceph.io/assets/pdfs/events/2024/ceph-days-nyc/Diving%20Deep%20with%20Squid.pdf + +Signed-off-by: Stoiko Ivanov +--- + ceph/src/common/options/global.yaml.in | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/common/options/global.yaml.in b/ceph/src/common/options/global.yaml.in +index 76a4f4d9551ada1ce20913197dab2b0bdb716b5c..c9b76d378aa7226944e8c0edb14956ad1265a4ae 100644 +--- a/src/common/options/global.yaml.in b/src/common/options/global.yaml.in +@@ -4952,7 +4952,7 @@ options: + long_desc: Overwrites on snapped objects cause shared blob count to grow. + It has a very negative performance effect. When enabled shared blob count + is significantly reduced. +- default: true ++ default: false + flags: + - create + with_legacy: false diff --git a/patches/series b/patches/series index 994ff174d..6d01dcc02 100644 --- a/patches/series +++ b/patches/series @@ -15,3 +15,4 @@ 0015-debian-pkg-record-python3-packaging-dependency-for-c.patch 0016-d-control-fix-lua-dependencies-for-librgw2.patch 0017-common-pick_address-Add-IPv6-support-to-is_addr_in_s.patch +0018-disable-elastic_shared_blob-to-prevent-crashing-OSDs.patch -- 2.39.5 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH proxmox-i18n] update Spanish translations
On Tue, 08 Apr 2025 13:18:02 +0200, Maximiliano Sandoval wrote: > Applied, thanks! [1/1] update Spanish translations commit: ac9cf0fced2cee0ad7db0c0c94cad3ca11a139a5 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager v7 3/3] ui: import storage content: allow importing of vm disk images
By enabling the import button for qcow2/vmdk/raw files, and showing a
window with a VMID selector and the disk edit panel.
Change the edit panel so that when we give an explicit volume id
directly, we don't let the user select one. Instead it show it in a
displayfield.
Signed-off-by: Dominik Csapak
---
www/manager6/qemu/HDEdit.js | 180 +++-
www/manager6/storage/Browser.js | 22 ++--
2 files changed, 171 insertions(+), 31 deletions(-)
diff --git a/www/manager6/qemu/HDEdit.js b/www/manager6/qemu/HDEdit.js
index 38bfb883..0a9c718d 100644
--- a/www/manager6/qemu/HDEdit.js
+++ b/www/manager6/qemu/HDEdit.js
@@ -9,6 +9,7 @@ Ext.define('PVE.qemu.HDInputPanel', {
unused: false, // ADD usused disk imaged
importDisk: false, // use import options
+importSelection: undefined, // preselect a disk to import
vmconfig: {}, // used to select usused disks
@@ -240,31 +241,44 @@ Ext.define('PVE.qemu.HDInputPanel', {
autoSelect: me.insideWizard,
});
} else {
- column1.push({
- xtype: 'pveStorageSelector',
- reference: 'import-source',
- fieldLabel: gettext('Import Storage'),
- name: 'import-source-storage',
- storageContent: 'import',
- nodename: me.nodename,
- autoSelect: me.insideWizard,
- disabled: false,
- listeners: {
- change: function(_selector, storage) {
- me.lookup('import-source-file').setStorage(storage);
-
me.lookup('import-source-file').setDisabled(!storage);
+ if (me.importSelection) {
+ column1.push({
+ xtype: 'displayfield',
+ fieldLabel: gettext('Selected Image'),
+ value: me.importSelection,
+ });
+ column1.push({
+ xtype: 'hiddenfield',
+ name: 'import-from',
+ value: me.importSelection,
+ });
+ } else {
+ column1.push({
+ xtype: 'pveStorageSelector',
+ reference: 'import-source',
+ fieldLabel: gettext('Import Storage'),
+ name: 'import-source-storage',
+ storageContent: 'import',
+ nodename: me.nodename,
+ autoSelect: me.insideWizard,
+ disabled: false,
+ listeners: {
+ change: function(_selector, storage) {
+
me.lookup('import-source-file').setStorage(storage);
+
me.lookup('import-source-file').setDisabled(!storage);
+ },
},
- },
- });
- column1.push({
- xtype: 'pveFileSelector',
- reference: 'import-source-file',
- fieldLabel: gettext("Select Image"),
- storageContent: 'import',
- name: 'import-from',
- filter: (rec) => ['qcow2', 'vmdk',
'raw'].indexOf(rec?.data?.format) !== -1,
- nodename: me.nodename,
- });
+ });
+ column1.push({
+ xtype: 'pveFileSelector',
+ reference: 'import-source-file',
+ fieldLabel: gettext("Select Image"),
+ storageContent: 'import',
+ name: 'import-from',
+ filter: (rec) => ['qcow2', 'vmdk',
'raw'].indexOf(rec?.data?.format) !== -1,
+ nodename: me.nodename,
+ });
+ }
column1.push({
xtype: 'pveDiskStorageSelector',
reference: 'import-target',
@@ -553,3 +567,121 @@ Ext.define('PVE.qemu.HDEdit', {
});
},
});
+
+Ext.define('PVE.qemu.HDImportEdit', {
+extend: 'Proxmox.window.Edit',
+mixins: ['Proxmox.Mixin.CBind'],
+
+isAdd: true,
+isCreate: true,
+
+backgroundDelay: 5,
+
+width: 600,
+bodyPadding: 0,
+
+title: gettext('Import Hard Disk'),
+
+url: "dummy", // will be set on vmid change
+
+cbindData: function() {
+ let me = this;
+
+ if (!me.nodename) {
+ throw "no nodename given";
+ }
+
+ if (!me.selection) {
+ throw "no image preselected";
+ }
+
+ return {
+ nodename: me.nodename,
+ selection: me.selection,
+ };
+},
+
+controller: {
+ xclass: 'Ext.app.ViewController',
+
+ onVmidChange: function(_selector, value) {
+ let me = this;
+
[pve-devel] applied: [PATCH proxmox] fix #6143: notify: allow overriding notification templates
On Fri, 21 Mar 2025 14:33:41 +0100, Alexander Zeidler wrote:
> Previously, notification templates could be modified by the user, but
> these were overwritten again with installing newer package versions of
> pve-manager and proxmox-backup.
>
> Now override templates can be created cluster-wide in the path
> “/etc/{pve,proxmox-backup}/notification-templates/{namespace}”, which
> are used with priority. The folder structure has to be created and
> populated manually (e.g. /etc/pve/notification-templates/default).
>
> [...]
Applied, thanks!
[1/1] fix #6143: notify: allow overriding notification templates
commit: 684ffacdf9cc8991ccd183e99010bd0b464331f6
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v4 1/3] lxc: show dynamically assigned IPs in network tab
Am 08.04.25 um 13:27 schrieb Gabriel Goller: > I added the IP addresses and a "More" button to the Container Summary > and increased it's height, so as to make room for it. This make > everything look kinda weird (i.e., the GuestSummary panel is higher than > the CPU usage RRD graph.) But as I said, we could make it scrollable? Sounds like an OK stop-gap. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH-SERIES manager/qemu-server/docs 0/3] drop writeback cache setting
VirtIO-fs using writeback cache seems very broken at the moment. If a guest accesses a file (even just using 'touch'), that the host is currently writing, the guest can permanently end up with a truncated version of that file. Even subsequent operations like moving the file, will not result in the correct file being visible, but just rename the truncated one. manager: Fiona Ebner (1): ui: virtiofs edit: drop writeback checkbox www/manager6/qemu/VirtiofsEdit.js | 5 - 1 file changed, 5 deletions(-) qemu-server: Fiona Ebner (1): virtiofs: drop writeback option PVE/QemuServer/Virtiofs.pm | 8 1 file changed, 8 deletions(-) docs: Fiona Ebner (1): qm: virtiofs: drop writeback cache qm.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Summary over all repositories: 3 files changed, 2 insertions(+), 15 deletions(-) -- Generated by git-murpp 0.5.0 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH docs 3/3] qm: virtiofs: drop writeback cache
VirtIO-fs using writeback cache seems very broken at the moment. If a guest accesses a file (even just using 'touch'), that the host is currently writing, the guest can permanently end up with a truncated version of that file. Even subsequent operations like moving the file, will not result in the correct file being visible, but just rename the truncated one. Signed-off-by: Fiona Ebner --- qm.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/qm.adoc b/qm.adoc index 539912a..1babb82 100644 --- a/qm.adoc +++ b/qm.adoc @@ -1309,7 +1309,7 @@ has been configured in the resource mapping. Additionally, you can set the `cache` option to either `always`, `never`, `metadata`, or `auto` (default: `auto`), depending on your requirements. How the different caching modes behave can be read https://lwn.net/Articles/774495/[here under the "Caching Modes" -section]. To enable writeback cache set `writeback` to `1`. +section]. Virtiofsd supports ACL and xattr passthrough (can be enabled with the `expose-acl` and `expose-xattr` options), allowing the guest to access ACLs and @@ -1327,7 +1327,7 @@ applications do their own caching. qm set -virtiofs0 dirid=,cache=always,direct-io=1 qm set -virtiofs1 ,cache=never,expose-xattr=1 -qm set -virtiofs2 ,expose-acl=1,writeback=1 +qm set -virtiofs2 ,expose-acl=1 To temporarily mount virtio-fs in a guest VM with the Linux kernel virtio-fs -- 2.39.5 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager 1/3] ui: virtiofs edit: drop writeback checkbox
VirtIO-fs using writeback cache seems very broken at the moment. If a
guest accesses a file (even just using 'touch'), that the host is
currently writing, the guest can permanently end up with a truncated
version of that file. Even subsequent operations like moving the file,
will not result in the correct file being visible, but just rename the
truncated one.
Signed-off-by: Fiona Ebner
---
www/manager6/qemu/VirtiofsEdit.js | 5 -
1 file changed, 5 deletions(-)
diff --git a/www/manager6/qemu/VirtiofsEdit.js
b/www/manager6/qemu/VirtiofsEdit.js
index fe8dc930..6983a763 100644
--- a/www/manager6/qemu/VirtiofsEdit.js
+++ b/www/manager6/qemu/VirtiofsEdit.js
@@ -57,11 +57,6 @@ Ext.define('PVE.qemu.VirtiofsInputPanel', {
['never', 'never'],
],
},
- {
- xtype: 'proxmoxcheckbox',
- name: 'writeback',
- fieldLabel: gettext('Writeback cache'),
- },
{
xtype: 'proxmoxcheckbox',
name: 'expose-xattr',
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH http-server 3/3] anyevent: handle 'disconnected' flag in client_do_disconnect() itself
Commit f737984 ("fix #4816: do not disconnect twice if client sends no
data") introduced a 'disconnected' flag in the request state to avoid
duplicate calls to client_do_disconnect() for a given client. The flag
is only set and checked in the on_error callback of the handle
however. Do this more centrally at the beginning of the
client_do_disconnect() function itself to catch all callers and code
paths that could lead to a duplicate call. For example, while not
currently known to cause issues, the on_eof handler might re-enter the
function.
Signed-off-by: Fiona Ebner
---
src/PVE/APIServer/AnyEvent.pm | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/PVE/APIServer/AnyEvent.pm b/src/PVE/APIServer/AnyEvent.pm
index db14a7d..b71a9a5 100644
--- a/src/PVE/APIServer/AnyEvent.pm
+++ b/src/PVE/APIServer/AnyEvent.pm
@@ -136,6 +136,13 @@ sub cleanup_reqstate {
sub client_do_disconnect {
my ($self, $reqstate) = @_;
+# Avoid any re-entrant call. For example, the on_error callback can be
called twice for the same
+# connection/handle if the timeout is reached before any data has been
received. The on_error
+# callback might also get invoked as part of the stoptls() call during
shutdown below, which is
+# another situation where the function would be re-entered without this
check.
+return if $reqstate->{disconnected};
+$reqstate->{disconnected} = 1;
+
cleanup_reqstate($reqstate, 1);
my $shutdown_hdl = sub {
@@ -1911,13 +1918,7 @@ sub accept_connections {
my ($hdl, $fatal, $message) = @_;
eval {
$self->log_aborted_request($reqstate, $message);
- # this error callback can be called twice for the same
- # connection/handle if the timeout is reached before
- # any data has been received, avoid misleading errors
- if (!$reqstate->{disconnected}) {
- $reqstate->{disconnected} = 1;
- $self->client_do_disconnect($reqstate);
- }
+ $self->client_do_disconnect($reqstate);
};
if (my $err = $@) { syslog('err', "$err"); }
},
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH proxmox-i18n] update Spanish translations
Signed-off-by: Maximiliano Sandoval
---
es.po | 43 ---
1 file changed, 20 insertions(+), 23 deletions(-)
diff --git a/es.po b/es.po
index afa25b1..2506f23 100644
--- a/es.po
+++ b/es.po
@@ -8,7 +8,7 @@ msgstr ""
"Project-Id-Version: proxmox translations\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: Tue Apr 8 12:23:34 2025\n"
-"PO-Revision-Date: 2025-04-08 09:57+0200\n"
+"PO-Revision-Date: 2025-04-08 13:15+0200\n"
"Last-Translator: Maximiliano Sandoval \n"
"Language-Team: Spanish\n"
"Language: es\n"
@@ -367,9 +367,8 @@ msgid "Add Datastore"
msgstr "Agregar almacén de datos"
#: pve-manager/www/manager6/window/DirMapEdit.js:26
-#, fuzzy
msgid "Add Directory Mapping"
-msgstr "Almacenamiento de directorio"
+msgstr "Agregar mapeo de directorio"
#: pve-manager/www/manager6/qemu/SystemEdit.js:117
msgid "Add EFI Disk"
@@ -635,7 +634,7 @@ msgstr "Permitir debugging"
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:87
msgid "Allow Direct IO"
-msgstr ""
+msgstr "Permitir IO directo"
#: pmg-gui/js/SpamQuarantineOptions.js:68
#: pmg-gui/js/VirusQuarantineOptions.js:20
@@ -3090,19 +3089,19 @@ msgstr "Directorio"
#: pve-manager/www/manager6/form/DirMapSelector.js:24
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:34
-#, fuzzy
msgid "Directory ID"
-msgstr "Directorio"
+msgstr "ID de directorio"
#: pve-manager/www/manager6/dc/Config.js:337
-#, fuzzy
msgid "Directory Mappings"
-msgstr "Almacenamiento de directorio"
+msgstr "Mapeos de directorios"
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:42
msgid ""
"Directory Mappings can be managed under Datacenter -> Directory Mappings"
msgstr ""
+"Los mapeos de directorios pueden gestionarse en Centro de datos -> Mapeos de "
+"directorios"
#: pve-manager/www/manager6/Utils.js:2022 proxmox-backup/www/Utils.js:409
msgid "Directory Storage"
@@ -3697,7 +3696,7 @@ msgstr "Activar quota"
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:69
msgid "Enable support for extended attributes."
-msgstr ""
+msgstr "Activar el soporte para atributos extendidos."
#: proxmox-widget-toolkit/src/Utils.js:46
#: proxmox-widget-toolkit/src/node/APTRepositories.js:242
@@ -4801,7 +4800,7 @@ msgstr "Grupos"
#: pve-manager/www/manager6/dc/AuthEditOpenId.js:97
msgid "Groups Claim"
-msgstr ""
+msgstr "Solicitud de grupos"
#: pmg-gui/js/LDAPConfig.js:427
msgid "Groups of '{0}'"
@@ -5096,9 +5095,8 @@ msgid "ID {0}"
msgstr "ID {0}"
#: pve-manager/www/manager6/dc/DirMapView.js:25
-#, fuzzy
msgid "ID/Node"
-msgstr "ID/Nodo/Ruta"
+msgstr "ID/Nodo"
#: pve-manager/www/manager6/dc/PCIMapView.js:83
msgid "ID/Node/Path"
@@ -5247,7 +5245,7 @@ msgstr "Ignorar la información del encabezado"
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:75
msgid "Implies xattr support."
-msgstr ""
+msgstr "Implica soporte de xattr."
#: pve-manager/www/manager6/Utils.js:694
#: pve-manager/www/manager6/storage/Browser.js:146
@@ -6285,9 +6283,8 @@ msgstr ""
"Los recursos asignados ({0}) no están disponibles en el destino seleccionado."
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:35
-#, fuzzy
msgid "Mapping ID"
-msgstr "Mapeo en el nodo"
+msgstr "ID de mapeo"
#: pve-manager/www/manager6/form/PCIMapSelector.js:52
#: pve-manager/www/manager6/form/USBMapSelector.js:37
@@ -8115,7 +8112,7 @@ msgstr "Modo del Autoscaler de PGs"
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:74
msgid "POSIX ACLs"
-msgstr ""
+msgstr "POSIX ACLs"
#: proxmox-widget-toolkit/src/node/APT.js:19
#: pve-manager/www/manager6/storage/TemplateView.js:71
@@ -12473,6 +12470,8 @@ msgid ""
"Uploads are stored temporarily in '/var/tmp/', make sure there is enough "
"free space."
msgstr ""
+"Las subidas se almacenaran temporalmente en '/var/tmp/', asegúrate de que "
+"hay suficiente espacio libre."
#: pve-manager/www/manager6/dc/OptionView.js:338
msgid "Upper"
@@ -12784,7 +12783,7 @@ msgstr "Nombre de usuario"
#: proxmox-widget-toolkit/src/window/AuthEditOpenId.js:84
#: pve-manager/www/manager6/dc/AuthEditOpenId.js:68
msgid "Username Claim"
-msgstr "Solicitud del usuario"
+msgstr "Solicitud de usuario"
#: pve-manager/www/manager6/dc/AuthEditLDAP.js:266
#: pve-manager/www/manager6/dc/Config.js:92
@@ -13120,11 +13119,11 @@ msgstr "RNG VirtIO"
#: pve-manager/www/manager6/qemu/HardwareView.js:330
#: pve-manager/www/manager6/qemu/HardwareView.js:764
msgid "Virtiofs"
-msgstr ""
+msgstr "Virtiofs"
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:100
msgid "Virtiofs Filesystem Passthrough"
-msgstr ""
+msgstr "Passthrough de sistema de archivos virtiofs"
#: proxmox-widget-toolkit/src/Schema.js:97
msgid "Virtual"
@@ -13488,9 +13487,8 @@ msgid "Write max burst"
msgstr "Ráfagas máximas de escritura"
#: pve-manager/www/manager6/qemu/VirtiofsEdit.js:63
-#, fuzzy
msgid "Writeback cache"
-msgstr "Caché de escritura"
+msgstr "Caché writeback"
#: pve-manager/www/manager6/ceph/Status.js:304
#: pve-manager/www/manager6/cep
Re: [pve-devel] [PATCH pve-network 1/1] ipam: netbox: fix adding vms without a name set in the options
Am 08.04.25 um 15:25 schrieb Stefan Hanreich:
> The hostname provided to the methods in the IPAM plugins is empty for
> VMs that do not have a name set. We always included the dns_name key
> in the request, even if it was undefined, which leads Netbox to return
> a 400 Bad Request error. With this patch we omit the dns_name
> parameter if it isn't set, so the call succeeds.
We default to "CT${VMID}" and "VM${VMID}" in that case though everywhere
such a hostname is required, that does not make sense here, or?
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-network 1/1] ipam: netbox: fix adding vms without a name set in the options
The hostname provided to the methods in the IPAM plugins is empty for
VMs that do not have a name set. We always included the dns_name key
in the request, even if it was undefined, which leads Netbox to return
a 400 Bad Request error. With this patch we omit the dns_name
parameter if it isn't set, so the call succeeds.
Signed-off-by: Stefan Hanreich
---
src/PVE/Network/SDN/Ipams/NetboxPlugin.pm | 36 +++
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/src/PVE/Network/SDN/Ipams/NetboxPlugin.pm
b/src/PVE/Network/SDN/Ipams/NetboxPlugin.pm
index a691323..97a0c3f 100644
--- a/src/PVE/Network/SDN/Ipams/NetboxPlugin.pm
+++ b/src/PVE/Network/SDN/Ipams/NetboxPlugin.pm
@@ -206,11 +206,14 @@ sub add_ip {
}
eval {
- netbox_api_request($plugin_config, "POST", "/ipam/ip-addresses/", {
+ my $params = {
address => "$ip/$mask",
- dns_name => $hostname,
description => $description,
- });
+ };
+
+ $params->{dns_name} = $hostname if $hostname;
+
+ netbox_api_request($plugin_config, "POST", "/ipam/ip-addresses/",
$params);
};
if ($@) {
@@ -244,11 +247,14 @@ sub update_ip {
}
eval {
- netbox_api_request($plugin_config, "PATCH",
"/ipam/ip-addresses/$ip_id/", {
+ my $params = {
address => "$ip/$mask",
- dns_name => $hostname,
description => $description,
- });
+ };
+
+ $params->{dns_name} = $hostname if $hostname;
+
+ netbox_api_request($plugin_config, "PATCH",
"/ipam/ip-addresses/$ip_id/", $params);
};
if ($@) {
die "error update ip $ip : $@" if !$noerr;
@@ -272,10 +278,13 @@ sub add_next_freeip {
$description = "mac:$mac" if $mac;
my $ip = eval {
- my $result = netbox_api_request($plugin_config, "POST",
"/ipam/prefixes/$internalid/available-ips/", {
- dns_name => $hostname,
+ my $params = {
description => $description,
- });
+ };
+
+ $params->{dns_name} = $hostname if $hostname;
+
+ my $result = netbox_api_request($plugin_config, "POST",
"/ipam/prefixes/$internalid/available-ips/", $params);
my ($ip, undef) = split(/\//, $result->{address});
return $ip;
@@ -303,10 +312,13 @@ sub add_range_next_freeip {
$description = "mac:$data->{mac}" if $data->{mac};
my $ip = eval {
- my $result = netbox_api_request($plugin_config, "POST",
"/ipam/ip-ranges/$internalid/available-ips/", {
- dns_name => $data->{hostname},
+ my $params = {
description => $description,
- });
+ };
+
+ $params->{dns_name} = $data->{hostname} if $data->{hostname};
+
+ my $result = netbox_api_request($plugin_config, "POST",
"/ipam/ip-ranges/$internalid/available-ips/", $params);
my ($ip, undef) = split(/\//, $result->{address});
print "found ip free $ip in range
$range->{'start-address'}-$range->{'end-address'}\n" if $ip;
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server v7 2/4] api: status/current: add display property
Am 08.04.25 um 14:27 schrieb Aaron Lauterer: > This new property returns the configured or default display for a VM. > > Instead of a flat property, we use a nested 'type' object that contains > the actual information. This way we can add other properties that belong > to a VM's display in the future without much hassle, to have them all in > one place. > Candidates to be moved into the display property are for example the > spice and clipboard property. > > Signed-off-by: Aaron Lauterer Reviewed-by: Fiona Ebner ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 1/1] ipam: netbox: fix adding vms without a name set in the options
On 4/8/25 15:29, Thomas Lamprecht wrote:
> Am 08.04.25 um 15:25 schrieb Stefan Hanreich:
>> The hostname provided to the methods in the IPAM plugins is empty for
>> VMs that do not have a name set. We always included the dns_name key
>> in the request, even if it was undefined, which leads Netbox to return
>> a 400 Bad Request error. With this patch we omit the dns_name
>> parameter if it isn't set, so the call succeeds.
>
> We default to "CT${VMID}" and "VM${VMID}" in that case though everywhere
> such a hostname is required, that does not make sense here, or?
That doesn't seem to be the case currently, at least during my tests. I
could look into solving it that way, if that's preferred.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH proxmox-firewall 1/1] guest: do not try to create map entries if there are no devices
When the firewall was enabled for a guest, but disabled for all
interfaces of a guest, the firewall tried to add an empty list to the
guest map, which is an invalid nftables statement.
Signed-off-by: Stefan Hanreich
---
proxmox-firewall/src/firewall.rs | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/proxmox-firewall/src/firewall.rs b/proxmox-firewall/src/firewall.rs
index e1c9351..086b96c 100644
--- a/proxmox-firewall/src/firewall.rs
+++ b/proxmox-firewall/src/firewall.rs
@@ -955,7 +955,7 @@ impl Firewall {
let network_devices = config.network_config().network_devices();
if !network_devices.is_empty() {
-let map_elements = network_devices
+let map_elements: Vec<(Expression, MapValue)> = network_devices
.iter()
.filter(|(_, device)| device.has_firewall())
.map(|(index, _)| {
@@ -965,12 +965,15 @@ impl Firewall {
target: chain.name().to_string(),
}),
)
-});
+})
+.collect();
-commands.push(Add::element(AddElement::map_from_expressions(
-Self::guest_vmap(direction),
-map_elements,
-)));
+if !map_elements.is_empty() {
+commands.push(Add::element(AddElement::map_from_expressions(
+Self::guest_vmap(direction),
+map_elements,
+)));
+}
}
self.create_log_rule(
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager] ui: qemu: hardware view: fix hwrng cap check for unprivileged users
On Tue, 8 Apr 2025 18:38:56 +0200
Friedrich Weber wrote:
> Currently, as an unprivileged user with role PVEVMUser the GUI breaks
> with an error after navigating to a VM's hardware tab. The reason is
> that the frontend checks the GUI capabilites via `caps.mapping.hwrng`,
> but `caps.mapping` does not actually have a property called `hwrng`.
>
> The reason this does not trigger for more privileged users is that all
> expressions involving `caps.mapping.hwrng` are short-circuited if the
> user has privilege `VM.Config.Type`, so `caps.mapping.hwrng` is never
> evaluated.
>
> Fixes: a47a8afb ("ui: let non-root users configure VirtIO RNG devices")
> Signed-off-by: Friedrich Weber
Thanks for tackling this so quick!
Managed to reproduce the original issue - your patch fixes it for me as
well!
it improves the current situation significantly:
Reviewed-by: Stoiko Ivanov
Tested-by: Stoiko Ivanov
In general I think the permissions seems a sensible choice (Mapping.Use
on /mapping/hwrng ) (we used Sys.Console for the RNG before (and for
other similarly sensitive places, as very high privilege below root@pam
only)
as talked with Friedrich off-list - understanding how the negation affects
what is displayed and what not in the menues took us a bit too long.
I'll send a follow-up to unify pci and usb-device add-entry enabling with
the the one for the RNG (the backend seems to use the same for all 3)
> ---
>
> Notes:
> I wasn't actually sure whether `caps` may have such a 2-level structure
> in some cases, but it doesn't seem like it. After applying this patch
> to pve-manager:
>
> % ag 'caps\.[^\[.]+\.' | wc -l
> 0
>
> www/manager6/qemu/HardwareView.js | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/www/manager6/qemu/HardwareView.js
> b/www/manager6/qemu/HardwareView.js
> index 4ce9908c..b949264f 100644
> --- a/www/manager6/qemu/HardwareView.js
> +++ b/www/manager6/qemu/HardwareView.js
> @@ -316,8 +316,8 @@ Ext.define('PVE.qemu.HardwareView', {
> rows.rng0 = {
> group: 45,
> tdCls: 'pve-itype-icon-die',
> - editor: caps.vms['VM.Config.HWType'] ||
> caps.mapping.hwrng['Mapping.Use'] ? 'PVE.qemu.RNGEdit' : undefined,
> - never_delete: !caps.vms['VM.Config.HWType'] &&
> !caps.mapping.hwrng['Mapping.Use'],
> + editor: caps.vms['VM.Config.HWType'] || caps.mapping['Mapping.Use']
> ? 'PVE.qemu.RNGEdit' : undefined,
> + never_delete: !caps.vms['VM.Config.HWType'] &&
> !caps.mapping['Mapping.Use'],
> header: gettext("VirtIO RNG"),
> };
> for (let i = 0; i < PVE.Utils.hardware_counts.virtiofs; i++) {
> @@ -757,7 +757,7 @@ Ext.define('PVE.qemu.HardwareView', {
> text: gettext("VirtIO RNG"),
> itemId: 'addRng',
> iconCls: 'pve-itype-icon-die',
> - disabled: !caps.vms['VM.Config.HWType'] &&
> !caps.mapping.hwrng['Mapping.Use'],
> + disabled: !caps.vms['VM.Config.HWType'] &&
> !caps.mapping['Mapping.Use'],
> handler: editorFactory('RNGEdit'),
> },
> {
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH http-server 1/3] anyevent: disconnect: check that handle is still defined before calling shutdown()
Commit 07e56cc ("fix unexpected EOF for client when closing TLS
session") added a call to stoptls() before the call to shutdown() for
the handle's file descriptor. However, the documentation for
AnyEvent[0] mentions for stoptls():
> This method may invoke callbacks (and therefore the handle might be
> destroyed after it returns).
Therefore, it is necessary to check that the handle is still defined
before calling shutdown(). Otherwise, this can result in a warning:
> Can't use an undefined value as a symbol reference at
> /usr/share/perl5/PVE/APIServer/AnyEvent.pm line 150.
as reported in the community forum [1].
The debug print message for closing the file handle is split up,
because part of it relies on the file handle to be defined.
[0]: https://metacpan.org/pod/AnyEvent::Handle#$handle-%3Estoptls
[1]: https://forum.proxmox.com/threads/164744/
Fixes: 07e56cc ("fix unexpected EOF for client when closing TLS session")
Signed-off-by: Fiona Ebner
---
src/PVE/APIServer/AnyEvent.pm | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/PVE/APIServer/AnyEvent.pm b/src/PVE/APIServer/AnyEvent.pm
index 9b18ee2..3f8642b 100644
--- a/src/PVE/APIServer/AnyEvent.pm
+++ b/src/PVE/APIServer/AnyEvent.pm
@@ -146,8 +146,11 @@ sub client_do_disconnect {
$hdl->on_read(undef);
$hdl->on_eof(undef);
- $hdl->stoptls();
- shutdown($hdl->{fh}, 1);
+ $self->dprint("CLOSE FH" . $hdl->{fh}->fileno());
+
+ $hdl->stoptls(); # can invoke callbacks and destroy the handle
+
+ shutdown($hdl->{fh}, 1) if defined($hdl) && defined($hdl->{fh});
};
if (my $proxyhdl = delete $reqstate->{proxyhdl}) {
@@ -170,7 +173,7 @@ sub client_do_disconnect {
$self->{conn_count}--;
-$self->dprint("CLOSE FH" . $hdl->{fh}->fileno() . "
CONN$self->{conn_count}");
+$self->dprint("DISCONNECT CONN$self->{conn_count}");
}
sub finish_response {
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-http-server v2 1/1] fix unexpected EOF for client when closing TLS session
> Fiona Ebner hat am 08.04.2025 09:27 CEST geschrieben: > > > Am 05.03.25 um 22:45 schrieb Rob Rozestraten via pve-devel: > > When pve-http-server initiates the closure of a TLS session, it does not > > send a TLS close notify, resulting in an unexpected EOF error on systems > > with recent crypto policies. This can break functionality with other > > applications, such as Foreman[0]. > > > > This behavior can be observed in the following cases: > > > > * client uses HTTP/1.0 (no keepalive; server closes connection) > > * client sends no data for 5 sec (timeout; server closes connection) > > * server responds with 400 (no keepalive; server closes connection) > > > > This patch sends the TLS close notify prior to socket teardown, > > resulting in clean closure of TLS connections and no client error. > > > > It also moves shutdown() to after the clearing of handlers. The reason > > for this is stoptls() must come before shutdown(), but it also triggers > > on_drain(), which calls client_do_disconnect() again. The extra call to > > client_do_disconnect() is avoided inside accept_connections() by commit > > f737984, but perhaps clearing the handlers prior to shutdown() will > > avoid it in all cases. > > > > [0]: https://github.com/theforeman/foreman_fog_proxmox/issues/325 > > > > I feel like the questions regarding blocking/missing client ack from > Fabian from v1 are not answered yet: > > > If I read the docs right, this could block (would that be an issue here?) > > and could potentially destroy the handle (so that might need to be > > rechecked afterwards to prevent spurious warnings?) > > > > what happens if we initiate the teardown, and the client never acks it? there was some more input in a separate mail: https://lore.proxmox.com/pve-devel/mailman.799.1741211155.293.pve-de...@lists.proxmox.com/ ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager] ui: qemu: unify enabled state of pci, usb and rng
all 3 additions fail in the backend, if a user does not have
VM.Config.HWType on the VM.
unify their display to cause less confusion, to the most recently
added version for the rng.
drop the now unused noHWPerm (eslint reminded me about that).
found while reviewing:
https://lore.proxmox.com/all/20250408195959.0b1f3...@rosa.proxmox.com/T/#t
Signed-off-by: Stoiko Ivanov
---
www/manager6/qemu/HardwareView.js | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/www/manager6/qemu/HardwareView.js
b/www/manager6/qemu/HardwareView.js
index b949264f..480bbb3d 100644
--- a/www/manager6/qemu/HardwareView.js
+++ b/www/manager6/qemu/HardwareView.js
@@ -599,7 +599,6 @@ Ext.define('PVE.qemu.HardwareView', {
});
// heuristic only for disabling some stuff, the backend has the
final word.
- const noHWPerm = !caps.nodes['Sys.Console'] &&
!caps.mapping['Mapping.Use'];
const noVMConfigHWTypePerm = !caps.vms['VM.Config.HWType'];
const noVMConfigNetPerm = !caps.vms['VM.Config.Network'];
const noVMConfigDiskPerm = !caps.vms['VM.Config.Disk'];
@@ -607,8 +606,8 @@ Ext.define('PVE.qemu.HardwareView', {
const noVMConfigCloudinitPerm = !caps.vms['VM.Config.Cloudinit'];
const noVMConfigOptionsPerm = !caps.vms['VM.Config.Options'];
- me.down('#addUsb').setDisabled(noHWPerm || isAtUsbLimit());
- me.down('#addPci').setDisabled(noHWPerm || isAtLimit('hostpci'));
+ me.down('#addUsb').setDisabled(noVMConfigHWTypePerm ||
isAtUsbLimit());
+ me.down('#addPci').setDisabled(noVMConfigHWTypePerm ||
isAtLimit('hostpci'));
me.down('#addAudio').setDisabled(noVMConfigHWTypePerm ||
isAtLimit('audio'));
me.down('#addSerial').setDisabled(noVMConfigHWTypePerm ||
isAtLimit('serial'));
me.down('#addNet').setDisabled(noVMConfigNetPerm ||
isAtLimit('net'));
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH installer] auto: add some error context when loading the first-boot executable
Am 08.04.25 um 11:06 schrieb Christoph Heiss:
> @@ -47,7 +47,9 @@ fn setup_first_boot_executable(first_boot:
> &FirstBootHookInfo) -> Result<()> {
> }
> }
> FirstBootHookSourceMode::FromIso => {
> -Some(fs::read(format!("/cdrom/{FIRST_BOOT_EXEC_NAME}"))?)
> +Some(fs::read(format!("/cdrom/{FIRST_BOOT_EXEC_NAME}")).context(
> +"failed loading first-boot executable from ISO (was
> --on-first-boot specified?)",
Definitively better than the status quo, but as user I would then ask
myself how I can pass that flag to the installer, so maybe word it
something like:
"failed loading first-boot executable from ISO (was ISO prepared with
--on-first-boot specified?"
Or is this caught already earlier?
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH guest-common 1/2] d/control: bump dependency for libpve-cluster-perl
On Tue, 08 Apr 2025 10:12:31 +0200, Fiona Ebner wrote: > For example, otherwise build of qemu-server will fail with: > > unknown file 'mapping/directory.cfg' at /usr/share/perl5/PVE/Cluster.pm > if libpve-cluster-perl is not recent enough and there most likely are > runtime issues too. > Applied, reworded the changelog entry a bit though, thanks! [1/2] d/control: bump dependency for libpve-cluster-perl commit: ca3f9a69a3f2b4e03f4da195fc5da08b7cde0cfd [2/2] bump version to 5.2.2 commit: 58ad1835bf48ac8a62877cc8889c67b49330113f [1/1] d/control: bump (build-)dependency for libpve-guest-common-perl commit dfdd5c368987f78e639be32bd84096a19d6528a2 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server v6 1/4] QemuServer: make get_vga_properties and extract_version public
Am 08.04.25 um 12:37 schrieb Aaron Lauterer:
> Signed-off-by: Aaron Lauterer
> ---
> newly introduced with v6
>
> PVE/QemuServer.pm | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index ccdceed..b7ef69b 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -1159,7 +1159,7 @@ sub kvm_version {
> return $kvm_api_version;
> }
>
> -my sub extract_version {
> +sub extract_version {
This is named too generally to make public. And there is no need to make
it public if you use PVE::QemuServer::Machine::extract_version() for the
new caller in the next patch. We could think about merging this helper
with PVE::QemuServer::Machine::extract_version(), but totally orthogonal
to this series.
> my ($machine_type, $version) = @_;
> $version = kvm_user_version() if !defined($version);
> return PVE::QemuServer::Machine::extract_version($machine_type, $version)
> @@ -3414,7 +3414,7 @@ my sub print_ovmf_drive_commandlines {
> return ("if=pflash,unit=0,format=raw,readonly=on,file=$ovmf_code",
> $var_drive_str);
> }
>
> -my sub get_vga_properties {
> +sub get_vga_properties {
> my ($conf, $arch, $machine_version, $winversion) = @_;
>
> my $vga = parse_vga($conf->{vga});
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager v7 3/4] fix #1926 ui: vm console: autodetect novnc or xtermjs
Some users configure their VMs to use serial as their display. The big
benefit is that in combination with the xtermjs remote console, copy &
paste works a lot better than via novnc.
While the console button in the top right allows to manually choose the
console type, the Console in the main submenu of a VM does not.
This patch changes the behavior to not load the console right away if
set to 'kvm'. Instead, the callback from the VM's status/current call
will run the final steps to load the console. Because then we know if it
should be noVNC or xtermjs.
That means that in the VNCConsole component we need to keep track if the
console has been fully set up and is running. The actual code that loads
the console into the iframe is moved into a function, so we cann call it
from the API callback.
One result is that the behavior changes. Loading the console on a VM
will take a little bit longer:
* When then Console is the selected and one switches between VMs, a new
status/current call is made and on a good connection, the console
should load just a few moments later.
* When one switches to the console from another submenu of the VM, the
console will load once the next API call to status/current finished.
Signed-off-by: Aaron Lauterer
Reviewed-by: Dominik Csapak
---
changes since:
v6: none
v5:
* introduce PVE.Utils.isSerialDisplay helper
* avoid 'rec' assignment in callback when setting the 'xtermjs' variable
v4:
* use new status/current display property
v3:
* fixed spacing issues
* add 'current' parameter when fetching config as the pending might have
a different display set
v2:
* change approach and do it in the UI alone by fetching the VM
config before deciding which console to use
v1:
* set 'autodetect' to always true in 'VNCConsole.js'
* add additional checks in pveproxy
* only if autodetect is enabled and console is set to 'kvm'
* username exists and has VM.Console permissions for the guest
www/manager6/Utils.js | 4 +++
www/manager6/VNCConsole.js | 52 +
www/manager6/qemu/Config.js | 7 -
3 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js
index a1bcbe7e..d6fd6a9e 100644
--- a/www/manager6/Utils.js
+++ b/www/manager6/Utils.js
@@ -1986,6 +1986,10 @@ Ext.define('PVE.Utils', {
);
return Ext.htmlEncode(description);
},
+
+isSerialDisplay: function(display) {
+ return display?.startsWith('serial') ?? false;
+},
},
singleton: true,
diff --git a/www/manager6/VNCConsole.js b/www/manager6/VNCConsole.js
index 9057e447..3371c923 100644
--- a/www/manager6/VNCConsole.js
+++ b/www/manager6/VNCConsole.js
@@ -12,6 +12,36 @@ Ext.define('PVE.noVncConsole', {
layout: 'fit',
border: false,
+setupDone: false, // initial setup is done and the session is running
+
+loadConsole: function(xtermjs, consoleType) {
+ let me = this;
+ if (me.setupDone) {
+ return;
+ }
+
+ let type = xtermjs ? 'xtermjs' : 'novnc';
+ let sp = Ext.state.Manager.getProvider();
+ if (Ext.isFunction(me.beforeLoad)) {
+ me.beforeLoad();
+ }
+ let queryDict = {
+ console: consoleType, // kvm, lxc, upgrade or shell
+ vmid: me.vmid,
+ node: me.nodename,
+ cmd: me.cmd,
+ 'cmd-opts': me.cmdOpts,
+ resize: sp.get('novnc-scaling', 'scale'),
+ };
+ let box = this.down('[itemid=vncconsole]');
+ queryDict[type] = 1;
+ PVE.Utils.cleanEmptyObjectKeys(queryDict);
+ let url = '/?' + Ext.Object.toQueryString(queryDict);
+ Proxmox.Utils.setErrorMask(me);
+ box.load(url);
+ me.setupDone = true;
+},
+
initComponent: function() {
var me = this;
@@ -29,37 +59,25 @@ Ext.define('PVE.noVncConsole', {
// always use same iframe, to avoid running several noVnc clients
// at same time (to avoid performance problems)
- var box = Ext.create('Ext.ux.IFrame', { itemid: "vncconsole" });
+ let box = Ext.create('Ext.ux.IFrame', { itemid: "vncconsole" });
- var type = me.xtermjs ? 'xtermjs' : 'novnc';
Ext.apply(me, {
items: box,
listeners: {
activate: function() {
- let sp = Ext.state.Manager.getProvider();
- if (Ext.isFunction(me.beforeLoad)) {
- me.beforeLoad();
+ if (me.consoleType !== 'kvm') {
+ me.loadConsole(me.xtermjs, me.consoleType);
}
- let queryDict = {
- console: me.consoleType, // kvm, lxc, upgrade or shell
- vmid: me.vmid,
- node: me.nodename,
- cmd: me.cmd,
- 'cmd-opts': me.cmdOpts,
- resize: sp.get('novnc-scaling', 'scale'),
-
[pve-devel] [PATCH qemu-server v7 1/4] QemuServer: add new public get_default_vga_type function
by moving that part out of get_vga_properties.
We resolve missing parameters if necessary to make it easier to call
from another module where we likely only have the VM config ready.
Signed-off-by: Aaron Lauterer
---
changes since v6:
instead of making get_vga_properties and extract_version public, we
create the new get_default_vga_type function and only make it public.
PVE/QemuServer.pm | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index ccdceed..cc08f6f 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -3414,6 +3414,27 @@ my sub print_ovmf_drive_commandlines {
return ("if=pflash,unit=0,format=raw,readonly=on,file=$ovmf_code",
$var_drive_str);
}
+sub get_default_vga_type {
+my ($conf, $arch, $machine_version, $winversion) = @_;
+
+$arch //= PVE::QemuServer::Helpers::get_vm_arch($conf);
+$winversion //= PVE::QemuServer::Helpers::windows_version($conf->{ostype});
+if (!$machine_version) {
+ my $kvm_binary = PVE::QemuServer::Helpers::get_command_for_arch($arch);
+ my $kvmver = kvm_user_version($kvm_binary);
+ my $machine_type = PVE::QemuServer::Machine::get_vm_machine($conf,
undef, $arch);
+ $machine_version = extract_version($machine_type, $kvmver);
+}
+
+if ($arch eq 'aarch64') {
+ return 'virtio';
+} elsif (min_version($machine_version, 2, 9)) {
+ return (!$winversion || $winversion >= 6) ? 'std' : 'cirrus';
+} else {
+ return ($winversion >= 6) ? 'std' : 'cirrus';
+}
+}
+
my sub get_vga_properties {
my ($conf, $arch, $machine_version, $winversion) = @_;
@@ -3423,13 +3444,7 @@ my sub get_vga_properties {
$vga->{type} = 'qxl' if $qxlnum;
if (!$vga->{type}) {
- if ($arch eq 'aarch64') {
- $vga->{type} = 'virtio';
- } elsif (min_version($machine_version, 2, 9)) {
- $vga->{type} = (!$winversion || $winversion >= 6) ? 'std' :
'cirrus';
- } else {
- $vga->{type} = ($winversion >= 6) ? 'std' : 'cirrus';
- }
+ $vga->{type} = get_default_vga_type($conf, $arch, $machine_version,
$winversion);
}
return ($vga, $qxlnum);
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server v7 2/4] api: status/current: add display property
This new property returns the configured or default display for a VM.
Instead of a flat property, we use a nested 'type' object that contains
the actual information. This way we can add other properties that belong
to a VM's display in the future without much hassle, to have them all in
one place.
Candidates to be moved into the display property are for example the
spice and clipboard property.
Signed-off-by: Aaron Lauterer
---
changes since
v6:
* use the new QemuServer::get_default_vga_type function, which means we
can drop a lot of boilerplate code
v5:
* use QemuServer::get_vga_properties to determine the default
* properties.
PVE/API2/Qemu.pm | 13 +
1 file changed, 13 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 626cce4..d7305d5 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3074,6 +3074,16 @@ __PACKAGE__->register_method({
enum => ['vnc'],
optional => 1,
},
+ display => {
+ description => "Display settings",
+ type => 'object',
+ properties => {
+ type => {
+ description => "Display type configured",
+ type => 'string',
+ },
+ },
+ },
},
},
code => sub {
@@ -3087,8 +3097,11 @@ __PACKAGE__->register_method({
$status->{ha} =
PVE::HA::Config::get_service_status("vm:$param->{vmid}");
+ $status->{display}->{type} =
PVE::QemuServer::get_default_vga_type($conf);
if ($conf->{vga}) {
my $vga = PVE::QemuServer::parse_vga($conf->{vga});
+ $status->{display}->{type} = $vga->{type} if defined($vga->{type});
+
my $spice = defined($vga->{type}) && $vga->{type} =~ /^virtio/;
$spice ||= PVE::QemuServer::vga_conf_has_spice($conf->{vga});
$status->{spice} = 1 if $spice;
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager v7 4/4] ui: console: check on activate if display info for VMs is present
If we already have the display information for a VM, we can proceed
loading the correct console (noVNC or xtermjs).
This way, we don't need to wait for the callback of the VM's
status/current API call to finish setting up the console.
Signed-off-by: Aaron Lauterer
---
changes since
v6: none
v5:
* use new helper to check if serial
www/manager6/VNCConsole.js | 8
1 file changed, 8 insertions(+)
diff --git a/www/manager6/VNCConsole.js b/www/manager6/VNCConsole.js
index 3371c923..200145c0 100644
--- a/www/manager6/VNCConsole.js
+++ b/www/manager6/VNCConsole.js
@@ -67,6 +67,14 @@ Ext.define('PVE.noVncConsole', {
activate: function() {
if (me.consoleType !== 'kvm') {
me.loadConsole(me.xtermjs, me.consoleType);
+ } else {
+ let display = me.up().statusStore.getById('display');
+ if
(PVE.Utils.isSerialDisplay(display?.data.value.type)) {
+ me.xtermjs = true;
+ }
+ if (display) {
+ me.loadConsole(me.xtermjs, me.consoleType);
+ }
}
},
},
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server v7 1/4] QemuServer: add new public get_default_vga_type function
Nit: please don't use "QemuServer" as a prefix in the commit subject.
That contains no additional information (for humans, but also machines
can already see the modified file).
Am 08.04.25 um 14:27 schrieb Aaron Lauterer:
> by moving that part out of get_vga_properties.
>
> We resolve missing parameters if necessary to make it easier to call
> from another module where we likely only have the VM config ready.
>
> Signed-off-by: Aaron Lauterer
Reviewed-by: Fiona Ebner
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index ccdceed..cc08f6f 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -3414,6 +3414,27 @@ my sub print_ovmf_drive_commandlines {
> return ("if=pflash,unit=0,format=raw,readonly=on,file=$ovmf_code",
> $var_drive_str);
> }
>
> +sub get_default_vga_type {
> +my ($conf, $arch, $machine_version, $winversion) = @_;
> +
> +$arch //= PVE::QemuServer::Helpers::get_vm_arch($conf);
> +$winversion //=
> PVE::QemuServer::Helpers::windows_version($conf->{ostype});
> +if (!$machine_version) {
> + my $kvm_binary = PVE::QemuServer::Helpers::get_command_for_arch($arch);
> + my $kvmver = kvm_user_version($kvm_binary);
> + my $machine_type = PVE::QemuServer::Machine::get_vm_machine($conf,
> undef, $arch);
> + $machine_version = extract_version($machine_type, $kvmver);
Nit: could have used the PVE::QemuServer::Machine::extract_version() helper.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH esxi-import-tools v2] listvms: exclude VMs without datastore_name from manifest.json
On newer ESXI-8x versions, the diskless vCLS machines in an
ESXI-cluster are not stored on a datastore anymore.
Instead, they are placed under `/var/run/crx` on the ESXI-hosts'
filesystem. This can lead to issues with the ESXI-storage not being
activated on the PVE-side [0].
This commit prevents these machines from being included in `manifest.json`.
It also excludes VMs without a datastore string in its configuration.
[0]
https://forum.proxmox.com/threads/new-import-wizard-available-for-migrating-vmware-esxi-based-virtual-machines.144023/post-759288
---
This supersedes:
https://lore.proxmox.com/pve-devel/875xjft34o@proxmox.com/T/#t
Changes from v1:
* query the ESXI VM config more purposefully -- thanks @Wolfgang
* prepare logging of dropped VMs to stderr
listvms.py | 14 ++
1 file changed, 14 insertions(+)
diff --git a/listvms.py b/listvms.py
index a2fb2a5..89ddfb2 100755
--- a/listvms.py
+++ b/listvms.py
@@ -265,6 +265,20 @@ def main():
with connect_to_esxi_host(connection_args) as connection:
data = {}
for vm in list_vms(connection):
+# drop vCLS machines
+vCLS = any(cfg.key == "HDCS.agent"
+ and cfg.value.lower() == "true"
+ for cfg in vm.config.extraConfig)
+if vCLS:
+continue
+# drop vms with empty datastore
+datastore_name, relative_vmx_path = parse_file_path(
+vm.config.files.vmPathName
+)
+if not datastore_name:
+print(f"Skipping VM (no datastore value): {vm.name}",
+ file=sys.stderr)
+continue
try:
fetch_and_update_vm_data(vm, data)
except Exception as err:
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v4 1/3] lxc: show dynamically assigned IPs in network tab
If you want to take this in with this release, I can send a new version, but I'd like to wait a bit to be honest. The Summary looks currently a bit rough, even with the scrollbar. Also we can't differentiate between a dhcp ip-address or an address set manually on the container itself (and we always show dhcp, which is kinda wrong). ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH container v4 3/3] api: return all addresses of an interface
Am 08.01.25 um 15:38 schrieb Gabriel Goller: > Return all ip-addresses of an interface, not only the first one. Change > return schema to resemble the 'agent/network-get-interfaces' qemu call > reponse. This helps us making the AgentIPView more generic and display > the ip on both containers and vms. > Preserve old attributes so that we remain backwards-compatible. These > should be removed in the next version. > > Fixes: #5339 > Cc: Johannes Draaijer > Signed-off-by: Gabriel Goller > --- > src/PVE/API2/LXC.pm | 37 +++-- > src/PVE/LXC.pm | 15 +++ > 2 files changed, 50 insertions(+), 2 deletions(-) > > applied this one for now, with some small follow-ups for code style nits, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH esxi-import-tools v2] listvms: exclude VMs without datastore_name from manifest.json
applied, thanks ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied-series: [PATCH-SERIES manager/qemu-server/docs 0/3] drop writeback cache setting
Am 08.04.25 um 17:07 schrieb Fiona Ebner: > VirtIO-fs using writeback cache seems very broken at the moment. If a > guest accesses a file (even just using 'touch'), that the host is > currently writing, the guest can permanently end up with a truncated > version of that file. Even subsequent operations like moving the file, > will not result in the correct file being visible, but just rename the > truncated one. > > manager: > > Fiona Ebner (1): > ui: virtiofs edit: drop writeback checkbox > > www/manager6/qemu/VirtiofsEdit.js | 5 - > 1 file changed, 5 deletions(-) > > > qemu-server: > > Fiona Ebner (1): > virtiofs: drop writeback option > > PVE/QemuServer/Virtiofs.pm | 8 > 1 file changed, 8 deletions(-) > > > docs: > > Fiona Ebner (1): > qm: virtiofs: drop writeback cache > > qm.adoc | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > Summary over all repositories: > 3 files changed, 2 insertions(+), 15 deletions(-) > applied, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 1/1] frr: enable frr service on reloading the controller config
> On 08.04.2025 21:42 CEST Stoiko Ivanov wrote:
>
>
> On Tue, 8 Apr 2025 20:43:17 +0200
> Thomas Lamprecht wrote:
>
> > On 08/04/2025 18:32, Stefan Hanreich wrote:
> > > Since we now ship frr with Proxmox VE, the frr service is available on
> > > the nodes but disabled on install. Prior to that users had to manually
> > > install frr, which automatically enabled the service. When applying a
> > > SDN configuration with an EVPN controller, we invoke systemctl restart
> > > frr, which leads to the service running but still being in the
> > > disabled state. This means that the EVPN setup is working until the
> > > next reboot. To avoid the situation where users configure an EVPN
> > > controller and everything seems to be working, until a restart breaks
> > > the EVPN setup, additionally enable the frr service before restarting
> > > it.
> > >
> > > Signed-off-by: Stefan Hanreich
> > > ---
> > > src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > > b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > > index c245ea2..4249cc5 100644
> > > --- a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > > +++ b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > > @@ -638,6 +638,7 @@ sub reload_controller {
> > > };
> > > if ($@) {
> > > warn "frr reload command fail. Restarting frr.";
> > > + run_command(['systemctl', 'enable', 'frr']);
> >
> > can we guard this with an file exists check for
> > "/etc/systemd/system/multi-user.target.wants/frr.service"? Not a must, but
> > does
> > not feel right to unconditionally call systemctl enable.
> while talking off-list with Gabriel and Stefan I argued that `systemctl
> is-enabled` probably costs as much as running `systemctl enable` for a
> service (open socket - tell pid 1 to do stuff, wait for result) - so
> now took the time to look into it (with strace, and ignoring what pid 1
> does) - in this case the output of `strace -yyttf systemctl enable frr`
> vs. `strace -yyttf systemctl is-enabled frr` is around 2.5 orders of
> magnitude (58k vs 9.9M) - and even for a service which does not ship an
> init-script anymore (thus causing a few forks for systemd-sysv-install),
> it's 56k vs 3.3M.
>
> in any-case a `-e /etc/systemd/system/multi-user.target.wants/frr.service`
> is probably the most economic version.
> I tried figuring out if this check could break due to external
> cirumstances - if the service is started as part of a target and that
> target is pulled into multi-user.target - the symlink is not present
> (e.g. zfs-zed) - but even then we'd fall back to the "expensive" enabling.
>
> summing up - the existence check seems sensible to me as well.
It certainly wouldn't hurt and your points sound sensible, I'll send
a v2 early tomorrow. Thanks for looking into this further!
> >
> > > eval { run_command(['systemctl', 'restart', 'frr']); };
> > > }
> > > }
> >
> >
> >
> > ___
> > pve-devel mailing list
> > pve-devel@lists.proxmox.com
> > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> >
> >
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH proxmox-firewall 1/1] guest: do not try to create map entries if there are no devices
On Tue, 08 Apr 2025 15:41:35 +0200, Stefan Hanreich wrote: > When the firewall was enabled for a guest, but disabled for all > interfaces of a guest, the firewall tried to add an empty list to the > guest map, which is an invalid nftables statement. > > Applied, thanks! [1/1] guest: do not try to create map entries if there are no devices commit: f16e60bc091892ad1c8576f034642d3f980c1357 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH proxmox-i18n] update Japanese translations
On Tue, 08 Apr 2025 18:59:01 +0900, ribbon via pve-devel wrote: > --- ja.po.old 2025-04-08 17:49:19.253871143 +0900 > +++ ja.po 2025-04-08 18:48:58.615114632 +0900 > @@ -34,9 +34,8 @@ > msgstr "(ブートデバイスが未選択)" > > #: pve-manager/www/manager6/dc/AuthEditOpenId.js:98 > -#, fuzzy > msgid "(none)" > -msgstr "none" > +msgstr "(none)" > > [...] Applied, thanks! [1/1] update Japanese translations commit: 4dd1285bd707afb39290773bac914288a11f1c8b ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH installer v2] auto: add some error context when loading first-boot executable
On Tue, 08 Apr 2025 11:54:43 +0200, Christoph Heiss wrote: > At least to one user in the forum already ran into this IIRC, and most > recently Maximiliano too. > > This can happen when e.g. copying example answer files with the > first-boot section, without then passing `--on-first-boot` to > proxmox-auto-install-assistant. > > [...] Applied, thanks! [1/1] auto: add some error context when loading first-boot executable commit: 9143452ddb3aac2d3901876a1f27f6354fa891ab ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH esxi-import-tools] listvms: exclude VMs without datastore_name from manifest.json.
On Mon, Apr 07, 2025 at 05:04:22PM +0200, Daniel Herzig wrote:
> On newer ESXI-8.x.y versions, the diskless vCLS machines in an
> ESXI-cluster are not stored on a datastore anymore.
>
> Instead, they are placed under `/var/run/crx` on the ESXI-hosts'
> filesystem. This can lead to issues with the ESXI-storage not being
> activated on the PVE-side [0].
>
> This commit changes the default behaviour of `manifest.json` creation by
> excluding any machine that has an empty datastore-string in its config
> and by that prevents querying a file that we cannot reach anyway.
>
> [0]
> https://forum.proxmox.com/threads/new-import-wizard-available-for-migrating-vmware-esxi-based-virtual-machines.144023/post-759288
>
> Signed-off-by: Daniel Herzig
> ---
> This acts silently for now, if we'd prefer logging exclusion
> of these VMs, please drop an idea!
>
> listvms.py | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/listvms.py b/listvms.py
> index a2fb2a5..7a4aa06 100755
> --- a/listvms.py
> +++ b/listvms.py
> @@ -265,6 +265,12 @@ def main():
> with connect_to_esxi_host(connection_args) as connection:
> data = {}
> for vm in list_vms(connection):
> +# skip vms with empty datastore_name
> +datastore_name, relative_vmx_path = parse_file_path(
> +vm.config.files.vmPathName
> +)
> +if not datastore_name:
While this works as a stop-gap, I think we should use the example code
here[1] to test if this is such an embedded(?) vCLS VM, and if it is
*not* such a VM, print a warning to stderr that we're skipping this VM,
so that in the future, if VMs magically disappear, we should see log
messages about this.
[1]
https://knowledge.broadcom.com/external/article/370219/script-identification-for-embedded-vcls.html
> +continue
> try:
> fetch_and_update_vm_data(vm, data)
> except Exception as err:
> --
> 2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-network 1/1] frr: enable frr service on reloading the controller config
Since we now ship frr with Proxmox VE, the frr service is available on
the nodes but disabled on install. Prior to that users had to manually
install frr, which automatically enabled the service. When applying a
SDN configuration with an EVPN controller, we invoke systemctl restart
frr, which leads to the service running but still being in the
disabled state. This means that the EVPN setup is working until the
next reboot. To avoid the situation where users configure an EVPN
controller and everything seems to be working, until a restart breaks
the EVPN setup, additionally enable the frr service before restarting
it.
Signed-off-by: Stefan Hanreich
---
src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
index c245ea2..4249cc5 100644
--- a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
+++ b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
@@ -638,6 +638,7 @@ sub reload_controller {
};
if ($@) {
warn "frr reload command fail. Restarting frr.";
+ run_command(['systemctl', 'enable', 'frr']);
eval { run_command(['systemctl', 'restart', 'frr']); };
}
}
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs 1/1] sdn: frr update documentation for installing frr package
The frr service now gets automatically enabled when applying an SDN
configuration with an EVPN controller present. Reflect this change in
the documentation. Also add a note for users upgrading from prior
versions, that they still need to install frr before applying the SDN
configuration.
Signed-off-by: Stefan Hanreich
---
pvesdn.adoc | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/pvesdn.adoc b/pvesdn.adoc
index 5e58cc3..eef2abf 100644
--- a/pvesdn.adoc
+++ b/pvesdn.adoc
@@ -115,20 +115,17 @@ FRRouting
~
The {pve} SDN stack uses the https://frrouting.org/[FRRouting] project for
-advanced setups. This is currently opt-in.
+advanced setups. Since version 8.4 FRR is automatically included in {pve}
+and gets automatically enabled when applying an SDN configuration with an EVPN
+controller configured.
-To use the SDN routing integration you need to install the `frr-pythontools`
-package on all nodes:
+If you upgraded from an earlier version, you need to install the frr and
+frr-pythontools packages before applying an SDN configuration with an EVPN
+controller:
apt update
-apt install frr-pythontools
-
-
-Then enable the frr service on all nodes:
-
-
-systemctl enable frr.service
+apt install frr frr-pythontools
[[pvesdn_main_configuration]]
@@ -450,8 +447,8 @@ EVPN Controller
The `EVPN`, zone requires an external controller to manage the control plane.
The EVPN controller plugin configures the Free Range Routing (frr) router.
-To enable the EVPN controller, you need to enable FRR on every node, see
-xref:pvesdn_install_frrouting[install FRRouting].
+If you upgraded {pve} from a version earlier than 8.4, you need to install FRR,
+see xref:pvesdn_install_frrouting[install FRRouting].
EVPN controller configuration options:
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH docs/network 0/2] improve behavior of frr service when pre-installed
Fixes the issue of the FRR service getting started, but not enabled when applying an SDN configuration and updates the docs to reflect the new behavior. pve-network: Stefan Hanreich (1): frr: enable frr service on reloading the controller config src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 1 + 1 file changed, 1 insertion(+) pve-docs: Stefan Hanreich (1): sdn: frr update documentation for installing frr package pvesdn.adoc | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) Summary over all repositories: 2 files changed, 10 insertions(+), 12 deletions(-) -- Generated by git-murpp 0.8.0 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-network v2 1/2] frr: remove erroneous outfunc from frr-reload command
Prior to the upgrade to frr-pythontools 10.2.1, frr-reload.py did not
print any output to STDOUT, which masked the erroneous outfunc
provided in run_command. With 10.2.1 frr-reload.py now prints to
STDOUT, which triggers the codepath for invoking the outfunc, leading
to an error when invoking frr-reload.py. By removing the outfunc the
invocation works again.
In addition to fixing the regression introduced, we also now print the
frr-reload.py informational output to the tasklog, which can be
helpful in debugging any issues when reloading the frr configuration.
Signed-off-by: Stefan Hanreich
---
src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
index c245ea2..535c1e6 100644
--- a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
+++ b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
@@ -634,7 +634,7 @@ sub reload_controller {
if (-e $conf_file && -e $bin_path) {
eval {
- run_command([$bin_path, '--stdout', '--reload', $conf_file],
outfunc => {}, errfunc => $err);
+ run_command([$bin_path, '--stdout', '--reload', $conf_file],
errfunc => $err);
};
if ($@) {
warn "frr reload command fail. Restarting frr.";
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH docs/network v2 0/3] improve behavior of frr service when pre-installed
Fixes the issue of the FRR service getting started, but not enabled when applying an SDN configuration and updates the docs to reflect the new behavior. Changes from v1 to v2: * additionally fix the outfunc in the reload command, which caused a regression with frr-pythontools 10.2.1 * move the enabled check before the invocation of frr-reload.py pve-network: Stefan Hanreich (2): frr: remove erroneous outfunc from frr-reload command frr: enable and start frr on reloading the controller config src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) pve-docs: Stefan Hanreich (1): sdn: frr update documentation for installing frr package pvesdn.adoc | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) Summary over all repositories: 2 files changed, 13 insertions(+), 13 deletions(-) -- Generated by git-murpp 0.8.0 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-network v2 2/2] frr: enable and start frr on reloading the controller config
Since we now ship frr with Proxmox VE, the frr service is available on
the nodes but disabled on install. Prior to that, users had to
manually install frr, which automatically enabled the service. When
first applying a SDN configuration with an EVPN controller, we always
fell back to restarting the frr service, because reloading fails when
the daemon isn't running. This fallback to restarting leads to the
service running but still being in the disabled state. This means that
the EVPN setup is working until the next reboot. To avoid the
situation where users configure an EVPN controller and everything
seems to be working, until a restart breaks the EVPN setup,
additionally enable and start the frr service before trying to reload
the configuration.
We enable the service after checking for the existence of
frr-pythontools in order to avoid the situation where users apply an
SDN configuration with an EVPN controller, but reloading fails due to
a missing frr-pythontools package. Since we do an early return there,
we never fell back to restarting the service in case frr-pythontools
was not available. If we enabled the service before the check, the
configuration would apply after a reboot since it already got written
to the frr configuration file.
Signed-off-by: Stefan Hanreich
---
src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
index 535c1e6..5b1a9aa 100644
--- a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
+++ b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
@@ -625,6 +625,9 @@ sub reload_controller {
return;
}
+run_command(['systemctl', 'enable', '--now', 'frr'])
+ if !-e "/etc/systemd/system/multi-user.target.wants/frr.service";
+
my $err = sub {
my $line = shift;
if ($line =~ /ERROR:/) {
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs v2 1/1] sdn: frr update documentation for installing frr package
The frr service now gets automatically enabled when applying an SDN
configuration with an EVPN controller present. Reflect this change in
the documentation. Also add a note for users upgrading from prior
versions, that they still need to install frr before applying the SDN
configuration.
Signed-off-by: Stefan Hanreich
---
pvesdn.adoc | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/pvesdn.adoc b/pvesdn.adoc
index 5e58cc3..eef2abf 100644
--- a/pvesdn.adoc
+++ b/pvesdn.adoc
@@ -115,20 +115,17 @@ FRRouting
~
The {pve} SDN stack uses the https://frrouting.org/[FRRouting] project for
-advanced setups. This is currently opt-in.
+advanced setups. Since version 8.4 FRR is automatically included in {pve}
+and gets automatically enabled when applying an SDN configuration with an EVPN
+controller configured.
-To use the SDN routing integration you need to install the `frr-pythontools`
-package on all nodes:
+If you upgraded from an earlier version, you need to install the frr and
+frr-pythontools packages before applying an SDN configuration with an EVPN
+controller:
apt update
-apt install frr-pythontools
-
-
-Then enable the frr service on all nodes:
-
-
-systemctl enable frr.service
+apt install frr frr-pythontools
[[pvesdn_main_configuration]]
@@ -450,8 +447,8 @@ EVPN Controller
The `EVPN`, zone requires an external controller to manage the control plane.
The EVPN controller plugin configures the Free Range Routing (frr) router.
-To enable the EVPN controller, you need to enable FRR on every node, see
-xref:pvesdn_install_frrouting[install FRRouting].
+If you upgraded {pve} from a version earlier than 8.4, you need to install FRR,
+see xref:pvesdn_install_frrouting[install FRRouting].
EVPN controller configuration options:
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH docs] virtiofs: add a description of how to install virtiofsd
Signed-off-by: Markus Frank
---
qm.adoc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/qm.adoc b/qm.adoc
index 39cf492..44e2436 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -1269,6 +1269,12 @@ Linux VMs with kernel >=5.4 support virtiofs by default
(https://www.kernelconfig.io/CONFIG_VIRTIO_FS[virtiofs kernel module]), but
some
features require a newer kernel.
+To use virtiofs, ensure that virtiofsd is installed on the {pve} host:
+
+
+apt install virtiofsd
+
+
There is a
https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Virtiofs:-Shared-file-system[guide]
available on how to utilize virtiofs in Windows VMs.
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH installer] btrfs: write /etc/kernel/cmdline unconditionally
On Tue, 08 Apr 2025 21:18:06 +0200, Stoiko Ivanov wrote: > the recent change of handing the ESPs to proxmox-boot-tool broke > installation on btrfs booted with systemd-boot (currently efi-systems > without secureboot). our systemd-boot config-generation takes the > kernel commandline from /etc/kernel/cmdline - without this there is no > root= parameter, and we end up in a initramfs shell. > > write the file unconditionally of boot-mode (legacy, efi, > efi-secureboot), to be consistent with the way we do it on ZFS. > > [...] Applied, thanks! [1/1] btrfs: write /etc/kernel/cmdline unconditionally commit: 268783c3e8f07dd6a30a8fdc18038a5f2681503d ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager v6 3/4] fix #1926 ui: vm console: autodetect novnc or xtermjs
Some users configure their VMs to use serial as their display. The big
benefit is that in combination with the xtermjs remote console, copy &
paste works a lot better than via novnc.
While the console button in the top right allows to manually choose the
console type, the Console in the main submenu of a VM does not.
This patch changes the behavior to not load the console right away if
set to 'kvm'. Instead, the callback from the VM's status/current call
will run the final steps to load the console. Because then we know if it
should be noVNC or xtermjs.
That means that in the VNCConsole component we need to keep track if the
console has been fully set up and is running. The actual code that loads
the console into the iframe is moved into a function, so we cann call it
from the API callback.
One result is that the behavior changes. Loading the console on a VM
will take a little bit longer:
* When then Console is the selected and one switches between VMs, a new
status/current call is made and on a good connection, the console
should load just a few moments later.
* When one switches to the console from another submenu of the VM, the
console will load once the next API call to status/current finished.
Signed-off-by: Aaron Lauterer
Reviewed-by: Dominik Csapak
---
changes since:
v5:
* introduce PVE.Utils.isSerialDisplay helper
* avoid 'rec' assignment in callback when setting the 'xtermjs' variable
v4:
* use new status/current display property
v3:
* fixed spacing issues
* add 'current' parameter when fetching config as the pending might have
a different display set
v2:
* change approach and do it in the UI alone by fetching the VM
config before deciding which console to use
v1:
* set 'autodetect' to always true in 'VNCConsole.js'
* add additional checks in pveproxy
* only if autodetect is enabled and console is set to 'kvm'
* username exists and has VM.Console permissions for the guest
www/manager6/Utils.js | 4 +++
www/manager6/VNCConsole.js | 52 +
www/manager6/qemu/Config.js | 7 -
3 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js
index a1bcbe7e..d6fd6a9e 100644
--- a/www/manager6/Utils.js
+++ b/www/manager6/Utils.js
@@ -1986,6 +1986,10 @@ Ext.define('PVE.Utils', {
);
return Ext.htmlEncode(description);
},
+
+isSerialDisplay: function(display) {
+ return display?.startsWith('serial') ?? false;
+},
},
singleton: true,
diff --git a/www/manager6/VNCConsole.js b/www/manager6/VNCConsole.js
index 9057e447..3371c923 100644
--- a/www/manager6/VNCConsole.js
+++ b/www/manager6/VNCConsole.js
@@ -12,6 +12,36 @@ Ext.define('PVE.noVncConsole', {
layout: 'fit',
border: false,
+setupDone: false, // initial setup is done and the session is running
+
+loadConsole: function(xtermjs, consoleType) {
+ let me = this;
+ if (me.setupDone) {
+ return;
+ }
+
+ let type = xtermjs ? 'xtermjs' : 'novnc';
+ let sp = Ext.state.Manager.getProvider();
+ if (Ext.isFunction(me.beforeLoad)) {
+ me.beforeLoad();
+ }
+ let queryDict = {
+ console: consoleType, // kvm, lxc, upgrade or shell
+ vmid: me.vmid,
+ node: me.nodename,
+ cmd: me.cmd,
+ 'cmd-opts': me.cmdOpts,
+ resize: sp.get('novnc-scaling', 'scale'),
+ };
+ let box = this.down('[itemid=vncconsole]');
+ queryDict[type] = 1;
+ PVE.Utils.cleanEmptyObjectKeys(queryDict);
+ let url = '/?' + Ext.Object.toQueryString(queryDict);
+ Proxmox.Utils.setErrorMask(me);
+ box.load(url);
+ me.setupDone = true;
+},
+
initComponent: function() {
var me = this;
@@ -29,37 +59,25 @@ Ext.define('PVE.noVncConsole', {
// always use same iframe, to avoid running several noVnc clients
// at same time (to avoid performance problems)
- var box = Ext.create('Ext.ux.IFrame', { itemid: "vncconsole" });
+ let box = Ext.create('Ext.ux.IFrame', { itemid: "vncconsole" });
- var type = me.xtermjs ? 'xtermjs' : 'novnc';
Ext.apply(me, {
items: box,
listeners: {
activate: function() {
- let sp = Ext.state.Manager.getProvider();
- if (Ext.isFunction(me.beforeLoad)) {
- me.beforeLoad();
+ if (me.consoleType !== 'kvm') {
+ me.loadConsole(me.xtermjs, me.consoleType);
}
- let queryDict = {
- console: me.consoleType, // kvm, lxc, upgrade or shell
- vmid: me.vmid,
- node: me.nodename,
- cmd: me.cmd,
- 'cmd-opts': me.cmdOpts,
- resize: sp.get('novnc-scaling', 'scale'),
- };
-
[pve-devel] [PATCH qemu-server, manager v6 0/4] fix #1926 autodetect xtermjs or novnc for VM console
We add a new property in the VM status/current API result that includes the display configurtion of the VM. This way we can check in the frontend what to do with it. I chose a nested return value, as that makes it easier to add/move additional display properties into it. Patch 1/4 makes two functions in QemuServer.pm public. Patch 2/4 adds the new display property. If not explicitly set in the VM config, it will return the default 'std' value. Patch 3/4 implements the changes in the UI. The final result isn't really a lot simpler on the UI side than in V4 where we had the extra API call to the VM's config directly. Because we still need to wait for the API call to finish when initially navigating to the VM. But we have one fewer call. Patch 4/4 then introduces some changes to make loading of the console faster if we just navigate in the submenu of a VM itself where we already have the current status of a VM already cached. Changes from v5: implement suggestions: * use get_vga_properties for default VGA * UI: use helper to determine if serial display qemu-server: Aaron Lauterer (2): QemuServer: make get_vga_properties and extract_version public api: status/current: add display property PVE/API2/Qemu.pm | 21 + PVE/QemuServer.pm | 4 ++-- 2 files changed, 23 insertions(+), 2 deletions(-) manager: Aaron Lauterer (2): fix #1926 ui: vm console: autodetect novnc or xtermjs ui: console: check on activate if display info for VMs is present www/manager6/Utils.js | 4 +++ www/manager6/VNCConsole.js | 60 ++--- www/manager6/qemu/Config.js | 7 - 3 files changed, 53 insertions(+), 18 deletions(-) -- 2.39.5 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs/network 0/2] improve behavior of frr service when pre-installed
We should also consider adding frr-pythontools to the ISO, since otherwise applying doesn't work ootb. On 4/8/25 18:32, Stefan Hanreich wrote: > Fixes the issue of the FRR service getting started, but not enabled when > applying an SDN configuration and updates the docs to reflect the new > behavior. > > pve-network: > > Stefan Hanreich (1): > frr: enable frr service on reloading the controller config > > src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 1 + > 1 file changed, 1 insertion(+) > > > pve-docs: > > Stefan Hanreich (1): > sdn: frr update documentation for installing frr package > > pvesdn.adoc | 21 + > 1 file changed, 9 insertions(+), 12 deletions(-) > > > Summary over all repositories: > 2 files changed, 10 insertions(+), 12 deletions(-) > ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs/network 0/2] improve behavior of frr service when pre-installed
On 08/04/2025 18:32, Stefan Hanreich wrote: > Fixes the issue of the FRR service getting started, but not enabled when > applying an SDN configuration and updates the docs to reflect the new > behavior. - started with fresh ISO with sha256sum: 695c1c9b247e62d851d29d39c3e9399d3a15dd7c1bdca68b357b6bd578ee9925 - set up evpn controller and zone, clicked apply => frr.service is disabled but running - reboot => frr.service is not running - applied this patch, clicked apply => frr.service is now enabled and running - reboot => frr.service is running So this looks good to me. I was wondering whether enabling frr may have any side effects on existing setups, but since we only enable if we restart anyway, I don't think this should cause any issues. Consider this Tested-by: Friedrich Weber ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v7 3/3] ui: import storage content: allow importing of vm disk images
Am 08.04.25 um 14:13 schrieb Dominik Csapak: > By enabling the import button for qcow2/vmdk/raw files, and showing a > window with a VMID selector and the disk edit panel. > functionality wise I'd have applied that as it would be new and have thus almost no regression potential, might be also better to factor out the panel upfront in a dedicated commit and then integrate it everywhere. But lets wait this out, no point in rushing things here. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v7 0/3] allow importing vm disk images on the UI
On 4/8/25 14:13, Dominik Csapak wrote: this is a continuation of my previous series [0] It enables importing disks on the UI in the HardwareView of a vm, in the create wizard, and in the storage content view. I split the patches so that the wizard and storage content view one are separate, so they can be reviewed independently. changes from v6: * drop applied patches * make import in hd edit panel dependant on configuration, instead of showing a checkbox * wizard and HardwareView got an explicit import button * make the import button work on the storage content view for disk images * split patches for hdedit, wizard and storage content 0: https://lore.proxmox.com/pve-devel/20250407101310.3196974-1-d.csa...@proxmox.com/ Hi, tested this by creating disk images from existing VMs and importing them in the following ways: - during creation of a VM in the CreateWizard - through the Hardware view of an existing VM, then changing the boot order to boot from the imported disk - from the storage content view; uploaded a disk image and imported into an existing VM from there - imported with IDE, SATA, SCSI, and VirtIO controllers - imported qcow2, vmdk, and raw disk images The tested cases worked as I would expect and I was able to create and start VMs with the given images. Creating multiple new VMs with imported disks in parallel did slow down the creation considerably, but otherwise worked without problems for me. I also tried adding, removing, changing disks in the CreateWizard to see if I could get around the constraints set for the new selectors. The UI part was overall intuitive to use. I pondered a bit on the icon chosen for the import, but would could not really find a more fitting one. Maybe someone else has a stronger opinion on this? So please consider this: Reviewed-by: Michael Köppl Tested-by: Michael Köppl ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH proxmox-i18n] update Spanish translations
Signed-off-by: Maximiliano Sandoval
---
es.po | 190 +++---
1 file changed, 88 insertions(+), 102 deletions(-)
diff --git a/es.po b/es.po
index 1f2556a..a6d7288 100644
--- a/es.po
+++ b/es.po
@@ -8,7 +8,7 @@ msgstr ""
"Project-Id-Version: proxmox translations\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: Mon Apr 7 15:25:31 2025\n"
-"PO-Revision-Date: 2025-02-26 11:33+0100\n"
+"PO-Revision-Date: 2025-04-08 09:57+0200\n"
"Last-Translator: Maximiliano Sandoval \n"
"Language-Team: Spanish\n"
"Language: es\n"
@@ -16,13 +16,13 @@ msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
-"X-Generator: Gtranslator 47.1\n"
+"X-Generator: Gtranslator 48.0\n"
"X-Poedit-SourceCharset: UTF-8\n"
#: proxmox-backup/www/tape/window/TapeBackup.js:127
#: proxmox-backup/www/tape/window/TapeBackupJob.js:224
msgid "# of Worker Threads"
-msgstr ""
+msgstr "Número de hilos de trabajo"
#: pmg-gui/js/SystemOptions.js:85
msgid "'From:' for Admin Mail"
@@ -30,12 +30,11 @@ msgstr "'From:' para el email del administrador"
#: pve-manager/www/manager6/qemu/Options.js:95
msgid "(No boot device selected)"
-msgstr "(Nse ha seleccionado dispositivo de arranque)"
+msgstr "(No se ha seleccionado dispositivo de arranque)"
#: pve-manager/www/manager6/dc/AuthEditOpenId.js:98
-#, fuzzy
msgid "(none)"
-msgstr "ninguno"
+msgstr "(ninguno)"
#: proxmox-backup/www/config/SyncView.js:242
msgid "(remote) store, remote, id, owner, direction"
@@ -56,11 +55,11 @@ msgstr "/alguna/ruta"
#: proxmox-backup/www/datastore/OptionView.js:303
msgid "1048576 (0 disables chache)"
-msgstr ""
+msgstr "1048576 (0 desactiva el caché)"
#: proxmox-backup/www/datastore/OptionView.js:295
msgid "1445 (24 hours 5 minutes)"
-msgstr ""
+msgstr "1445 (24 horas y 5 minutos)"
#: pmg-gui/js/PBSConfig.js:39
msgid "5 Minutes"
@@ -247,11 +246,11 @@ msgstr "Acción"
#: pmg-gui/js/controller/QuarantineController.js:97
msgid "Action '{0}' for '{1}' items"
-msgstr "Acción '{0}' para '{1}' elementos"
+msgstr "Acción '{0}' para '{1}' ítems"
#: pmg-gui/js/Utils.js:794 pmg-gui/js/Utils.js:921
msgid "Action '{0}' for '{1}' items successful"
-msgstr "Acción '{0}' para '{1}' elementos exitosa"
+msgstr "Acción '{0}' para '{1}' ítems exitosa"
#: pmg-gui/js/Utils.js:795 pmg-gui/js/Utils.js:922
msgid "Action '{0}' successful"
@@ -638,9 +637,8 @@ msgid "Allow Key-Sharing"
msgstr "Permitir compartir llaves"
#: pve-manager/www/manager6/qemu/SevEdit.js:109
-#, fuzzy
msgid "Allow SMT"
-msgstr "Permitir HREFs"
+msgstr "Permitir SMT"
#: pve-manager/www/manager6/window/BulkAction.js:87
msgid "Allow local disk migration"
@@ -929,9 +927,8 @@ msgid "Auto-generate a client encryption key"
msgstr "Auto-generar una llave de cifrado para el cliente"
#: pve-manager/www/manager6/dc/AuthEditOpenId.js:87
-#, fuzzy
msgid "Autocreate Groups"
-msgstr "Auto-creación de usuarios"
+msgstr "Auto-creación de grupos"
#: proxmox-widget-toolkit/src/window/AuthEditOpenId.js:74
#: pve-manager/www/manager6/dc/AuthEditOpenId.js:58
@@ -1503,15 +1500,15 @@ msgstr "Imposible obtener información del Guest
AgentError: {0}"
#: pve-manager/www/manager6/window/Migrate.js:316
msgid "Cannot migrate VM with local CD/DVD"
-msgstr ""
+msgstr "No se puede migrar la VM con CD/DVD local"
#: pve-manager/www/manager6/window/Migrate.js:266
msgid "Cannot migrate VM with local resources: {0}"
-msgstr ""
+msgstr "No se puede migrar la VM con recursos locales: {0}"
#: pve-manager/www/manager6/window/Migrate.js:294
msgid "Cannot migrate running VM with mapped resources: {0}"
-msgstr ""
+msgstr "No se puede migrar la VM con recursos mapeados: {0}"
#: pve-manager/www/manager6/storage/ImageView.js:52
msgid "Cannot remove disk image."
@@ -1579,14 +1576,12 @@ msgid "Ceph in the cluster"
msgstr "Ceph en el cluster"
#: pve-manager/www/manager6/window/CephInstall.js:38
-#, fuzzy
msgid "Ceph is not initialized."
-msgstr "{0} no ha sido inicializado"
+msgstr "Ceph no ha sido inicializado."
#: pve-manager/www/manager6/window/CephInstall.js:42
-#, fuzzy
msgid "Ceph is not installed on this node."
-msgstr "{0} no ha sido instalado en este nodo."
+msgstr "Ceph no ha sido instalado en este nodo."
#: pve-manager/www/manager6/ceph/CephInstallWizard.js:27
msgid "Ceph version to install"
@@ -1627,7 +1622,7 @@ msgstr "Tipo de desafío"
#: proxmox-backup/www/window/BackupGroupChangeOwner.js:7
#: proxmox-backup/www/window/BackupGroupChangeOwner.js:26
msgid "Change Owner"
-msgstr "Cambiar dueño"
+msgstr "Cambiar propietario"
#: proxmox-backup/www/config/UserView.js:175
msgid "Change Password"
@@ -1645,11 +1640,11 @@ msgstr "Cambiar las opciones globales de Ceph"
#: proxmox-backup/www/datastore/Content.js:1322
msgid "Change owner"
-msgstr "Cambiar dueño"
+msgstr "Cambiar propietario"
#: proxmox-backup/www/datastore/Content.js:1004
[pve-devel] [PATCH proxmox-i18n] Update italian translation
Typos and errors introduced by previous commit.
Fixes: 99c75561ae98 ("update Italian translations")
Signed-off-by: Gabriel Goller
---
it.po | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/it.po b/it.po
index e3128c5ba04b..95997e333272 100644
--- a/it.po
+++ b/it.po
@@ -392,7 +392,7 @@ msgstr "Aggiungi Remote"
#: proxmox-widget-toolkit/src/panel/WebhookEditPanel.js:95
msgid "Add Secret"
-msgstr "Aggiungii Segreto"
+msgstr "Aggiungi Segreto"
#: pmg-gui/js/Utils.js:720
msgid "Add Separator"
@@ -1567,7 +1567,7 @@ msgstr "Ceph non è inizializzato."
#: pve-manager/www/manager6/window/CephInstall.js:42
msgid "Ceph is not installed on this node."
-msgstr "Ceph non è stato installato in questo nodo."
+msgstr "Ceph non è stato installato su questo nodo."
#: pve-manager/www/manager6/ceph/CephInstallWizard.js:27
msgid "Ceph version to install"
@@ -12783,7 +12783,7 @@ msgstr "Job di Verifica"
#: proxmox-backup/www/window/SyncJobEdit.js:419
msgid "Verified Only"
-msgstr "Soltanto Verificati"
+msgstr "Solo Verificati"
#: proxmox-backup/www/dashboard/TaskSummary.js:33
#: proxmox-backup/www/datastore/Content.js:1314
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server, manager v6 0/4] fix #1926 autodetect xtermjs or novnc for VM console
sent a v7 https://lore.proxmox.com/pve-devel/20250408122710.1164112-2-a.laute...@proxmox.com/T/#m54aae8f7595a1478748c2b61180c46d0cf52e38b On 2025-04-08 12:37, Aaron Lauterer wrote: We add a new property in the VM status/current API result that includes the display configurtion of the VM. This way we can check in the frontend what to do with it. I chose a nested return value, as that makes it easier to add/move additional display properties into it. Patch 1/4 makes two functions in QemuServer.pm public. Patch 2/4 adds the new display property. If not explicitly set in the VM config, it will return the default 'std' value. Patch 3/4 implements the changes in the UI. The final result isn't really a lot simpler on the UI side than in V4 where we had the extra API call to the VM's config directly. Because we still need to wait for the API call to finish when initially navigating to the VM. But we have one fewer call. Patch 4/4 then introduces some changes to make loading of the console faster if we just navigate in the submenu of a VM itself where we already have the current status of a VM already cached. Changes from v5: implement suggestions: * use get_vga_properties for default VGA * UI: use helper to determine if serial display qemu-server: Aaron Lauterer (2): QemuServer: make get_vga_properties and extract_version public api: status/current: add display property PVE/API2/Qemu.pm | 21 + PVE/QemuServer.pm | 4 ++-- 2 files changed, 23 insertions(+), 2 deletions(-) manager: Aaron Lauterer (2): fix #1926 ui: vm console: autodetect novnc or xtermjs ui: console: check on activate if display info for VMs is present www/manager6/Utils.js | 4 +++ www/manager6/VNCConsole.js | 60 ++--- www/manager6/qemu/Config.js | 7 - 3 files changed, 53 insertions(+), 18 deletions(-) ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server, manager v7 0/4] fix #1926 autodetect xtermjs or novnc for VM console
Created a VM, started it and opened the console -> noVNC was selected added a serial device and selected Serial output as Display -> xtermjs was selected selected SPICE as Display -> noVNC was selected the patches behaved as i would have expected, please consider them Tested-by: Hannes Duerr On 4/8/25 14:27, Aaron Lauterer wrote: Sorry for the noise, after the feedback from Fiona on v6 and some off-list discussion, we decided to improve the backend part by moving the "default" logic out of `get_vga_properties` and move it into a separate public `get_default_vga_type` function. This way we can leave all the other functions private to the QemuServer.pm module. We add a new property in the VM status/current API result that includes the display configurtion of the VM. This way we can check in the frontend what to do with it. I chose a nested return value, as that makes it easier to add/move additional display properties into it. Patch 1/4 moves the default display logic into its own public function Patch 2/4 adds the new display property. If not explicitly set in the VM config, it will return the default value. Patch 3/4 implements the changes in the UI. The final result isn't really a lot simpler on the UI side than in V4 where we had the extra API call to the VM's config directly. Because we still need to wait for the API call to finish when initially navigating to the VM. But we have one fewer call. Patch 4/4 then introduces some changes to make loading of the console faster if we just navigate in the submenu of a VM itself where we already have the current status of a VM already cached. Changes from v6: backend only: create new `get_default_vga_type` function. v5: implement suggestions: * use get_vga_properties for default VGA * UI: use helper to determine if serial display qemu-server: Aaron Lauterer (2): QemuServer: add new public get_default_vga_type function api: status/current: add display property PVE/API2/Qemu.pm | 13 + PVE/QemuServer.pm | 29 ++--- 2 files changed, 35 insertions(+), 7 deletions(-) manager: Aaron Lauterer (2): fix #1926 ui: vm console: autodetect novnc or xtermjs ui: console: check on activate if display info for VMs is present www/manager6/Utils.js | 4 +++ www/manager6/VNCConsole.js | 60 ++--- www/manager6/qemu/Config.js | 7 - 3 files changed, 53 insertions(+), 18 deletions(-) ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH-SERIES http-server 0/3] fix disconnecting clients
Commit 07e56cc ("fix unexpected EOF for client when closing TLS
session") added a call to stoptls() before the call to shutdown() for
the handle's file descriptor. However, the documentation for
AnyEvent[0] mentions for stoptls():
> This method may invoke callbacks (and therefore the handle might be
> destroyed after it returns).
Indeed, the on_error callback might get invoked and lead to a
"detected empty handle" error message as reported in the community
forum [1].
Also, it is necessary to check that the handle is still defined
before calling shutdown(). Otherwise, this can result in a warning:
> Can't use an undefined value as a symbol reference at
> /usr/share/perl5/PVE/APIServer/AnyEvent.pm line 150.
as reported in the community forum [1] too.
Patches 1/3 and 2/3 are fixes for the reported issues. Patch 3/3 is
further future-proofing.
[0]: https://metacpan.org/pod/AnyEvent::Handle#$handle-%3Estoptls
[1]: https://forum.proxmox.com/threads/164744/
Fiona Ebner (3):
anyevent: disconnect: check that handle is still defined before
calling shutdown()
anyevent: always avoid re-entering client_do_disconnect() in on_error
callback
anyevent: handle 'disconnected' flag in client_do_disconnect() itself
src/PVE/APIServer/AnyEvent.pm | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH http-server 2/3] anyevent: always avoid re-entering client_do_disconnect() in on_error callback
Commit f737984 ("fix #4816: do not disconnect twice if client sends no
data") introduced a 'disconnected' flag in the request state to avoid
duplicate calls to client_do_disconnect() for a given client. This
works, except in the case where client_do_disconnect() enters the
on_error callback itself. To fix this, set the 'disconnected' flag
before calling client_do_disconnect().
This was exposed by commit 07e56cc ("fix unexpected EOF for client
when closing TLS session") which introduced a call to stoptls() in
client_do_disconnect(). The documentation [0] mentions for stoptls():
> This method may invoke callbacks (and therefore the handle might be
> destroyed after it returns).
Indeed, the on_error callback might get invoked and lead to a
"detected empty handle" error message as reported in the community
forum [1].
[0]: https://metacpan.org/pod/AnyEvent::Handle#$handle-%3Estoptls
[1]: https://forum.proxmox.com/threads/164744/
Fixes: 07e56cc ("fix unexpected EOF for client when closing TLS session")
Signed-off-by: Fiona Ebner
---
src/PVE/APIServer/AnyEvent.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/PVE/APIServer/AnyEvent.pm b/src/PVE/APIServer/AnyEvent.pm
index 3f8642b..db14a7d 100644
--- a/src/PVE/APIServer/AnyEvent.pm
+++ b/src/PVE/APIServer/AnyEvent.pm
@@ -1915,8 +1915,8 @@ sub accept_connections {
# connection/handle if the timeout is reached before
# any data has been received, avoid misleading errors
if (!$reqstate->{disconnected}) {
- $self->client_do_disconnect($reqstate);
$reqstate->{disconnected} = 1;
+ $self->client_do_disconnect($reqstate);
}
};
if (my $err = $@) { syslog('err', "$err"); }
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH docs] virtual machines: document importing disks from import storage
Explain which formats can be imported and what the requirements for the storage are (content type). Give an example on how to import into an existing and new guest. Also note that images are copied, not moved and that they can't reference external files. Signed-off-by: Dominik Csapak --- qm.adoc | 33 + 1 file changed, 33 insertions(+) diff --git a/qm.adoc b/qm.adoc index 539912a..1d42891 100644 --- a/qm.adoc +++ b/qm.adoc @@ -1961,6 +1961,39 @@ and attaching it to the VM's SCSI controller: The VM is ready to be started. +[[qm_import_disk_images]] +Import Disk Images +~~ + +Disk images in the formats `qcow2`, `vmdk` and `raw` can be imported directly +from a storage marked with the `import` content type. You can upload these +files in the UI, or put it in the correct folder yourself (usually +`/path/to/your/storage/import/`). + +To import the disk into an existing guest you can use the `import-from` option +of the disk API. + +Here is an example to import the image `disk.qcow2` from the storage `source` +into the guest with VMID 100 to the storage `local`. + + +# qm set 100 --scsi0 local:0,import-from=source:import/disk.qcow2 + + +The same syntax is available for vm creation: + + +# qm create 100 --scsi0 local:0,import-from=source:import/disk.qcow2 + + +These options are also available over the API. + +Images imported this way are copied to the target storage and converted into +the correct format. The original image will not be modified or deleted. + +NOTE: Disk importing has a few security restrictions. For example, they can not +reference external images. + ifndef::wiki[] include::qm-cloud-init.adoc[] -- 2.39.5 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH i18n] update German translations
Signed-off-by: Shannon Sterz --- de.po | 226 +- 1 file changed, 98 insertions(+), 128 deletions(-) diff --git a/de.po b/de.po index 1c1965d..c291c2f 100644 --- a/de.po +++ b/de.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: proxmox translations\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: Tue Apr 8 12:23:34 2025\n" -"PO-Revision-Date: 2024-11-28 10:10+0100\n" +"PO-Revision-Date: 2025-04-08 16:07+0200\n" "Last-Translator: Proxmox Support Team \n" "Language-Team: German\n" "Language: de\n" @@ -21,20 +21,19 @@ msgstr "" #: proxmox-backup/www/tape/window/TapeBackup.js:127 #: proxmox-backup/www/tape/window/TapeBackupJob.js:224 msgid "# of Worker Threads" -msgstr "" +msgstr "# von Worker Threads" #: pmg-gui/js/SystemOptions.js:85 msgid "'From:' for Admin Mail" -msgstr "" +msgstr "'From': Absender für Admin Mails" #: pve-manager/www/manager6/qemu/Options.js:95 msgid "(No boot device selected)" msgstr "(Kein Startgerät ausgewählt)" #: pve-manager/www/manager6/dc/AuthEditOpenId.js:98 -#, fuzzy msgid "(none)" -msgstr "keine" +msgstr "(keiner)" #: proxmox-backup/www/config/SyncView.js:242 msgid "(remote) store, remote, id, owner, direction" @@ -56,11 +55,11 @@ msgstr "/ein/pfad" #: proxmox-backup/www/datastore/OptionView.js:303 msgid "1048576 (0 disables cache)" -msgstr "" +msgstr "1048576 (0 deaktiviert den Cache)" #: proxmox-backup/www/datastore/OptionView.js:295 msgid "1445 (24 hours 5 minutes)" -msgstr "" +msgstr "1445 (24 Stunden 5 Minuten)" #: pmg-gui/js/PBSConfig.js:39 msgid "5 Minutes" @@ -91,8 +90,8 @@ msgid "" "A selected device is not in a separate IOMMU group, make sure this is " "intended." msgstr "" -"Ein ausgewähltes Gerät befindet sich in keiner eigenen IOMMU-Gruppe, ist das " -"so gewollt?" +"Ein ausgewähltes Gerät befindet sich in keiner eigenen IOMMU-Gruppe, stellen " +"Sie sicher, dass das so gewollt ist." #: proxmox-widget-toolkit/src/window/AuthEditLDAP.js:414 #: proxmox-widget-toolkit/src/window/SyncWindow.js:110 @@ -368,18 +367,16 @@ msgid "Add Datastore" msgstr "Datastore hinzufügen" #: pve-manager/www/manager6/window/DirMapEdit.js:26 -#, fuzzy msgid "Add Directory Mapping" -msgstr "Verzeichnis-Storage" +msgstr "Verzeichnis Mapping hinzufügen" #: pve-manager/www/manager6/qemu/SystemEdit.js:117 msgid "Add EFI Disk" msgstr "EFI-Disk hinzufügen" #: proxmox-widget-toolkit/src/panel/WebhookEditPanel.js:73 -#, fuzzy msgid "Add Header" -msgstr "Header" +msgstr "Header hinzufügen" #: proxmox-backup/www/datastore/Content.js:1260 msgid "Add Namespace" @@ -398,9 +395,8 @@ msgid "Add Remote" msgstr "Remote hinzufügen" #: proxmox-widget-toolkit/src/panel/WebhookEditPanel.js:95 -#, fuzzy msgid "Add Secret" -msgstr "Secret" +msgstr "Geheimnis hinzufügen" #: pmg-gui/js/Utils.js:720 msgid "Add Separator" @@ -415,7 +411,7 @@ msgstr "Storage hinzufügen" #: pmg-gui/js/MailProxyTLS.js:14 msgid "Add TLS received header" -msgstr "TLS 'received header' hinzufügen." +msgstr "TLS 'received header' hinzufügen" #: pve-manager/www/manager6/qemu/SystemEdit.js:166 msgid "Add TPM" @@ -612,7 +608,7 @@ msgstr "Alle fehlgeschlagen" #: pmg-gui/js/form/MatchModeSelector.js:6 msgid "All match" -msgstr "alle zutreffen" +msgstr "Alle stimmen überein" #: proxmox-widget-toolkit/src/window/NotificationMatcherEdit.js:497 #: proxmox-widget-toolkit/src/window/NotificationMatcherEdit.js:886 @@ -635,7 +631,7 @@ msgstr "Debuggen erlauben" #: pve-manager/www/manager6/qemu/VirtiofsEdit.js:87 msgid "Allow Direct IO" -msgstr "" +msgstr "Direkt IO erlauben" #: pmg-gui/js/SpamQuarantineOptions.js:68 #: pmg-gui/js/VirusQuarantineOptions.js:20 @@ -647,9 +643,8 @@ msgid "Allow Key-Sharing" msgstr "Teilen von Schlüsseln erlauben" #: pve-manager/www/manager6/qemu/SevEdit.js:109 -#, fuzzy msgid "Allow SMT" -msgstr "Erlaube HREFs" +msgstr "SMT erlauben" #: pve-manager/www/manager6/window/BulkAction.js:87 msgid "Allow local disk migration" @@ -690,7 +685,7 @@ msgstr "Anonyme Suche" #: pmg-gui/js/form/MatchModeSelector.js:7 msgid "Any matches" -msgstr "beliebige Übereinstimmungen" +msgstr "Beliebige Übereinstimmungen" #: proxmox-widget-toolkit/src/window/NotificationMatcherEdit.js:503 #: proxmox-widget-toolkit/src/window/NotificationMatcherEdit.js:887 @@ -698,9 +693,8 @@ msgid "Any rule matches" msgstr "mindestens eine Regel zutrifft" #: pve-manager/www/manager6/ceph/Pool.js:314 -#, fuzzy msgid "Application" -msgstr "Replizierung" +msgstr "Applikation" #: pve-manager/www/manager6/dc/OptionView.js:468 msgid "Applies to new edits" @@ -939,9 +933,8 @@ msgid "Auto-generate a client encryption key" msgstr "Client-Schlüssel automatisch generieren" #: pve-manager/www/manager6/dc/AuthEditOpenId.js:87 -#, fuzzy msgid "Autocreate Groups" -msgstr "Benutzer auto-erstellen" +msgstr "Gruppen auto-erstellen" #: proxmox-widget-toolkit/src/window/AuthEditOpenId.js:74 #: pve-m
[pve-devel] applied: [PATCH manager] ui: qemu: hardware view: fix hwrng cap check for unprivileged users
On Tue, 08 Apr 2025 18:38:56 +0200, Friedrich Weber wrote: > Currently, as an unprivileged user with role PVEVMUser the GUI breaks > with an error after navigating to a VM's hardware tab. The reason is > that the frontend checks the GUI capabilites via `caps.mapping.hwrng`, > but `caps.mapping` does not actually have a property called `hwrng`. > > The reason this does not trigger for more privileged users is that all > expressions involving `caps.mapping.hwrng` are short-circuited if the > user has privilege `VM.Config.Type`, so `caps.mapping.hwrng` is never > evaluated. > > [...] Applied, with two commit message typos fixed, thanks! [1/1] ui: qemu: hardware view: fix hwrng cap check for unprivileged users commit: c7b75cc57f4ad2c44d4876418efef8b6eadd43ce ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH i18n] update German translations
Am 08.04.25 um 16:33 schrieb Shannon Sterz:
> Signed-off-by: Shannon Sterz
> ---
> de.po | 226 +-
> 1 file changed, 98 insertions(+), 128 deletions(-)
Hmm, when trying to apply this (with b4) I got an warning:
> @@ -5967,6 +5948,7 @@ msgstr "Live Wiederherstellung"
> #: pve-manager/www/manager6/window/Migrate.js:302
> msgid "Live-migrating running VM with mapped resources (Experimental): {0}"
> msgstr ""
> +"Laufende VM mit gemappten Ressourcen wird live-migriert
> (experimentell): {0}"
WARNING: Message contains suspicious unicode control characters!
Subject: [pve-devel] [PATCH i18n] update German translations
Line: +"Laufende VM mit gemappten Ressourcen wird live-migriert
(experimentell): {0}"
---^
Char: SOFT HYPHEN (0xad)
And with the right tools one sees hyphens in experimentell, but not if one
copies
that text in some textareas or the like, which is a feature of soft-hyphens.
Was this done intentionally?
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH i18n v2] update German translations
Signed-off-by: Shannon Sterz --- de.po | 226 +- 1 file changed, 98 insertions(+), 128 deletions(-) diff --git a/de.po b/de.po index 1c1965d..7339f83 100644 --- a/de.po +++ b/de.po @@ -8,7 +8,7 @@ msgstr "" "Project-Id-Version: proxmox translations\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: Tue Apr 8 12:23:34 2025\n" -"PO-Revision-Date: 2024-11-28 10:10+0100\n" +"PO-Revision-Date: 2025-04-08 16:07+0200\n" "Last-Translator: Proxmox Support Team \n" "Language-Team: German\n" "Language: de\n" @@ -21,20 +21,19 @@ msgstr "" #: proxmox-backup/www/tape/window/TapeBackup.js:127 #: proxmox-backup/www/tape/window/TapeBackupJob.js:224 msgid "# of Worker Threads" -msgstr "" +msgstr "# von Worker Threads" #: pmg-gui/js/SystemOptions.js:85 msgid "'From:' for Admin Mail" -msgstr "" +msgstr "'From': Absender für Admin Mails" #: pve-manager/www/manager6/qemu/Options.js:95 msgid "(No boot device selected)" msgstr "(Kein Startgerät ausgewählt)" #: pve-manager/www/manager6/dc/AuthEditOpenId.js:98 -#, fuzzy msgid "(none)" -msgstr "keine" +msgstr "(keiner)" #: proxmox-backup/www/config/SyncView.js:242 msgid "(remote) store, remote, id, owner, direction" @@ -56,11 +55,11 @@ msgstr "/ein/pfad" #: proxmox-backup/www/datastore/OptionView.js:303 msgid "1048576 (0 disables cache)" -msgstr "" +msgstr "1048576 (0 deaktiviert den Cache)" #: proxmox-backup/www/datastore/OptionView.js:295 msgid "1445 (24 hours 5 minutes)" -msgstr "" +msgstr "1445 (24 Stunden 5 Minuten)" #: pmg-gui/js/PBSConfig.js:39 msgid "5 Minutes" @@ -91,8 +90,8 @@ msgid "" "A selected device is not in a separate IOMMU group, make sure this is " "intended." msgstr "" -"Ein ausgewähltes Gerät befindet sich in keiner eigenen IOMMU-Gruppe, ist das " -"so gewollt?" +"Ein ausgewähltes Gerät befindet sich in keiner eigenen IOMMU-Gruppe, stellen " +"Sie sicher, dass das so gewollt ist." #: proxmox-widget-toolkit/src/window/AuthEditLDAP.js:414 #: proxmox-widget-toolkit/src/window/SyncWindow.js:110 @@ -368,18 +367,16 @@ msgid "Add Datastore" msgstr "Datastore hinzufügen" #: pve-manager/www/manager6/window/DirMapEdit.js:26 -#, fuzzy msgid "Add Directory Mapping" -msgstr "Verzeichnis-Storage" +msgstr "Verzeichnis Mapping hinzufügen" #: pve-manager/www/manager6/qemu/SystemEdit.js:117 msgid "Add EFI Disk" msgstr "EFI-Disk hinzufügen" #: proxmox-widget-toolkit/src/panel/WebhookEditPanel.js:73 -#, fuzzy msgid "Add Header" -msgstr "Header" +msgstr "Header hinzufügen" #: proxmox-backup/www/datastore/Content.js:1260 msgid "Add Namespace" @@ -398,9 +395,8 @@ msgid "Add Remote" msgstr "Remote hinzufügen" #: proxmox-widget-toolkit/src/panel/WebhookEditPanel.js:95 -#, fuzzy msgid "Add Secret" -msgstr "Secret" +msgstr "Geheimnis hinzufügen" #: pmg-gui/js/Utils.js:720 msgid "Add Separator" @@ -415,7 +411,7 @@ msgstr "Storage hinzufügen" #: pmg-gui/js/MailProxyTLS.js:14 msgid "Add TLS received header" -msgstr "TLS 'received header' hinzufügen." +msgstr "TLS 'received header' hinzufügen" #: pve-manager/www/manager6/qemu/SystemEdit.js:166 msgid "Add TPM" @@ -612,7 +608,7 @@ msgstr "Alle fehlgeschlagen" #: pmg-gui/js/form/MatchModeSelector.js:6 msgid "All match" -msgstr "alle zutreffen" +msgstr "Alle stimmen überein" #: proxmox-widget-toolkit/src/window/NotificationMatcherEdit.js:497 #: proxmox-widget-toolkit/src/window/NotificationMatcherEdit.js:886 @@ -635,7 +631,7 @@ msgstr "Debuggen erlauben" #: pve-manager/www/manager6/qemu/VirtiofsEdit.js:87 msgid "Allow Direct IO" -msgstr "" +msgstr "Direkt IO erlauben" #: pmg-gui/js/SpamQuarantineOptions.js:68 #: pmg-gui/js/VirusQuarantineOptions.js:20 @@ -647,9 +643,8 @@ msgid "Allow Key-Sharing" msgstr "Teilen von Schlüsseln erlauben" #: pve-manager/www/manager6/qemu/SevEdit.js:109 -#, fuzzy msgid "Allow SMT" -msgstr "Erlaube HREFs" +msgstr "SMT erlauben" #: pve-manager/www/manager6/window/BulkAction.js:87 msgid "Allow local disk migration" @@ -690,7 +685,7 @@ msgstr "Anonyme Suche" #: pmg-gui/js/form/MatchModeSelector.js:7 msgid "Any matches" -msgstr "beliebige Übereinstimmungen" +msgstr "Beliebige Übereinstimmungen" #: proxmox-widget-toolkit/src/window/NotificationMatcherEdit.js:503 #: proxmox-widget-toolkit/src/window/NotificationMatcherEdit.js:887 @@ -698,9 +693,8 @@ msgid "Any rule matches" msgstr "mindestens eine Regel zutrifft" #: pve-manager/www/manager6/ceph/Pool.js:314 -#, fuzzy msgid "Application" -msgstr "Replizierung" +msgstr "Applikation" #: pve-manager/www/manager6/dc/OptionView.js:468 msgid "Applies to new edits" @@ -939,9 +933,8 @@ msgid "Auto-generate a client encryption key" msgstr "Client-Schlüssel automatisch generieren" #: pve-manager/www/manager6/dc/AuthEditOpenId.js:87 -#, fuzzy msgid "Autocreate Groups" -msgstr "Benutzer auto-erstellen" +msgstr "Gruppen auto-erstellen" #: proxmox-widget-toolkit/src/window/AuthEditOpenId.js:74 #: pve-m
Re: [pve-devel] [PATCH i18n] update German translations
On Tue Apr 8, 2025 at 4:39 PM CEST, Thomas Lamprecht wrote:
> Am 08.04.25 um 16:33 schrieb Shannon Sterz:
>> Signed-off-by: Shannon Sterz
>> ---
>> de.po | 226 +-
>> 1 file changed, 98 insertions(+), 128 deletions(-)
>
>
> Hmm, when trying to apply this (with b4) I got an warning:
>
>> @@ -5967,6 +5948,7 @@ msgstr "Live Wiederherstellung"
>> #: pve-manager/www/manager6/window/Migrate.js:302
>> msgid "Live-migrating running VM with mapped resources (Experimental): {0}"
>> msgstr ""
>> +"Laufende VM mit gemappten Ressourcen wird live-migriert
>> (experimentell): {0}"
>
> WARNING: Message contains suspicious unicode control characters!
> Subject: [pve-devel] [PATCH i18n] update German translations
> Line: +"Laufende VM mit gemappten Ressourcen wird live-migriert
> (experimentell): {0}"
>
> ---^
> Char: SOFT HYPHEN (0xad)
>
> And with the right tools one sees hyphens in experimentell, but not if
> one copies
> that text in some textareas or the like, which is a feature of soft-hyphens.
> Was this done intentionally?
no, sorry, that must have happened by accident, somehow didn't catch
this. re-send a v2 without those.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH-SERIES http-server 0/3] fix disconnecting clients
On Tue, 08 Apr 2025 16:20:11 +0200, Fiona Ebner wrote:
> Commit 07e56cc ("fix unexpected EOF for client when closing TLS
> session") added a call to stoptls() before the call to shutdown() for
> the handle's file descriptor. However, the documentation for
> AnyEvent[0] mentions for stoptls():
>
> > This method may invoke callbacks (and therefore the handle might be
> > destroyed after it returns).
>
> [...]
Applied, thanks!
Btw. I did some benchmarks yesterday running `oha` [0] and I rechecked the logs
and I found a handful of such error messages too that I did overlook before.
With your patches I could not see them anymore after running a 10s five times
(vs just once yesterday)
[1/3] anyevent: disconnect: check that handle is still defined before calling
shutdown()
commit: 0ec627cff14a51695e6f81f86b34b398b07cf329
[2/3] anyevent: always avoid re-entering client_do_disconnect() in on_error
callback
commit: fa639169214f679c90274e4a6f1a84b864212326
[3/3] anyevent: handle 'disconnected' flag in client_do_disconnect() itself
commit: f82b416214c94720c04dd02d5f5778af3439187f
[0]: https://github.com/hatoo/oha
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH i18n v2] update German translations
On Tue, 08 Apr 2025 16:51:46 +0200, Shannon Sterz wrote: > Applied, thanks! [1/1] update German translations commit: 5d3ea37c3c30c2fb26e1a065ecd7b5848a3e112c ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v4 1/3] lxc: show dynamically assigned IPs in network tab
On 08.04.2025 12:18, Thomas Lamprecht wrote:
Am 08.04.25 um 12:06 schrieb Gabriel Goller:
On 07.04.2025 19:46, Thomas Lamprecht wrote:
Am 08.01.25 um 15:38 schrieb Gabriel Goller:
adds a call to /nodes/{node}/lxc/{vmid}/interfaces and merges the
returned data with the existing configuration. This will update the
IPv4 and IPv6 address, as well as the interface name (in case the
container changed it).
Originally-by: Leo Nunner
Signed-off-by: Gabriel Goller
---
www/manager6/lxc/Network.js | 85 ++---
1 file changed, 60 insertions(+), 25 deletions(-)
the network view's grid gets broken here for any container that is not
turned on, and thus cannot have an address configured.
Umm this is kinda tricky, the proxmoxRRDChart has a fixed height of 300,
and changing that probably breakes a lot of stuff. I could make the
GuestView (so the first panel) scrollable, but then additional text or
the "More" button will probably be cut off (when not scrolling).
There are no RRD graphs in the network view, what are you talking about?
I mean the columns of the network configuration view stop rendering with
these patches starting from the address column rightwards.
Oh, I'm stupid, I thought of the grid in the GuestSummary "IPs"
property.
Anyway, fixed the problem you reported.
The problem I mentioned still exists, although it isn't really that bad.
I added the IP addresses and a "More" button to the Container Summary
and increased it's height, so as to make room for it. This make
everything look kinda weird (i.e., the GuestSummary panel is higher than
the CPU usage RRD graph.) But as I said, we could make it scrollable?
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager v4 1/3] lxc: show dynamically assigned IPs in network tab
Am 08.04.25 um 14:15 schrieb Gabriel Goller: > If you want to take this in with this release, I can send a new version, > but I'd like to wait a bit to be honest. > > The Summary looks currently a bit rough, even with the scrollbar. Also > we can't differentiate between a dhcp ip-address or an address set > manually on the container itself (and we always show dhcp, which is > kinda wrong). > Yeah, definitively no need to rush this. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager v7 2/3] ui: vm create wizard: allow importing disks
by adding a new 'import' button in the disk tab, which adds the same
input panel as the one we have when doing an 'Import Hard Disk' for an
existing VM.
partially fixes #2424
Signed-off-by: Dominik Csapak
---
www/manager6/panel/MultiDiskEdit.js | 36 +
www/manager6/qemu/MultiHDEdit.js| 5 +++-
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/www/manager6/panel/MultiDiskEdit.js
b/www/manager6/panel/MultiDiskEdit.js
index ea1f974d..ffa2f234 100644
--- a/www/manager6/panel/MultiDiskEdit.js
+++ b/www/manager6/panel/MultiDiskEdit.js
@@ -1,6 +1,8 @@
Ext.define('PVE.panel.MultiDiskPanel', {
extend: 'Ext.panel.Panel',
+mixins: ['Proxmox.Mixin.CBind'],
+
setNodename: function(nodename) {
this.items.each((panel) => panel.setNodename(nodename));
},
@@ -8,6 +10,8 @@ Ext.define('PVE.panel.MultiDiskPanel', {
border: false,
bodyBorder: false,
+importDisk: false, // allow import panel
+
layout: 'card',
controller: {
@@ -16,25 +20,35 @@ Ext.define('PVE.panel.MultiDiskPanel', {
vmconfig: {},
onAdd: function() {
+ this.addDiskChecked(false);
+ },
+
+ onImport: function() {
+ this.addDiskChecked(true);
+ },
+
+ addDiskChecked: function(importDisk) {
let me = this;
me.lookup('addButton').setDisabled(true);
- me.addDisk();
+ me.lookup('addImportButton').setDisabled(true);
+ me.addDisk(importDisk);
let count = me.lookup('grid').getStore().getCount() + 1; // +1 is
from ide2
me.lookup('addButton').setDisabled(count >= me.maxCount);
+ me.lookup('addImportButton').setDisabled(count >= me.maxCount);
},
getNextFreeDisk: function(vmconfig) {
throw "implement in subclass";
},
- addPanel: function(itemId, vmconfig, nextFreeDisk) {
+ addPanel: function(itemId, vmconfig, nextFreeDisk, importDisk) {
throw "implement in subclass";
},
// define in subclass
diskSorter: undefined,
- addDisk: function() {
+ addDisk: function(importDisk) {
let me = this;
let grid = me.lookup('grid');
let store = grid.getStore();
@@ -53,7 +67,7 @@ Ext.define('PVE.panel.MultiDiskPanel', {
itemId,
})[0];
- let panel = me.addPanel(itemId, vmconfig, nextFreeDisk);
+ let panel = me.addPanel(itemId, vmconfig, nextFreeDisk, importDisk);
panel.updateVMConfig(vmconfig);
// we need to setup a validitychange handler, so that we can show
@@ -171,6 +185,7 @@ Ext.define('PVE.panel.MultiDiskPanel', {
store.remove(record);
me.getView().remove(record.get('itemId'));
me.lookup('addButton').setDisabled(false);
+ me.lookup('addImportButton').setDisabled(false);
me.updateVMConfig();
me.checkValidity();
},
@@ -210,6 +225,7 @@ Ext.define('PVE.panel.MultiDiskPanel', {
dock: 'left',
border: false,
width: 130,
+ cbind: {}, // for nested cbinds
items: [
{
xtype: 'grid',
@@ -257,6 +273,18 @@ Ext.define('PVE.panel.MultiDiskPanel', {
iconCls: 'fa fa-plus-circle',
handler: 'onAdd',
},
+ {
+ xtype: 'button',
+ reference: 'addImportButton',
+ text: gettext('Import'),
+ iconCls: 'fa fa-cloud-download',
+ handler: 'onImport',
+ margin: '5 0 0 0',
+ cbind: {
+ disabled: '{!importDisk}',
+ hidden: '{!importDisk}',
+ },
+ },
{
// dummy field to control wizard validation
xtype: 'textfield',
diff --git a/www/manager6/qemu/MultiHDEdit.js b/www/manager6/qemu/MultiHDEdit.js
index 27884f3f..159236b6 100644
--- a/www/manager6/qemu/MultiHDEdit.js
+++ b/www/manager6/qemu/MultiHDEdit.js
@@ -4,6 +4,8 @@ Ext.define('PVE.qemu.MultiHDPanel', {
onlineHelp: 'qm_hard_disk',
+importDisk: true,
+
controller: {
xclass: 'Ext.app.ViewController',
@@ -16,7 +18,7 @@ Ext.define('PVE.qemu.MultiHDPanel', {
return PVE.Utils.nextFreeDisk(clist, vmconfig);
},
- addPanel: function(itemId, vmconfig, nextFreeDisk) {
+ addPanel: function(itemId, vmconfig, nextFreeDisk, importDisk) {
let me = this;
return me.getView().add({
vmconfig,
@@ -30,6 +32,7 @@ Ext.define('PVE.qemu.MultiHDPanel', {
itemId,
isCreate: true,
insideWizard: true,
+ importDisk,
});
},
--
2.39.5
Re: [pve-devel] [PATCH pve-network 1/1] ipam: netbox: fix adding vms without a name set in the options
On Tue, 08 Apr 2025 15:25:17 +0200, Stefan Hanreich wrote: > The hostname provided to the methods in the IPAM plugins is empty for > VMs that do not have a name set. We always included the dns_name key > in the request, even if it was undefined, which leads Netbox to return > a 400 Bad Request error. With this patch we omit the dns_name > parameter if it isn't set, so the call succeeds. > > > [...] Applied, thanks! [1/1] ipam: netbox: fix adding vms without a name set in the options commit: 3ede261b255263ba79a63446305ba0a0f408592c ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH] add patch to disable elastic_shared_blob to prevent crashing OSDs
On Tue, 08 Apr 2025 12:39:04 +0200, Stoiko Ivanov wrote: > reported in our community forum and upstream: > https://forum.proxmox.com/threads/164735/ > https://tracker.ceph.com/issues/70390 > https://github.com/ceph/ceph/pull/62724 > > fix seems trivial, and the feature is quite new: > https://ceph.io/assets/pdfs/events/2024/ceph-days-nyc/Diving%20Deep%20with%20Squid.pdf > > [...] Applied, thanks! [1/1] add patch to disable elastic_shared_blob to prevent crashing OSDs commit: 0e9e827cd8a81e2724bdb81cb7611453c7fa068e ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH access-control] openid: fix groups-claim regex
On Tue, 08 Apr 2025 13:33:49 +0200, Mira Limbeck wrote: > The previous regex matched exactly that combination of characters, > rather than any combination of the specified ones. > > Applied, thanks! [1/1] openid: fix groups-claim regex commit: 55ab21ecfcd090ef7d364be39bdbb740391138a4 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server 2/3] virtiofs: drop writeback option
VirtIO-fs using writeback cache seems very broken at the moment. If a
guest accesses a file (even just using 'touch'), that the host is
currently writing, the guest can permanently end up with a truncated
version of that file. Even subsequent operations like moving the file,
will not result in the correct file being visible, but just rename the
truncated one.
Signed-off-by: Fiona Ebner
---
PVE/QemuServer/Virtiofs.pm | 8
1 file changed, 8 deletions(-)
diff --git a/PVE/QemuServer/Virtiofs.pm b/PVE/QemuServer/Virtiofs.pm
index 13035c9b..cfde92c9 100644
--- a/PVE/QemuServer/Virtiofs.pm
+++ b/PVE/QemuServer/Virtiofs.pm
@@ -45,13 +45,6 @@ my $virtiofs_fmt = {
default => 0,
optional => 1,
},
-writeback => {
- type => 'boolean',
- description => "Enable writeback cache. If enabled, writes may be
cached in the guest until"
- ." the file is closed or an fsync is performed.",
- default => 0,
- optional => 1,
-},
'expose-xattr' => {
type => 'boolean',
description => "Enable support for extended attributes for this mount.",
@@ -182,7 +175,6 @@ sub start_virtiofsd {
push @$cmd, '--announce-submounts';
push @$cmd, '--allow-direct-io' if $virtiofs->{'direct-io'};
push @$cmd, '--cache='.$virtiofs->{cache} if $virtiofs->{cache};
- push @$cmd, '--writeback' if $virtiofs->{'writeback'};
push @$cmd, '--syslog';
exec(@$cmd);
} elsif (!defined($pid2)) {
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 1/1] frr: enable frr service on reloading the controller config
On 08/04/2025 18:32, Stefan Hanreich wrote:
> Since we now ship frr with Proxmox VE, the frr service is available on
> the nodes but disabled on install. Prior to that users had to manually
> install frr, which automatically enabled the service. When applying a
> SDN configuration with an EVPN controller, we invoke systemctl restart
> frr, which leads to the service running but still being in the
> disabled state. This means that the EVPN setup is working until the
> next reboot. To avoid the situation where users configure an EVPN
> controller and everything seems to be working, until a restart breaks
> the EVPN setup, additionally enable the frr service before restarting
> it.
>
> Signed-off-by: Stefan Hanreich
> ---
> src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> index c245ea2..4249cc5 100644
> --- a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> +++ b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> @@ -638,6 +638,7 @@ sub reload_controller {
> };
> if ($@) {
> warn "frr reload command fail. Restarting frr.";
> + run_command(['systemctl', 'enable', 'frr']);
can we guard this with an file exists check for
"/etc/systemd/system/multi-user.target.wants/frr.service"? Not a must, but does
not feel right to unconditionally call systemctl enable.
> eval { run_command(['systemctl', 'restart', 'frr']); };
> }
> }
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH installer] btrfs: write /etc/kernel/cmdline unconditionally
the recent change of handing the ESPs to proxmox-boot-tool broke
installation on btrfs booted with systemd-boot (currently efi-systems
without secureboot). our systemd-boot config-generation takes the
kernel commandline from /etc/kernel/cmdline - without this there is no
root= parameter, and we end up in a initramfs shell.
write the file unconditionally of boot-mode (legacy, efi,
efi-secureboot), to be consistent with the way we do it on ZFS.
the uuid is stored in a variable instead of running blkid multiple
time primarily to not end up with different versions of a similar
command in the future, at the expense of 3 change-sites which are
quite far apart.
Fixes: dc5b8d7 ("btrfs: use proxmox-boot-tool to sync ESPs for RAID installs")
Signed-off-by: Stoiko Ivanov
---
tested minimally with a vm with a single disk booted with a efi-disk without
enrolled keys - as this is what broke for me.
Proxmox/Install.pm | 9 +
1 file changed, 9 insertions(+)
diff --git a/Proxmox/Install.pm b/Proxmox/Install.pm
index cb6c502..f673604 100644
--- a/Proxmox/Install.pm
+++ b/Proxmox/Install.pm
@@ -751,6 +751,7 @@ sub extract_data {
my ($swapfile, $rootdev, $datadev);
my ($use_zfs, $use_btrfs) = (0, 0);
+my $btrfs_uuid;
my $filesys = Proxmox::Install::Config::get_filesys();
my $hdsize = Proxmox::Install::Config::get_hdsize();
@@ -1125,6 +1126,9 @@ sub extract_data {
die "unable to detect FS UUID" if !defined($fsuuid);
+ # needed for /etc/kernel/cmdline when making the system bootable.
+ $btrfs_uuid = $fsuuid;
+
my $btrfs_opts = Proxmox::Install::Config::get_btrfs_opt();
my $mountopts = 'defaults';
@@ -1333,6 +1337,11 @@ _EOD
file_write_all("$targetdir/etc/kernel/cmdline",
"root=ZFS=$zfs_pool_name/ROOT/$zfs_root_volume_name boot=zfs
$target_cmdline\n");
}
+ if ($use_btrfs) {
+ # add root= option to /etc/kernel/cmdline as well (for
systemd-boot+btrfs)
+ file_write_all("$targetdir/etc/kernel/cmdline",
"root=UUID=$btrfs_uuid $target_cmdline\n");
+ }
+
# Always write zfs module parameter - even if the user did not select
ZFS-on-root.
# It still makes sense to provide a sensible default for zfs_arc_max,
in case a
# separate zfs pool is created afterwards.
--
2.39.5
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-network 1/1] frr: enable frr service on reloading the controller config
> On 08.04.2025 20:43 CEST Thomas Lamprecht wrote:
>
>
> On 08/04/2025 18:32, Stefan Hanreich wrote:
> > Since we now ship frr with Proxmox VE, the frr service is available on
> > the nodes but disabled on install. Prior to that users had to manually
> > install frr, which automatically enabled the service. When applying a
> > SDN configuration with an EVPN controller, we invoke systemctl restart
> > frr, which leads to the service running but still being in the
> > disabled state. This means that the EVPN setup is working until the
> > next reboot. To avoid the situation where users configure an EVPN
> > controller and everything seems to be working, until a restart breaks
> > the EVPN setup, additionally enable the frr service before restarting
> > it.
> >
> > Signed-off-by: Stefan Hanreich
> > ---
> > src/PVE/Network/SDN/Controllers/EvpnPlugin.pm | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > index c245ea2..4249cc5 100644
> > --- a/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > +++ b/src/PVE/Network/SDN/Controllers/EvpnPlugin.pm
> > @@ -638,6 +638,7 @@ sub reload_controller {
> > };
> > if ($@) {
> > warn "frr reload command fail. Restarting frr.";
> > + run_command(['systemctl', 'enable', 'frr']);
>
> can we guard this with an file exists check for
> "/etc/systemd/system/multi-user.target.wants/frr.service"? Not a must, but
> does
> not feel right to unconditionally call systemctl enable.
probably a bit too convoluted and unclear, but this is guarded by the existence
of frr-reload.py already, which requires frr to be installed (above in the if
with an early return).
I can certainly whip up a v2 quite early tomorrow, shouldn't take long. Do you
have any input on pre-installing frr-pythontools as well?
> > eval { run_command(['systemctl', 'restart', 'frr']); };
> > }
> > }
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
