[pve-devel] Proxmox VE 6.4 released
Hi all, We are proud to announce the general availability of Proxmox Virtual Environment 6.4, our open-source virtualization platform. This version brings unified single-file restore for virtual machine (VM) and container (CT) backup archives stored on a Proxmox Backup Server as well as live restore of VM backup archives located on a Proxmox Backup Server. Version 6.4 also comes with Ceph Octopus 15.2.11 and Ceph Nautilus 14.2.20, many enhancements to KVM/QEMU, and notable bug fixes. Many new Ceph-specific management features have been added to the GUI. We have improved the integration of the placement group (PG) auto-scaler, and you can configure Target Size or Target Ratio settings in the GUI. The new version is based on Debian Buster 10.9, but using a newer, long-term supported Linux kernel 5.4. Optionally, the 5.11 kernel can be installed, providing support for the latest hardware. The latest versions of QEMU 5.2, LXC 4.0, and OpenZFS 2.0.4 have been included. There are some notable bug fixes and smaller improvements, see the full release notes. Release notes https://pve.proxmox.com/wiki/Roadmap Press release https://www.proxmox.com/en/news/press-releases/proxmox-virtual-environment-6-4-available Video tutorial https://www.proxmox.com/en/training/video-tutorials/item/what-s-new-in-proxmox-ve-6-4 Download https://www.proxmox.com/en/downloads Alternate ISO download: http://download.proxmox.com/iso Documentation https://pve.proxmox.com/pve-docs Community Forum https://forum.proxmox.com Source Code https://git.proxmox.com Bugtracker https://bugzilla.proxmox.com FAQ Q: Can I dist-upgrade Proxmox VE 6.x to 6.4 with apt? A: Yes, just via GUI or via CLI with apt update && apt dist-upgrade Q: Can I install Proxmox VE 6.4 on top of Debian Buster? A: Yes, see https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Buster Q: Can I upgrade my Proxmox VE 5.4 cluster with Ceph Luminous to 6.x and higher with Ceph Nautilus and even Ceph Octopus? A: This is a three step process. First, you have to upgrade Proxmox VE from 5.4 to 6.4, and afterwards upgrade Ceph from Luminous to Nautilus. There are a lot of improvements and changes, please follow exactly the upgrade documentation. https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0 https://pve.proxmox.com/wiki/Ceph_Luminous_to_Nautilus Finally, do the upgrade to Ceph Octopus - https://pve.proxmox.com/wiki/Ceph_Nautilus_to_Octopus Q: Where can I get more information about feature updates? A: Check our roadmap, forum, mailing lists, and subscribe to our newsletter. A big THANK YOU to our active community for all your feedback, testing, bug reporting and patch submitting! -- Best Regards, Martin Maurer Proxmox VE project leader ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH docs] pveproxy: improve LISTEN_IP doc
* fix small typo * add details for link-local addresses * mention that pveproxy needs to be restarted Signed-off-by: Oguz Bektas --- pveproxy.adoc | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/pveproxy.adoc b/pveproxy.adoc index 08c5f63..b9f8ade 100644 --- a/pveproxy.adoc +++ b/pveproxy.adoc @@ -71,10 +71,18 @@ exposure to the public internet: LISTEN_IP="192.0.2.1" -Similarly you can also set a n IPv6 address: +Similarly you can also set an IPv6 address: LISTEN_IP="2001:db8:85a3::1" +And for a link-local IPv6 address on vmbr0 (interface name is necessary in this case): + + LISTEN_IP="fe80::d8ee:34ff:fe37:4579%vmbr0" + +After the change you have to restart `pveproxy` for it to take effect: + + systemctl restart pveproxy + WARNING: The nodes in a cluster need access to `pveproxy` for communication, possibly on different sub-nets. It is **not recommended** to set `LISTEN_IP` on clustered systems. -- 2.20.1 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs] pveproxy: improve LISTEN_IP doc
On 28.04.21 13:16, Oguz Bektas wrote: > * fix small typo > * add details for link-local addresses > * mention that pveproxy needs to be restarted > > Signed-off-by: Oguz Bektas > --- > pveproxy.adoc | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/pveproxy.adoc b/pveproxy.adoc > index 08c5f63..b9f8ade 100644 > --- a/pveproxy.adoc > +++ b/pveproxy.adoc > @@ -71,10 +71,18 @@ exposure to the public internet: > > LISTEN_IP="192.0.2.1" > > -Similarly you can also set a n IPv6 address: > +Similarly you can also set an IPv6 address: > > LISTEN_IP="2001:db8:85a3::1" > > +And for a link-local IPv6 address on vmbr0 (interface name is necessary in > this case): Does not reads like an actual sentence... I'd write something a long the lines of: "Note, if you want to specify a link-local IPv6 address, you need to provide the interface name itself:" > + > + LISTEN_IP="fe80::d8ee:34ff:fe37:4579%vmbr0" > + > +After the change you have to restart `pveproxy` for it to take effect: I'd specifically state that a reload is not enough and then add a small warning that a restart can stop some existing workers (not all, but e.g., shell connection is stopped and reconnected which may loose info on CTs without a screen/tmux instance running). Also, there's a short time window where no new connections are accepted IIRC (albeit I was the one fixing that for reload it's been to long since then, so not sure anymore) > + > + systemctl restart pveproxy and spiceproxy? > + > WARNING: The nodes in a cluster need access to `pveproxy` for communication, > possibly on different sub-nets. It is **not recommended** to set `LISTEN_IP` > on > clustered systems. > ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs] pveproxy: improve LISTEN_IP doc
On 28.04.21 13:42, Oguz Bektas wrote: >>> + >>> + LISTEN_IP="fe80::d8ee:34ff:fe37:4579%vmbr0" >>> + >>> +After the change you have to restart `pveproxy` for it to take effect: >> >> I'd specifically state that a reload is not enough and then add a small >> warning that >> a restart can stop some existing workers (not all, but e.g., shell >> connection is stopped >> and reconnected which may loose info on CTs without a screen/tmux instance >> running). >> Also, there's a short time window where no new connections are accepted IIRC >> (albeit >> I was the one fixing that for reload it's been to long since then, so not >> sure anymore) > > i think the phrasing "you have to restart" already emphasizes this, > adding too many warnings or notes would just confuse users in my > opinion. No, it's clear that something needs to be restarted, but "restart" is a general overused term which can mean lots of things (even reboot for some). > > though i don't see any harm in making the **restart** bold in that > sentence and adding that small warning about possible connection drop. as said, restart is often used for the general semantic thing, be it reload or restart, so this is really not clear. The gui also only triggers a reload, IIRC (pls. check) and thus "restarting" (it's named that way there) from there would not help. You just need to write it in such a way that it is not confusing, then it is not a problem. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs] pveproxy: improve LISTEN_IP doc
hi, thanks for checking. On Wed, Apr 28, 2021 at 01:35:40PM +0200, Thomas Lamprecht wrote: > On 28.04.21 13:16, Oguz Bektas wrote: > > * fix small typo > > * add details for link-local addresses > > * mention that pveproxy needs to be restarted > > > > Signed-off-by: Oguz Bektas > > --- > > pveproxy.adoc | 10 +- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/pveproxy.adoc b/pveproxy.adoc > > index 08c5f63..b9f8ade 100644 > > --- a/pveproxy.adoc > > +++ b/pveproxy.adoc > > @@ -71,10 +71,18 @@ exposure to the public internet: > > > > LISTEN_IP="192.0.2.1" > > > > -Similarly you can also set a n IPv6 address: > > +Similarly you can also set an IPv6 address: > > > > LISTEN_IP="2001:db8:85a3::1" > > > > +And for a link-local IPv6 address on vmbr0 (interface name is necessary in > > this case): > > Does not reads like an actual sentence... I'd write something a long the > lines of: > > "Note, if you want to specify a link-local IPv6 address, you need to provide > the interface name itself:" okay > > > + > > + LISTEN_IP="fe80::d8ee:34ff:fe37:4579%vmbr0" > > + > > +After the change you have to restart `pveproxy` for it to take effect: > > I'd specifically state that a reload is not enough and then add a small > warning that > a restart can stop some existing workers (not all, but e.g., shell connection > is stopped > and reconnected which may loose info on CTs without a screen/tmux instance > running). > Also, there's a short time window where no new connections are accepted IIRC > (albeit > I was the one fixing that for reload it's been to long since then, so not > sure anymore) i think the phrasing "you have to restart" already emphasizes this, adding too many warnings or notes would just confuse users in my opinion. though i don't see any harm in making the **restart** bold in that sentence and adding that small warning about possible connection drop. > > > + > > + systemctl restart pveproxy > > and spiceproxy? ah yes forgot that, also adding to v2 > > > + > > WARNING: The nodes in a cluster need access to `pveproxy` for > > communication, > > possibly on different sub-nets. It is **not recommended** to set > > `LISTEN_IP` on > > clustered systems. > > ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs] pveproxy: improve LISTEN_IP doc
On Wed, Apr 28, 2021 at 01:51:51PM +0200, Thomas Lamprecht wrote: > On 28.04.21 13:42, Oguz Bektas wrote: > >>> + > >>> + LISTEN_IP="fe80::d8ee:34ff:fe37:4579%vmbr0" > >>> + > >>> +After the change you have to restart `pveproxy` for it to take effect: > >> > >> I'd specifically state that a reload is not enough and then add a small > >> warning that > >> a restart can stop some existing workers (not all, but e.g., shell > >> connection is stopped > >> and reconnected which may loose info on CTs without a screen/tmux instance > >> running). > >> Also, there's a short time window where no new connections are accepted > >> IIRC (albeit > >> I was the one fixing that for reload it's been to long since then, so not > >> sure anymore) > > > > i think the phrasing "you have to restart" already emphasizes this, > > adding too many warnings or notes would just confuse users in my > > opinion. > > No, it's clear that something needs to be restarted, but "restart" is a > general > overused term which can mean lots of things (even reboot for some). > > > > > though i don't see any harm in making the **restart** bold in that > > sentence and adding that small warning about possible connection drop. > > as said, restart is often used for the general semantic thing, be it reload > or restart, > so this is really not clear. why is it not clear? there's not a single instance of 'systemctl reload' command in the documentation, and in instances where a service restart is required, we specify 'systemctl restart' without any mention, e.g., in pvenode.adoc when setting up certificates) so i don't see why users would imagine to 'reload' the service instead of 'restart' when it's clearly written in bold, and the command is right beneath the explanation... > The gui also only triggers a reload, IIRC (pls. check) > and thus "restarting" (it's named that way there) from there would not help. yes, on the button it says "restart" but the tasklog says "reload". so to me that sounds like a mislabeled button with wrong/lax use of "restart" instead of the correct "reload". > > You just need to write it in such a way that it is not confusing, then it is > not > a problem. there's really nothing confusing IMO (besides the button). but if you insist i will send another patch with the changes you recommended. some possible alternative phrasing i'd suggest: = After the change you have to **restart** `pveproxy` and `spiceproxy` for it to take effect (**reload** or restart from GUI does not suffice): systemctl restart pveproxy spiceproxy = or much simpler and less confusing: = Run the following command to restart the proxy servers and apply the change: systemctl restart pveproxy spiceproxy = with a note about the connection drop during restart. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs] pveproxy: improve LISTEN_IP doc
On 28.04.21 14:20, Oguz Bektas wrote: > On Wed, Apr 28, 2021 at 01:51:51PM +0200, Thomas Lamprecht wrote: >> On 28.04.21 13:42, Oguz Bektas wrote: > + > + LISTEN_IP="fe80::d8ee:34ff:fe37:4579%vmbr0" > + > +After the change you have to restart `pveproxy` for it to take effect: I'd specifically state that a reload is not enough and then add a small warning that a restart can stop some existing workers (not all, but e.g., shell connection is stopped and reconnected which may loose info on CTs without a screen/tmux instance running). Also, there's a short time window where no new connections are accepted IIRC (albeit I was the one fixing that for reload it's been to long since then, so not sure anymore) >>> >>> i think the phrasing "you have to restart" already emphasizes this, >>> adding too many warnings or notes would just confuse users in my >>> opinion. >> >> No, it's clear that something needs to be restarted, but "restart" is a >> general >> overused term which can mean lots of things (even reboot for some). >> >>> >>> though i don't see any harm in making the **restart** bold in that >>> sentence and adding that small warning about possible connection drop. >> >> as said, restart is often used for the general semantic thing, be it reload >> or restart, >> so this is really not clear. > > why is it not clear? there's not a single instance of 'systemctl reload' > command in the documentation, and in instances where a service restart > is required, we specify 'systemctl restart' without any mention, e.g., > in pvenode.adoc when setting up certificates) > > so i don't see why users would imagine to 'reload' the service instead > of 'restart' when it's clearly written in bold, and the command is > right beneath the explanation... > >> The gui also only triggers a reload, IIRC (pls. check) >> and thus "restarting" (it's named that way there) from there would not help. > > yes, on the button it says "restart" but the tasklog says "reload". > so to me that sounds like a mislabeled button with wrong/lax use > of "restart" instead of the correct "reload". I *always* use try-reload-or-restart, as I want to avoid service disruption, as most people actually running relevant systems do... What I surely do not is reading all the docs, comparing how often reload vs. restart is used and then try to read into that and conclude something from that... I *never* saw anybody complaining about an additional note of some side-effects that may come unexpected, but I saw quite some situations where there was no such note and user run into issues, I do not suggest such changes just for the hell of it... > >> >> You just need to write it in such a way that it is not confusing, then it is >> not >> a problem. > > there's really nothing confusing IMO (besides the button). but if you > insist i will send another patch with the changes you recommended. You said you would write it in a confusing way when adding an explicit note, so I suggest doing it in a not confusing manner ;) > > some possible alternative phrasing i'd suggest: > > = > After the change you have to **restart** `pveproxy` and `spiceproxy` for > it to take effect (**reload** or restart from GUI does not suffice): > systemctl restart pveproxy spiceproxy > = > > or much simpler and less confusing: > = > Run the following command to restart the proxy servers and apply the change: > systemctl restart pveproxy spiceproxy > = > > with a note about the connection drop during restart. > I applied the fixes, the notes and another small grammar style fix for the comma after "Similarly," myself, seemed to be the faster way to resolve this nicely.. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH storage 1/1] fix #1710: add retrieve method for storage
Users are now able to download/retrieve any .iso/... file onto their
storages and verify file integrity with checksums.
Signed-off-by: Lorenz Stechauner
---
PVE/API2/Storage/Status.pm | 244 +
1 file changed, 244 insertions(+)
diff --git a/PVE/API2/Storage/Status.pm b/PVE/API2/Storage/Status.pm
index 897b4a7..3919be7 100644
--- a/PVE/API2/Storage/Status.pm
+++ b/PVE/API2/Storage/Status.pm
@@ -5,6 +5,8 @@ use warnings;
use File::Path;
use File::Basename;
+use HTTP::Request;
+use LWP::UserAgent;
use PVE::Tools;
use PVE::INotify;
use PVE::Cluster;
@@ -497,4 +499,246 @@ __PACKAGE__->register_method ({
return $upid;
}});
+__PACKAGE__->register_method({
+name => 'retrieve',
+path => '{storage}/retrieve',
+method => 'POST',
+description => "Download templates and ISO images by using an URL.",
+permissions => {
+ check => ['perm', '/storage/{storage}', ['Datastore.AllocateTemplate']],
+},
+protected => 1,
+parameters => {
+ additionalProperties => 0,
+ properties => {
+ node => get_standard_option('pve-node'),
+ storage => get_standard_option('pve-storage-id'),
+ url => {
+ description => "The URL to retrieve the file from.",
+ type => 'string',
+ },
+ content => {
+ description => "Content type.",
+ type => 'string', format => 'pve-storage-content',
+ },
+ filename => {
+ description => "The name of the file to create. Alternatively
the file name given by the server will be used.",
+ type => 'string',
+ optional => 1,
+ },
+ checksum => {
+ description => "The expected checksum of the file.",
+ type => 'string',
+ optional => 1,
+ },
+ checksumalg => {
+ description => "The algorithm to claculate the checksum of the
file.",
+ type => 'string',
+ optional => 1,
+ },
+ metaonly => {
+ description => "Only return the file name and size.",
+ type => 'boolean',
+ optional => 1,
+ },
+ insecure => {
+ description => "Allow TLS certificates to be invalid.",
+ type => 'boolean',
+ optional => 1,
+ }
+ },
+},
+returns => {
+ type => "object",
+ properties => {
+ filename => { type => 'string' },
+ upid => { type => 'string' },
+ size => {
+ type => 'integer',
+ renderer => 'bytes',
+ },
+ },
+},
+code => sub {
+ my ($param) = @_;
+
+ my @hash_algs = ['md5', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512'];
+
+ my $rpcenv = PVE::RPCEnvironment::get();
+
+ my $user = $rpcenv->get_user();
+
+ my $cfg = PVE::Storage::config();
+
+ my $node = $param->{node};
+ my $scfg = PVE::Storage::storage_check_enabled($cfg, $param->{storage},
$node);
+
+ die "can't upload to storage type '$scfg->{type}'"
+ if !defined($scfg->{path});
+
+ my $content = $param->{content};
+
+ my $url = $param->{url};
+
+ die "invalid https or http url"
+ if $url !~ qr!^https?://!;
+
+ my $checksum = $param->{checksum};
+ my $hash_alg = $param->{checksumalg};
+
+ $hash_alg = undef
+ if $hash_alg eq 'none';
+
+ die "either 'checksum' and 'checksumalg' or none of these have to be
specified"
+ if ($checksum && !$hash_alg) || (!$checksum && $hash_alg);
+
+ die "unsupported checksumalg: '$hash_alg'"
+ if $hash_alg && ($hash_alg !~ /^(md5|sha1|sha(224|256|384|512))$/);
+
+ my $req = HTTP::Request->new(HEAD => $url);
+ my $ua = LWP::UserAgent->new();
+ my $res = $ua->request($req);
+
+ die "invalid server response: '" . $res->status_line() . "'"
+ if ($res->code() != 200);
+
+ my $size = $res->header("Content-Length");
+ my $dispo = $res->header("Content-Disposition");
+
+ my $filename_remote;
+
+ if ($dispo && $dispo =~ m/filename=(.+)/) {
+ $filename_remote = $1;
+ } elsif ($url =~ m!^[^?]+/([^?/]*)(?:\?.*)?$!) {
+ $filename_remote = $1;
+ }
+
+ chomp $filename_remote;
+ $filename_remote =~ s/^.*[\/\\]//;
+ $filename_remote =~ s/[^-a-zA-Z0-9_.]/_/g;
+
+ if ($param->{metaonly}) {
+ return {
+ filename => $filename_remote,
+ upid => 0,
+ size => $size + 0,
+ };
+ }
+
+ my $filename = $param->{filename} || $filename_remote;
+ chomp $filename;
+ $filename =~ s/^.*[\/\\]//;
+ $filename =~ s/[^-a-zA-Z0-9_.]/_/g;
+
+ my $path;
+
+ if ($content eq 'iso') {
+ if ($filen
[pve-devel] [PATCH widget-toolkit 1/1] window: add upidFieldName option
Signed-off-by: Lorenz Stechauner
---
src/window/Edit.js | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/window/Edit.js b/src/window/Edit.js
index 53d0e73..867ba9b 100644
--- a/src/window/Edit.js
+++ b/src/window/Edit.js
@@ -53,6 +53,10 @@ Ext.define('Proxmox.window.Edit', {
showTaskViewer: false,
+// name of the upid field in response data
+// required for showTaskViewer
+upidFieldName: undefined,
+
// gets called if we have a progress bar or taskview and it detected that
// the task finished. function(success)
taskDone: Ext.emptyFn,
@@ -165,9 +169,8 @@ Ext.define('Proxmox.window.Edit', {
Ext.Msg.alert(gettext('Error'), response.htmlStatus);
},
success: function(response, options) {
- let hasProgressBar =
- (me.backgroundDelay || me.showProgress ||
me.showTaskViewer) &&
- response.result.data;
+ let data = response.result.data;
+ let hasProgressBar = (me.backgroundDelay || me.showProgress ||
me.showTaskViewer) && data;
me.apiCallDone(true, response, options);
@@ -176,7 +179,7 @@ Ext.define('Proxmox.window.Edit', {
// when background action is completed
me.hide();
- let upid = response.result.data;
+ let upid = me.upidFieldName ? data[me.upidFieldName] : data;
let viewerClass = me.showTaskViewer ? 'Viewer' : 'Progress';
Ext.create('Proxmox.window.Task' + viewerClass, {
autoShow: true,
--
2.20.1
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager 1/1] fix #1710: add retrieve from url button for storage
Add PVE.storage.Retrieve window and PVE.form.hashAlgorithmSelector.
Users are now able to download/retrieve any .iso/... file onto their
storages and verify file integrity with checksums.
Signed-off-by: Lorenz Stechauner
---
www/manager6/Makefile | 1 +
www/manager6/form/HashAlgorithmSelector.js | 21 +++
www/manager6/storage/ContentView.js| 161 +
3 files changed, 183 insertions(+)
create mode 100644 www/manager6/form/HashAlgorithmSelector.js
diff --git a/www/manager6/Makefile b/www/manager6/Makefile
index afed3283..8e6557d8 100644
--- a/www/manager6/Makefile
+++ b/www/manager6/Makefile
@@ -38,6 +38,7 @@ JSSRC=
\
form/GlobalSearchField.js \
form/GroupSelector.js \
form/GuestIDSelector.js \
+ form/HashAlgorithmSelector.js \
form/HotplugFeatureSelector.js \
form/IPProtocolSelector.js \
form/IPRefSelector.js \
diff --git a/www/manager6/form/HashAlgorithmSelector.js
b/www/manager6/form/HashAlgorithmSelector.js
new file mode 100644
index ..4a72cc08
--- /dev/null
+++ b/www/manager6/form/HashAlgorithmSelector.js
@@ -0,0 +1,21 @@
+Ext.define('PVE.form.hashAlgorithmSelector', {
+extend: 'Proxmox.form.KVComboBox',
+alias: ['widget.pveHashAlgorithmSelector'],
+comboItems: [],
+hasNoneOption: false,
+initComponent: function() {
+ var me = this;
+ me.comboItems = [
+ ['md5', 'MD5'],
+ ['sha1', 'SHA-1'],
+ ['sha224', 'SHA-224'],
+ ['sha256', 'SHA-256'],
+ ['sha384', 'SHA-384'],
+ ['sha512', 'SHA-512'],
+ ];
+ if (me.hasNoneOption) {
+ me.comboItems.unshift(['none', 'None']);
+ }
+ this.callParent();
+},
+});
diff --git a/www/manager6/storage/ContentView.js
b/www/manager6/storage/ContentView.js
index dd6df4b1..7187ebbe 100644
--- a/www/manager6/storage/ContentView.js
+++ b/www/manager6/storage/ContentView.js
@@ -191,6 +191,153 @@ Ext.define('PVE.storage.Upload', {
},
});
+Ext.define('PVE.storage.Retrieve', {
+extend: 'Proxmox.window.Edit',
+alias: 'widget.pveStorageRetrieve',
+
+resizable: false,
+
+modal: true,
+
+isCreate: true,
+
+showTaskViewer: true,
+upidFieldName: 'upid',
+
+initComponent: function() {
+var me = this;
+
+ if (!me.nodename) {
+ throw "no node name specified";
+ }
+ if (!me.storage) {
+ throw "no storage ID specified";
+ }
+
+ me.url = `/nodes/${me.nodename}/storage/${me.storage}/retrieve`;
+ me.method = 'POST';
+
+ let defaultContent = me.contents[0] || '';
+
+ let urlField = Ext.create('Ext.form.field.Text', {
+ name: 'url',
+ allowBlank: false,
+ fieldLabel: gettext('URL'),
+ });
+
+ let fileNameField = Ext.create('Ext.form.field.Text', {
+ name: 'filename',
+ allowBlank: false,
+ fieldLabel: gettext('File name'),
+ });
+
+ let fileSizeField = Ext.create('Ext.form.field.Text', {
+ name: 'size',
+ disabled: true,
+ fieldLabel: gettext('File size'),
+ emptyText: gettext('unknown'),
+ });
+
+ let checksumField = Ext.create('Ext.form.field.Text', {
+ name: 'checksum',
+ fieldLabel: gettext('Checksum'),
+ allowBlank: true,
+ disabled: true,
+ emptyText: gettext('none'),
+ });
+
+ let checksumAlgField = Ext.create('PVE.form.hashAlgorithmSelector', {
+ name: 'checksumalg',
+ fieldLabel: gettext('Hash algorithm'),
+ allowBlank: true,
+ hasNoneOption: true,
+ value: 'none',
+ });
+
+ let inputPanel = Ext.create('Proxmox.panel.InputPanel', {
+ method: 'POST',
+ waitMsgTarget: true,
+ border: false,
+ columnT: [
+ urlField,
+ fileNameField,
+ ],
+ column1: [
+ {
+ xtype: 'pveContentTypeSelector',
+ cts: me.contents,
+ fieldLabel: gettext('Content'),
+ name: 'content',
+ value: defaultContent,
+ allowBlank: false,
+ },
+ ],
+ column2: [
+ fileSizeField,
+ ],
+ advancedColumn1: [
+ checksumField,
+ checksumAlgField,
+ ],
+ advancedColumn2: [
+ {
+ xtype: 'checkbox',
+ name: 'insecure',
+ fieldLabel: gettext('Trust invalid certificates'),
+ labelWidth: 150,
+ },
+
