Re: [pve-devel] LDAP integration with G Suite?
On 2/6/20 5:05 AM, Victor Hooi wrote: Hi, Just a quick update on this - is there any issues with having the cert and certkey point to files on /etc/pve (clustered config filesystem): hi, should not be a problem (we have the nodes api certificates/keys also there) but be aware that those files are readable by www-data if you would move them to /etc/pve/priv they would be readable by root only (not sure if www-data needs to read those) kind regards Dominik ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] LDAP integration with G Suite?
Hi, Just a quick update on this - is there any issues with having the cert and certkey point to files on /etc/pve (clustered config filesystem): ldap: anguslab.io > base_dn dc=anguslab,dc=io > server1 ldap.google.com > user_attr uid > cert /etc/pve/Google_2022_05_22_3494.crt > certkey /etc/pve/Google_2022_05_22_3494.key > port 636 > secure 1 > verify 1 Thanks, Victor On Mon, May 27, 2019 at 5:23 PM Dominik Csapak wrote: > > > > Also we do not have a bounty program (or similar), but if you > > can find something that is willing to implement it for you > > s/something/someone/ > > of course :) > > ___ > pve-devel mailing list > pve-devel@pve.proxmox.com > https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH widget-toolkit] add capitalized NoneText
On 2/5/20 11:59 AM, Dominik Csapak wrote:
> we want this in some cases
>
> Signed-off-by: Dominik Csapak
> ---
> Utils.js | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Utils.js b/Utils.js
> index e9dcd79..8f8c55f 100644
> --- a/Utils.js
> +++ b/Utils.js
> @@ -42,6 +42,7 @@ Ext.define('Proxmox.Utils', { utilities: {
> enabledText: gettext('Enabled'),
> disabledText: gettext('Disabled'),
> noneText: gettext('none'),
> +NoneText: gettext('None'),
> errorText: gettext('Error'),
> unknownText: gettext('Unknown'),
> defaultText: gettext('Default'),
>
applied, thanks!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH manager] gui: tree/SnapshotTree: fix gettext invocation
On 2/5/20 11:58 AM, Dominik Csapak wrote:
> our gettext extractor cannot handle such statements to extract the
> gettext, so change it to two gettexts
>
> Signed-off-by: Dominik Csapak
> ---
> www/manager6/tree/SnapshotTree.js | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/www/manager6/tree/SnapshotTree.js
> b/www/manager6/tree/SnapshotTree.js
> index e186bea7..0636ef68 100644
> --- a/www/manager6/tree/SnapshotTree.js
> +++ b/www/manager6/tree/SnapshotTree.js
> @@ -22,7 +22,7 @@ Ext.define('PVE.guest.SnapshotTree', {
> canRollback: (get) => get('rollbackAllowed') && get('isSnapshot'),
> canRemove: (get) => get('snapshotAllowed') && get('isSnapshot'),
> isSnapshot: (get) => get('selected') && get('selected') !==
> 'current',
> - buttonText: (get) => gettext(get('snapshotAllowed') ? 'Edit' :
> 'View'),
> + buttonText: (get) => get('snapshotAllowed') ? gettext('Edit') :
> gettext('View'),
> showMemory: (get) => get('type') === 'qemu',
> },
> },
>
applied, thanks!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH firewall] logging: Add missing logmsg for inbound rules
On 1/28/20 5:57 PM, Christian Ebner wrote:
> Signed-off-by: Christian Ebner
> ---
> src/PVE/Firewall.pm | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm
> index 255bb9a..d22b15a 100644
> --- a/src/PVE/Firewall.pm
> +++ b/src/PVE/Firewall.pm
> @@ -2491,6 +2491,7 @@ sub enable_host_firewall {
> $rule->{iface_in} = $rule->{iface} if $rule->{iface};
>
> eval {
> + $rule->{logmsg} = "$rule->{action}: ";
> if ($rule->{type} eq 'group') {
> ruleset_add_group_rule($ruleset, $cluster_conf, $chain, $rule,
> 'IN', $accept_action, $ipversion);
> } elsif ($rule->{type} eq 'in') {
>
applied, thanks!
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs] network: add note for possible fix/workaround in NAT setup
On Wed, 5 Feb 2020 15:57:13 +0100 Oguz Bektas wrote: > apparently sometimes users have problems reaching outside internet with > some network setups. this is the workaround a user suggested that > we should add in the wiki. Thanks for the initiative - that does come up indeed every now and then in our various support channels (and it usually takes me quite a while to find the trustworthy forum-post by Alexandre (Thanks!!), which I quote on that ;) As an optional suggestion: I would try to add some more rationale, as to why users should put those iptables rules in their firewall - (maybe: due to the way packets are processed in the processed by netfilter and the rules created by pve-firewall?) - Also the following could be worth linking in the docs (or mentioning in the commit-message): [0] https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg [1] https://lwn.net/Articles/370152/ (patch from 2010 on netdev-list introducing the conntrack zones) [2] https://blog.lobraun.de/2019/05/19/prox/ (a blog post with a good explanation, by using the TRACE target in the raw table) [3] https://forum.proxmox.com/threads/firewall-stops-vm-ct-communication-also-have-to-reboot-to-fix.59811/#post-275921 (the forum post I usually quote on those issues) > > Signed-off-by: Oguz Bektas > --- > pve-network.adoc | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/pve-network.adoc b/pve-network.adoc > index c61cd42..471edb4 100644 > --- a/pve-network.adoc > +++ b/pve-network.adoc > @@ -248,6 +248,15 @@ iface vmbr0 inet static > post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 > -j MASQUERADE > > > +NOTE: If you have firewall enabled for your CT/VM and you're having > +connectivity problems with outgoing connections, you can add the following > +lines in the interfaces config: > + > + > +post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1 > +post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1 > + > + > > Linux Bond > ~~ ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server] fix efidisks on storages with minimum sizes bigger than OVMF_VARS.fd
on storages where the minimum size of images is bigger than the real
OVMF_VARS.fd file, they get padded to their minimum size
when using such an image, qemu maps it fully to the vm, but the efi
does not find the vars region and creates a file on the first efi
partition it finds
this breaks some settings in the ovmf, such as resolution
to fix this, we have to specify the size for the pflash, so that
qemu only maps the first n bytes in the vm (this only works for
raw files, not for qcow2)
we also have to use the correct size when converting between storages
in 'clone_disk' (used for move disk and cloning vms) and when
live migrating to different storages
when we now expect that the source image is always correctly used/created
(e.g. raw with size=x in pflash argument) then we always create the
target correctly
when encountering users which have a non-valid image (e.g. a efidisk
moved from zfs to qcow2 before this patch), we have to tell them to
recreate the efidisk and the settings on it
for all this to work, we have to bump the pve machine version
(and adapt the tests)
Signed-off-by: Dominik Csapak
---
PVE/API2/Qemu.pm | 4 +-
PVE/QemuMigrate.pm| 6 +++
PVE/QemuServer.pm | 43 +--
PVE/QemuServer/Machine.pm | 2 +-
test/cfg2cmd/i440fx-win10-hostpci.conf.cmd| 2 +-
test/cfg2cmd/minimal-defaults.conf.cmd| 2 +-
.../q35-linux-hostpci-multifunction.conf.cmd | 2 +-
test/cfg2cmd/q35-linux-hostpci.conf.cmd | 2 +-
test/cfg2cmd/q35-win10-hostpci.conf.cmd | 2 +-
test/cfg2cmd/spice-linux-4.1.conf.cmd | 2 +-
10 files changed, 55 insertions(+), 12 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index d0dd2dc..bf5bb16 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -2908,7 +2908,7 @@ __PACKAGE__->register_method({
my $newdrive = PVE::QemuServer::clone_disk($storecfg,
$vmid, $running, $opt, $drive, $snapname,
$newid,
$storage, $format, $fullclone->{$opt}, $newvollist,
- $jobs,
$skipcomplete, $oldconf->{agent}, $clonelimit);
+ $jobs,
$skipcomplete, $oldconf->{agent}, $clonelimit, $oldconf);
$newconf->{$opt} =
PVE::QemuServer::print_drive($newdrive);
@@ -3095,7 +3095,7 @@ __PACKAGE__->register_method({
my $movelimit = PVE::Storage::get_bandwidth_limit('move',
[$oldstoreid, $storeid], $bwlimit);
my $newdrive = PVE::QemuServer::clone_disk($storecfg,
$vmid, $running, $disk, $drive, undef,
- $vmid, $storeid,
$format, 1, $newvollist, undef, undef, undef, $movelimit);
+ $vmid, $storeid,
$format, 1, $newvollist, undef, undef, undef, $movelimit, $conf);
$conf->{$disk} = PVE::QemuServer::print_drive($newdrive);
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 1f6e306..4914a1c 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -454,6 +454,12 @@ sub sync_disks {
}
});
+ # we want to set the efidisk size in the config to the size of the
+ # real OVMF_VARS.fd image, else we can create a too big image, which
does not work
+ if (defined($conf->{efidisk0})) {
+ PVE::QemuServer::update_efidisk_size($conf);
+ }
+
$self->log('info', "copying local disk images") if
scalar(%$local_volumes);
foreach my $volid (keys %$local_volumes) {
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 214140c..3aef95c 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -3520,8 +3520,14 @@ sub config_to_command {
$format = 'raw';
}
+ my $size_str = "";
+
+ if (min_version($machine_version, 4, 1, 2) && $format eq 'raw') {
+ $size_str = ",size=" . (-s $ovmf_vars);
+ }
+
push @$cmd, '-drive',
"if=pflash,unit=0,format=raw,readonly,file=$ovmf_code";
- push @$cmd, '-drive',
"if=pflash,unit=1,format=$format,id=drive-efidisk0,file=$path";
+ push @$cmd, '-drive',
"if=pflash,unit=1,format=$format,id=drive-efidisk0$size_str,file=$path";
}
# load q35 config
@@ -6987,7 +6993,7 @@ sub qemu_blockjobs_cancel {
sub clone_disk {
my ($storecfg, $vmid, $running, $drivename, $drive, $snapname,
- $newvmid, $storage, $format, $full, $newvollist, $jobs, $skipcomplete,
$qga, $bwlimit) = @_;
+ $newvmid, $storage, $format, $full, $newvollist, $jobs, $skipcomplete,
$qga, $bwlimit, $conf) = @_;
my $newvolid;
@@ -7010,6 +7016,8 @@ sub clone_disk {
$name .= ".$dst_format" if $dst_format ne 'raw';
$snapname = undef;
[pve-devel] [PATCH docs] network: add note for possible fix/workaround in NAT setup
apparently sometimes users have problems reaching outside internet with some network setups. this is the workaround a user suggested that we should add in the wiki. Signed-off-by: Oguz Bektas --- pve-network.adoc | 9 + 1 file changed, 9 insertions(+) diff --git a/pve-network.adoc b/pve-network.adoc index c61cd42..471edb4 100644 --- a/pve-network.adoc +++ b/pve-network.adoc @@ -248,6 +248,15 @@ iface vmbr0 inet static post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE +NOTE: If you have firewall enabled for your CT/VM and you're having +connectivity problems with outgoing connections, you can add the following +lines in the interfaces config: + + +post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1 +post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1 + + Linux Bond ~~ -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 docs 07/10] Overhaul Sysadmin
improve phrasing
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
v1 -> v2:
applied suggestions from oguz [0]
[0] https://pve.proxmox.com/pipermail/pve-devel/2019-September/038966.html
sysadmin.adoc | 38 ++
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/sysadmin.adoc b/sysadmin.adoc
index e045610..86b61f0 100644
--- a/sysadmin.adoc
+++ b/sysadmin.adoc
@@ -5,31 +5,21 @@ ifndef::manvolnum[]
:pve-toplevel:
endif::manvolnum[]
-{pve} is based on the famous https://www.debian.org/[Debian] Linux
-distribution. That means that you have access to the whole world of
-Debian packages, and the base system is well documented. The
+The following sections will focus on common virtualization tasks and explain
the
+{pve} specifics regarding the administration and management of the host
machine.
+
+{pve} is based on https://www.debian.org/[Debian GNU/Linux] with additional
+repositories to provide the {pve} related packages. This means that the full
+range of Debian packages is available including security updates and bug fixes.
+{pve} provides it's own Linux kernel based on the Ubuntu kernel. It has all the
+necessary virtualization and container features enabled and includes
+https://zfsonlinux.org[ZFS] and several extra hardware drivers.
+
+For other topics not included in the following sections, please refer to the
+Debian documentation. The
https://debian-handbook.info/download/stable/debian-handbook.pdf[Debian
-Administrator\'s Handbook] is available online, and provides a
-comprehensive introduction to the Debian operating system (see
-xref:Hertzog13[]).
-
-A standard {pve} installation uses the default repositories from
-Debian, so you get bug fixes and security updates through that
-channel. In addition, we provide our own package repository to roll
-out all {pve} related packages. This includes updates to some
-Debian packages when necessary.
-
-We also deliver a specially optimized Linux kernel, where we enable all
-required virtualization and container features. That kernel includes
-drivers for http://zfsonlinux.org/[ZFS], and several hardware drivers.
-For example, we ship Intel network card drivers to support their
-newest hardware.
-
-The following sections will concentrate on virtualization related
-topics. They either explain things which are different on {pve}, or
-tasks which are commonly used on {pve}. For other topics, please refer
-to the standard Debian documentation.
-
+Administrator\'s Handbook] is available online, and provides a comprehensive
+introduction to the Debian operating system (see xref:Hertzog13[]).
ifdef::wiki[]
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 docs 04/10] Overhaul Installation
improve phrasing, align style of CLI commands
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
v1 -> v2:
applied suggestions from oguz [0]
[0] https://pve.proxmox.com/pipermail/pve-devel/2019-September/038964.html
pve-installation.adoc | 260 --
1 file changed, 125 insertions(+), 135 deletions(-)
diff --git a/pve-installation.adoc b/pve-installation.adoc
index 18cd9af..2ac47b2 100644
--- a/pve-installation.adoc
+++ b/pve-installation.adoc
@@ -1,5 +1,5 @@
-Installing Proxmox VE
-=
+Installing {pve}
+
ifndef::manvolnum[]
:pve-toplevel:
endif::manvolnum[]
@@ -7,19 +7,19 @@ ifdef::wiki[]
:title: Installation
endif::wiki[]
-{pve} is based on Debian, therefore the disk image (ISO file) provided
-by us includes a complete Debian system ("buster" for version 6.x) as
-well as all necessary {pve} packages.
+{pve} is based on Debian. This is why the install disk images (ISO files)
+provided by Proxmox include a complete Debian system (Debian 10 "buster" for
+{pve} version 6.x) as well as all necessary {pve} packages.
-Using the installer will guide you through the setup, allowing
-you to partition the local disk(s), apply basic system configurations
-(e.g. timezone, language, network) and install all required packages.
-Using the provided ISO will get you started in just a few minutes,
-that's why we recommend this method for new and existing users.
+The installer will guide through the setup, allowing you to partition the local
+disk(s), apply basic system configurations (e.g. timezone, language, network)
+and install all required packages. This process should not take more than a few
+minutes. Installing with the provided ISO is the recommended method for new and
+existing users.
-Alternatively, {pve} can be installed on top of an existing Debian
-system. This option is only recommended for advanced users since
-detailed knowledge about {pve} is necessary.
+Alternatively, {pve} can be installed on top of an existing Debian system. This
+option is only recommended for advanced users because detailed knowledge about
+{pve} is required.
ifndef::wiki[]
@@ -31,103 +31,102 @@ endif::wiki[]
Using the {pve} Installer
-
-You can download the ISO from {website}en/downloads.
-It includes the following:
+Download the installer ISO at {website}en/downloads. It includes the following:
* Complete operating system (Debian Linux, 64-bit)
* The {pve} installer, which partitions the local disk(s) with ext4,
ext3, xfs or ZFS and installs the operating system.
-* {pve} kernel (Linux) with LXC and KVM support
+* {pve} kernel (Linux) with KVM and LXC support
* Complete toolset for administering virtual machines, containers and
all necessary resources
-* Web based management interface for using the toolset
+* Web-based management interface
-NOTE: During the installation process, the complete server
-is used by default and all existing data is removed.
+NOTE: All existing data on the server will be removed during the installation
+process.
-Please insert the installation media (e.g. USB stick, CD-ROM) and boot
+Please insert the installation media (e.g. USB flash drive, CD-ROM) and boot
from it.
[thumbnail="screenshot/pve-grub-menu.png"]
-After choosing the correct entry (e.g. Boot from USB) the {pve} menu
-will be displayed, you can now select one of the following options:
+After choosing the correct entry (e.g. Boot from USB) the {pve} menu will be
+displayed and one of the following options can be selected:
-Install Proxmox VE::
+Install {pve}::
-Start normal installation.
+Starts the normal installation.
-TIP: It is possible to only use the keyboard to progress through the
-installation wizard. Buttons can be pressed by pressing down the `ALT`
-key, combined with the underlined character from the respective Button.
-For example, `ALT + N` to press a `Next` button.
+TIP: It's possible to use the installation wizard with a keyboard only. Buttons
+can be clicked by pressing the `ALT` key combined with the underlined character
+from the respective button. For example, `ALT + N` to press a `Next` button.
-Install Proxmox VE (Debug mode)::
+Install {pve} (Debug mode)::
-Start installation in debug mode. It opens a shell console at several
-installation steps, so that you can debug things if something goes
-wrong. Please press `CTRL-D` to exit those debug consoles and continue
-installation. This option is mostly for developers and not meant for
-general use.
+Starts the installation in debug mode. A console will be opened at several
+installation steps. This helps to debug the situation if something goes wrong.
+To exit a debug console, press `CTRL-D`. This options is primarily for
+developers and not intended for general use.
Rescue Boot::
-This option allows you to boot an existing installation. It searches
-all attached hard disks and, if it finds
[pve-devel] [PATCH v3 docs 10/10] Fix whitespace and line length
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
getting-help.adoc| 9 -
howto-improve-pve-docs.adoc | 4 ++--
pve-installation.adoc| 14 +++---
pve-package-repos.adoc | 11 +--
pve-system-requirements.adoc | 4 ++--
sysadmin.adoc| 2 +-
6 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/getting-help.adoc b/getting-help.adoc
index 8e81483..9f561c7 100644
--- a/getting-help.adoc
+++ b/getting-help.adoc
@@ -27,15 +27,14 @@ Mailing Lists
This is a fast way to communicate with the {pve} community via email.
* Mailing list for users:
- http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user[PVE User
- List]
+ http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user[PVE User List]
{pve} is fully open source and contributions are welcome! The primary
communication channel for developers is the:
-* Mailing list for developer:
- http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel[PVE
- development discussion]
+* Mailing list for developers:
+ http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel[PVE development
+ discussion]
Commercial Support
diff --git a/howto-improve-pve-docs.adoc b/howto-improve-pve-docs.adoc
index d96bb03..940e050 100644
--- a/howto-improve-pve-docs.adoc
+++ b/howto-improve-pve-docs.adoc
@@ -28,5 +28,5 @@ right option to contribute.
document.
NOTE: If you are interested in working on the {pve} codebase, the
-{webwiki-url}Developer_Documentation[Developer Documentation] wiki
-article will show you where to start.
+{webwiki-url}Developer_Documentation[Developer Documentation] wiki article will
+show you where to start.
diff --git a/pve-installation.adoc b/pve-installation.adoc
index 2ac47b2..2eb7cd6 100644
--- a/pve-installation.adoc
+++ b/pve-installation.adoc
@@ -35,13 +35,13 @@ Download the installer ISO at {website}en/downloads. It
includes the following:
* Complete operating system (Debian Linux, 64-bit)
-* The {pve} installer, which partitions the local disk(s) with ext4,
- ext3, xfs or ZFS and installs the operating system.
+* The {pve} installer, which partitions the local disk(s) with ext4, ext3, xfs
+ or ZFS and installs the operating system.
* {pve} kernel (Linux) with KVM and LXC support
-* Complete toolset for administering virtual machines, containers and
- all necessary resources
+* Complete toolset for administering virtual machines, containers, and all
+ necessary resources
* Web-based management interface
@@ -175,9 +175,9 @@ VG on the same hard disk that can be used for LVM storage).
`swapsize`::
-Defines the size of the `swap` volume. The default is the size of the
-installed memory, minimum 4 GB and maximum 8 GB. The resulting value cannot
-be greater than `hdsize/8`.
+Defines the size of the `swap` volume. The default is the size of the installed
+memory, minimum 4 GB and maximum 8 GB. The resulting value cannot be greater
+than `hdsize/8`.
+
NOTE: If set to `0`, no `swap` volume will be created.
diff --git a/pve-package-repos.adoc b/pve-package-repos.adoc
index e11f8ec..b7e7674 100644
--- a/pve-package-repos.adoc
+++ b/pve-package-repos.adoc
@@ -32,10 +32,9 @@ deb http://security.debian.org/debian-security
buster/updates main contrib
{pve} Enterprise Repository
~~~
-This is the default, stable and recommended repository, available for
-all {pve} subscription users. It contains the most stable packages,
-and is suitable for production use. The `pve-enterprise` repository is
-enabled by default:
+This is the default, stable, and recommended repository, available for all
{pve}
+subscription users. It contains the most stable packages and is suitable for
+production use. The `pve-enterprise` repository is enabled by default:
.File `/etc/apt/sources.list.d/pve-enterprise.list`
@@ -277,8 +276,8 @@ deb http://security.debian.org/ squeeze/updates main contrib
Outdated: {pve} VE 1.x Repositories
~~~
-{pve} 1.x is based on Debian 5.0 (``lenny'') and very outdated. Please
-upgrade to latest version as soon as possible.
+{pve} 1.x is based on Debian 5.0 (``lenny'') and very outdated. Please upgrade
+to latest version as soon as possible.
endif::wiki[]
diff --git a/pve-system-requirements.adoc b/pve-system-requirements.adoc
index 63f8a37..4703092 100644
--- a/pve-system-requirements.adoc
+++ b/pve-system-requirements.adoc
@@ -62,8 +62,8 @@ Simple performance overview
To get an overview of the CPU and hard disk performance on an installed {pve}
system, run the included `pveperf` tool.
-NOTE: this is just a very quick and general benchmark. More detailed tests
-are recommended, especially regarding the I/O performance of your system.
+NOTE: this is just a very quick and general benchmark. More detailed tests are
+recommended, especially regarding the I/O performance of your system.
Supported web browsers for accessing the web
[pve-devel] [PATCH v3 docs 02/10] Overhaul How To Improve Docs
general overhauling, improve phrasing
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
v1 -> v2:
applied suggestion from oguz [0]
[0] https://pve.proxmox.com/pipermail/pve-devel/2019-September/038952.html
howto-improve-pve-docs.adoc | 38 +
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/howto-improve-pve-docs.adoc b/howto-improve-pve-docs.adoc
index c0d277e..d96bb03 100644
--- a/howto-improve-pve-docs.adoc
+++ b/howto-improve-pve-docs.adoc
@@ -5,31 +5,27 @@ ifdef::wiki[]
:pve-toplevel:
endif::wiki[]
-Depending on which issue you want to improve, you can use a variety of
-communication mediums to reach the developers.
+Contributions and improvements to the {pve} documentation are always welcome.
+There are several ways to contribute.
-If you notice an error in the current documentation, use the
-http://bugzilla.proxmox.com[Proxmox bug tracker] and propose an
-alternate text/wording.
+If you find errors or other room for improvement in this documentation, please
+file a bug at the https://bugzilla.proxmox.com/[Proxmox bug tracker] to propose
+a correction.
-If you want to propose new content, it depends on what you want to
-document:
+If you want to propose new content, choose one of the following options:
-* if the content is specific to your setup, a wiki article is the best
-option. For instance if you want to document specific options for guest
-systems, like which combination of Qemu drivers work best with a less popular
-OS, this is a perfect fit for a wiki article.
+* The wiki: For specific setups, how-to guides, or tutorials the wiki is the
+right option to contribute.
-* if you think the content is generic enough to be of interest for all users,
-then you should try to get it into the reference documentation. The reference
-documentation is written in the easy to use 'asciidoc' document format.
-Editing the official documentation requires to clone the git repository at
-`git://git.proxmox.com/git/pve-docs.git` and then follow the
-https://git.proxmox.com/?p=pve-docs.git;a=blob_plain;f=README.adoc;hb=HEAD[README.adoc]
document.
-
-Improving the documentation is just as easy as editing a Wikipedia
-article and is an interesting foray in the development of a large
-opensource project.
+* The reference documentation: For general content that will be helpful to
all
+ users please propose your contribution for the reference documentation.
This
+ includes all information about how to install, configure, use, and
+ troubleshoot {pve} features. The reference documentation is written in the
+ https://en.wikipedia.org/wiki/AsciiDoc[asciidoc format]. To edit the
+ documentation you need to clone the git repository at
+ `git://git.proxmox.com/git/pve-docs.git`; then follow the
+
https://git.proxmox.com/?p=pve-docs.git;a=blob_plain;f=README.adoc;hb=HEAD[README.adoc]
+ document.
NOTE: If you are interested in working on the {pve} codebase, the
{webwiki-url}Developer_Documentation[Developer Documentation] wiki
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 docs 08/10] Overhaul Package Repositories
improve phrasing, align style of CLI commands
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
pve-package-repos.adoc | 143 +
1 file changed, 74 insertions(+), 69 deletions(-)
diff --git a/pve-package-repos.adoc b/pve-package-repos.adoc
index 078de95..e11f8ec 100644
--- a/pve-package-repos.adoc
+++ b/pve-package-repos.adoc
@@ -5,18 +5,16 @@ ifdef::wiki[]
:pve-toplevel:
endif::wiki[]
-All Debian based systems use
-http://en.wikipedia.org/wiki/Advanced_Packaging_Tool[APT] as package
-management tool. The list of repositories is defined in
-`/etc/apt/sources.list` and `.list` files found inside
-`/etc/apt/sources.d/`. Updates can be installed directly using
-`apt-get`, or via the GUI.
-
-Apt `sources.list` files list one package repository per line, with
-the most preferred source listed first. Empty lines are ignored, and a
-`#` character anywhere on a line marks the remainder of that line as a
-comment. The information available from the configured sources is
-acquired by `apt-get update`.
+{pve} uses http://en.wikipedia.org/wiki/Advanced_Packaging_Tool[APT] as package
+management tool like any other Debian-based system. Repositories are defined in
+the file `/etc/apt/sources.list` and in `.list` files placed in
+`/etc/apt/sources.list.d/`.
+
+Each line defines a package repository. The preferred source must come first.
+Empty lines are ignored. A `#` character anywhere on a line marks the remainder
+of that line as a comment. The available packages from a repository are
acquired
+by running `apt-get update`. Updates can be installed directly using `apt-get`,
+or via the GUI.
.File `/etc/apt/sources.list`
@@ -28,7 +26,7 @@ deb http://security.debian.org/debian-security buster/updates
main contrib
// FIXME for 7.0: change security update suite to bullseye-security
-In addition, {pve} provides three different package repositories.
+{pve} additionally provides three different package repositories.
[[sysadmin_enterprise_repo]]
{pve} Enterprise Repository
@@ -44,29 +42,25 @@ enabled by default:
deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
-As soon as updates are available, the `root@pam` user is notified via
-email about the available new packages. On the GUI, the change-log of
-each package can be viewed (if available), showing all details of the
-update. So you will never miss important security fixes.
-
-Please note that you need a valid subscription key to access this
-repository. We offer different support levels, and you can find further
-details at https://www.proxmox.com/en/proxmox-ve/pricing.
+The `root@pam` user is notified via email about available updates. Click the
+'Changelog' button in the GUI to see more details about the selected update.
-NOTE: You can disable this repository by commenting out the above line
-using a `#` (at the start of the line). This prevents error messages
-if you do not have a subscription key. Please configure the
-`pve-no-subscription` repository in that case.
+You need a valid subscription key to access the `pve-enterprise` repository.
+Different support levels are available. Further details can be found at
+https://www.proxmox.com/en/proxmox-ve/pricing.
+NOTE: You can disable this repository by commenting out the above line using a
+`#` (at the start of the line). This prevents error messages if you do not have
+a subscription key. Please configure the `pve-no-subscription` repository in
+that case.
[[sysadmin_no_subscription_repo]]
{pve} No-Subscription Repository
-As the name suggests, you do not need a subscription key to access
-this repository. It can be used for testing and non-production
-use. Its not recommended to run on production servers, as these
-packages are not always heavily tested and validated.
+This is the recommended repository for testing and non-production use. The
+packages are not headily tested and validated. You don't need a subscription
key
+to access the `pve-no-subscription` repository.
We recommend to configure this repository in `/etc/apt/sources.list`.
@@ -88,26 +82,25 @@ deb http://security.debian.org/debian-security
buster/updates main contrib
{pve} Test Repository
~~
-Finally, there is a repository called `pvetest`. This one contains the
-latest packages and is heavily used by developers to test new
-features. As usual, you can configure this using
-`/etc/apt/sources.list` by adding the following line:
+This repository contains the latest packages and is primarily used by
developers
+to test new features. To configure it, add the following line to
+`etc/apt/sources.list`:
.sources.list entry for `pvetest`
deb http://download.proxmox.com/debian/pve buster pvetest
-WARNING: the `pvetest` repository should (as the name implies) only be used
-for testing new features or bug fixes.
+WARNING: The `pvetest` repository should
[pve-devel] [PATCH v3 docs 09/10] OVerhaul System Software Updates
improve phrasing, align style of CLI commands
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
v1 -> v2:
applied suggestions from oguz [0]
[0] https://pve.proxmox.com/pipermail/pve-devel/2019-September/038965.html
system-software-updates.adoc | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/system-software-updates.adoc b/system-software-updates.adoc
index 04c17f3..013e171 100644
--- a/system-software-updates.adoc
+++ b/system-software-updates.adoc
@@ -4,21 +4,16 @@ ifdef::wiki[]
:pve-toplevel:
endif::wiki[]
-We provide regular package updates on all repositories. You can
-install those update using the GUI, or you can directly run the CLI
-command `apt-get`:
+Proxmox provides updates on a regular basis for all repositories. To install
+updates use the web-based GUI or the following CLI commands:
- apt-get update
- apt-get dist-upgrade
+
+# apt-get update
+# apt-get dist-upgrade
+
-NOTE: The `apt` package management system is extremely flexible and
-provides countless of feature - see `man apt-get` or <> for
-additional information.
+NOTE: The APT package management system is very flexible and provides many
+features, see `man apt-get`, or <> for additional information.
-You should do such updates at regular intervals, or when we release
-versions with security related fixes. Major system upgrades are
-announced at the {forum}. Those announcement also contain detailed
-upgrade instructions.
-
-TIP: We recommend to run regular upgrades, because it is important to
-get the latest security updates.
+TIP: Regular updates are essential to get the latest patches and security
+related fixes. Major system upgrades are announced in the {forum}.
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 docs 05/10] Overhaul System Requirements
improve phrasing, align headlines, rearrange requirement lists
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
v1 -> v2:
applied (some) suggestions from oguz [0], IO performance is based on the
whole system, not just disks
[0] https://pve.proxmox.com/pipermail/pve-devel/2019-September/038953.html
pve-system-requirements.adoc | 65 +++-
1 file changed, 34 insertions(+), 31 deletions(-)
diff --git a/pve-system-requirements.adoc b/pve-system-requirements.adoc
index 0a4ba6c..63f8a37 100644
--- a/pve-system-requirements.adoc
+++ b/pve-system-requirements.adoc
@@ -4,22 +4,23 @@ ifdef::wiki[]
:pve-toplevel:
endif::wiki[]
-For production servers, high quality server equipment is needed. Keep
-in mind, if you run 10 Virtual Servers on one machine and you then
-experience a hardware failure, 10 services are lost. {pve}
-supports clustering, this means that multiple {pve} installations
-can be centrally managed thanks to the included cluster functionality.
+We recommend to use high quality server hardware when running {pve} in
+production. To further decrease the impact of a failed host you can run {pve}
in
+a cluster with highly available (HA) virtual machines and containers.
-{pve} can use local storage (DAS), SAN, NAS and also distributed
-storage (Ceph RBD). For details see xref:chapter_storage[chapter storage].
+{pve} can use local storage (DAS), SAN, NAS, and distributed storage like Ceph
+RBD. For details see xref:chapter_storage[chapter storage].
[[install_minimal_requirements]]
Minimum Requirements, for Evaluation
+These minimum requirements are for evaluation purposes only and should not be
+used in production.
+
* CPU: 64bit (Intel EMT64 or AMD64)
-* Intel VT/AMD-V capable CPU/Mainboard for KVM Full Virtualization support
+* Intel VT/AMD-V capable CPU/Mainboard for KVM full virtualization support
* RAM: 1 GB RAM, plus additional RAM used for guests
@@ -34,44 +35,46 @@ Recommended System Requirements
* Intel EMT64 or AMD64 with Intel VT/AMD-V CPU flag.
-* Memory, minimum 2 GB for OS and Proxmox VE services. Plus designated memory
- for guests. For Ceph or ZFS additional memory is required, approximately 1 GB
- memory for every TB used storage.
+* Memory, minimum 2 GB for the OS and {pve} services. Plus designated memory
for
+ guests. For Ceph and ZFS additional memory is required; approximately 1GB of
+ memory for every TB of used storage.
-* Fast and redundant storage, best results with SSD disks.
+* Fast and redundant storage, best results are achieved with SSDs.
-* OS storage: Hardware RAID with batteries protected write cache (``BBU'') or
- non-RAID with ZFS and SSD cache.
+* OS storage: Use a hardware RAID with battery protected write cache (``BBU'')
+ or non-RAID with ZFS and SSD cache.
-* VM storage: For local storage use a hardware RAID with battery backed
- write cache (BBU) or non-RAID for ZFS. Neither ZFS nor Ceph are compatible
- with a hardware RAID controller. Shared and distributed storage is also
- possible.
+* VM storage:
+** For local storage use either a hardware RAID with battery backed write cache
+ (BBU) or non-RAID for ZFS and Ceph. Neither ZFS nor Ceph are compatible with
a
+ hardware RAID controller.
+** Shared and distributed storage is possible.
* Redundant Gbit NICs, additional NICs depending on the preferred storage
- technology and cluster setup – 10 Gbit and higher is also supported.
+ technology and cluster setup (10 Gbit and higher) are supported.
-* For PCI passthrough a CPU with VT-d/AMD-d CPU flag is needed.
+* For PCI(e) passthrough the CPU needs to support the VT-d/AMD-d flag.
-Simple Performance Overview
+Simple performance overview
~~~
-On an installed {pve} system, you can run the included `pveperf` script
-to obtain an overview of the CPU and hard disk performance.
+To get an overview of the CPU and hard disk performance on an installed {pve}
+system, run the included `pveperf` tool.
NOTE: this is just a very quick and general benchmark. More detailed tests
are recommended, especially regarding the I/O performance of your system.
Supported web browsers for accessing the web interface
~~
-To use the web interface you need a modern browser, this includes:
-* Firefox, a release from the current year, or the latest Extended
-Support Release
-* Chrome, a release from the current year
-* Microsofts currently supported version of Edge
-* Safari, a release from the current year
+To access the web-based user interface one of the following browsers is
+recommended:
+
+* Firefox, a release of the current year, or the latest Extended Support
Release
+* Chrome, a release of the current year
+* Microsoft's currently supported version of Edge
+* Safari, a release of the current year
-If {pve} detects you're connecting from a mobile
[pve-devel] [PATCH v3 docs 06/10] Overhaul Install from USB flash drive
improve phrasing, align style of CLI commands, OSX is now macOS, Rufus
with dd mode is preferred to etcher
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
pve-usbstick.adoc | 109 +++---
1 file changed, 54 insertions(+), 55 deletions(-)
diff --git a/pve-usbstick.adoc b/pve-usbstick.adoc
index 5eb9132..3d4860f 100644
--- a/pve-usbstick.adoc
+++ b/pve-usbstick.adoc
@@ -1,121 +1,120 @@
-Install from USB Stick
---
+Install from a USB flash drive
+--
ifdef::wiki[]
:pve-toplevel:
endif::wiki[]
-The {pve} installation media is a hybrid ISO image, working in two ways:
+The {pve} installation media is a hybrid ISO image. It works in two ways:
-* An ISO image file ready to burn on CD
+* An ISO image file ready to burn to a CD or DVD.
-* A raw sector (IMG) image file ready to directly copy to flash media
- (USB Stick)
+* A raw sector (IMG) image file ready to copy to a USB flash drive (USB stick).
-Using USB sticks is faster and more environmental friendly and
-therefore the recommended way to install {pve}.
+Using a USB flash drive to install {pve} is the recommended way because it is
+the faster option.
+Prepare a USB flash drive as installation medium
+
-Prepare a USB flash drive as install medium
-~~~
-
-In order to boot the installation media, copy the ISO image to a USB
-media.
-
-First download the ISO image from
+Download the installer ISO image from:
https://www.proxmox.com/en/downloads/category/iso-images-pve
-You need at least a 1 GB USB media.
+The flash drive needs to have at least 1GB of storage available.
-NOTE: Using UNetbootin or Rufus does not work.
+NOTE: Do not use UNetbootin. It does not work with the {pve} installation
image.
-IMPORTANT: Make sure that the USB media is not mounted and does not
+IMPORTANT: Make sure that the USB flash drive is not mounted and does not
contain any important data.
Instructions for GNU/Linux
~~
-You can simply use `dd` on UNIX like systems. First download the ISO
-image, then plug in the USB stick. You need to find out what device
-name gets assigned to the USB stick (see below). Then run:
+On Unix-like operating system use the `dd` command to copy the ISO image to the
+USB flash drive. First find the correct device name of the USB flash drive (see
+below). Then run the `dd` command.
-dd if=proxmox-ve_*.iso of=/dev/XYZ bs=1M
+# dd if=proxmox-ve_*.iso of=/dev/XYZ bs=1M
NOTE: Be sure to replace /dev/XYZ with the correct device name.
-CAUTION: Be very careful, and do not overwrite the hard disk!
+CAUTION: Be very careful, and do not overwrite the wrong disk!
-Find Correct USB Device Name
-
-
-You can compare the last lines of 'dmesg' command before and after the
-insertion, or use the 'lsblk' command. Open a terminal and run:
+Find the correct USB device name
+
+There are two ways to find out the name of the USB flash drive. The first one
is
+to compare the last lines of the `dmesg` command output before and after
+plugging in the flash drive. The second way is to compare the output of the
+`lsblk` command. Open a terminal and run:
- lsblk
+# lsblk
-Then plug in your USB media and run the command again:
+Then plug in your USB flash drive and run the command again:
- lsblk
+# lsblk
-A new device will appear, and this is the USB device you want to use.
+A new device will appear. This is the one you want to use. To be on the extra
+safe side check if the reported size matches your USB flash drive.
-Instructions for OSX
-
+Instructions for macOS
+~~
Open the terminal (query Terminal in Spotlight).
-Convert the .iso file to .img using the convert option of hdiutil for example.
+Convert the .iso file to .img using the convert option of `hdiutil` for
example.
-hdiutil convert -format UDRW -o proxmox-ve_*.dmg proxmox-ve_*.iso
+# hdiutil convert -format UDRW -o proxmox-ve_*.dmg proxmox-ve_*.iso
-TIP: OS X tends to put the .dmg ending on the output file automatically.
+TIP: macOS tends to automatically add '.dmg' to the output file name.
-To get the current list of devices run the command again:
+To get the current list of devices run the command:
-diskutil list
+# diskutil list
-Now insert your USB flash media and run this command again to
-determine the device node assigned to your flash media
-(e.g. /dev/diskX).
+Now insert the USB flash drive and run this command again to determine which
+device node has been assigned to it. (e.g., /dev/diskX).
-diskutil list
-
-diskutil unmountDisk /dev/diskX
+# diskutil list
+# diskutil unmountDisk /dev/diskX
NOTE: replace X with the disk number from the last command.
[pve-devel] [PATCH v3 docs 00/10] Documenation overhaul chapt. 1.9 to 3.2
This is the first patch series aimed to overhaul our documentation. The main goal is to make it easier to understand and more consistent. Therefore the phrasing is changed in a lot of places, sometimes the ordering of content as well. I tried to align the source to the 80 characters per line wherever possible. The reason why this first patch series doesn't start at the very beginning is because we are not yet happy with few things there. v2 -> v3: rebased on current master v1[0] -> v2: * incorporating suggestions received * moved line length and white space fixes to separate patch [0] https://pve.proxmox.com/pipermail/pve-devel/2019-September/038938.html Aaron Lauterer (10): Overhaul Getting Help Overhaul How To Improve Docs Overhaul Translation Overhaul Installation Overhaul System Requirements Overhaul Install from USB flash drive Overhaul Sysadmin Overhaul Package Repositories OVerhaul System Software Updates Fix whitespace and line length getting-help.adoc| 47 +++--- howto-improve-pve-docs.adoc | 42 +++--- pve-installation.adoc| 274 +-- pve-package-repos.adoc | 154 ++-- pve-system-requirements.adoc | 69 - pve-usbstick.adoc| 109 +++--- sysadmin.adoc| 40 ++--- system-software-updates.adoc | 25 ++-- translation.adoc | 37 ++--- 9 files changed, 388 insertions(+), 409 deletions(-) -- 2.20.1 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 docs 01/10] Overhaul Getting Help
general overhaul of the documentation, improving phrasing, move open
source info
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
v1 -> v2:
feedback from thomas[0]:
* moved open source hint to mailing list for devs
* added suggestions
* regarding spaces around dashes (--): our current technical writing
style guide says to not use any
[0] https://pve.proxmox.com/pipermail/pve-devel/2019-September/038950.html
getting-help.adoc | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/getting-help.adoc b/getting-help.adoc
index 850d7a3..8e81483 100644
--- a/getting-help.adoc
+++ b/getting-help.adoc
@@ -16,23 +16,22 @@ documentation with user contributed content.
Community Support Forum
~~~
-{pve} itself is fully open source, so we always encourage our users to
-discuss and share their knowledge using the {forum}. The forum is fully
-moderated by the Proxmox support team, and has a quite large user base
-around the whole world. Needless to say that such a large forum is a
+We always encourage our users to discuss and share their knowledge using the
+{forum}. The forum is moderated by the Proxmox support team. The large user
base
+is spread out all over the world. Needless to say that such a large forum is a
great place to get information.
Mailing Lists
~
-This is a fast way to communicate via email with the Proxmox VE
-community
+This is a fast way to communicate with the {pve} community via email.
* Mailing list for users:
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user[PVE User
List]
-The primary communication channel for developers is:
+{pve} is fully open source and contributions are welcome! The primary
+communication channel for developers is the:
* Mailing list for developer:
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel[PVE
@@ -42,19 +41,22 @@ The primary communication channel for developers is:
Commercial Support
~~
-{proxmoxGmbh} also offers commercial
-https://www.proxmox.com/en/proxmox-ve/pricing[{pve} Subscription Service
-Plans]. System Administrators with a standard subscription plan can access a
-dedicated support portal with guaranteed response time, where {pve}
-developers help them should an issue appear.
-Please contact the mailto:off...@proxmox.com[Proxmox sales
-team] for more information or volume discounts.
+{proxmoxGmbh} also offers enterprise support available as
+https://www.proxmox.com/en/proxmox-ve/pricing[{pve} Subscription Service
Plans].
+All users with a subscription get access to the {pve}
+<>, and--with a Basic, Standard
+or Premium subscription--also to the Proxmox Customer Portal. The customer
+portal provides help and support with guaranteed response times from the {pve}
+developers.
+
+For volume discounts, or more information in general, please contact
+mailto:off...@proxmox.com[off...@proxmox.com].
Bug Tracker
~~~
-We also run a public bug tracker at
-https://bugzilla.proxmox.com. If you ever detect an issue, you can
-file a bug report there. This makes it easy to track its status, and
-you will get notified as soon as the problem is fixed.
+Proxmox runs a public bug tracker at https://bugzilla.proxmox.com. If an issue
+appears, file your report there. An issue can be a bug as well as a request for
+a new feature or enhancement. The bug tracker helps to keep track of the issue
+and will send a notification once it has been solved.
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 docs 03/10] Overhaul Translation
improve phrasing
Signed-off-by: Aaron Lauterer
---
v2 -> v3:
rebased on current master
v1 -> v2:
applied suggestion from oguz [0]
[0] https://pve.proxmox.com/pipermail/pve-devel/2019-September/038952.html
translation.adoc | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/translation.adoc b/translation.adoc
index ff99296..cf627f1 100644
--- a/translation.adoc
+++ b/translation.adoc
@@ -6,24 +6,25 @@ ifdef::wiki[]
endif::wiki[]
-A lot of users speak a language other than English and we depend on
contributions
-to make {pve} available to users all over the world.
-We are always happy to welcome new localizers and invite you to help shape
-{pve}.
+The {pve} user interface is in English by default. Thanks to contributions by
+the community, translations to other languages are available. We welcome help
to
+add new languages, translate the newest features, and improve incomplete or
+inconsistent translations.
-Our language files are available as
https://git.proxmox.com/?p=proxmox-i18n.git[git repository].
-If you are familiar with git we would be glad to see your contribution
according
-to our {webwiki-url}Developer_Documentation[Developer Documentation].
+The language files are available as a
+https://git.proxmox.com/?p=proxmox-i18n.git[git repository]. If you are
familiar
+with git, please contribute according to our
+{webwiki-url}Developer_Documentation[Developer Documentation].
-Nonetheless, translating does not require special technical skills.
-You can get the language files without setting up a development environment
-https://git.proxmox.com/?p=proxmox-i18n.git;a=tree[here].
-Right click on the "raw" link of your language and choose "Save Link As...".
-Do not hesitate to send your translation directly to office(at)proxmox.com with
-your signed
{webwiki-url}Developer_Documentation#Software_License_and_Copyright[contributor
license agreement].
+Even if you are not familiar with git, you can help with translating {pve}.
+Download the language files
+https://git.proxmox.com/?p=proxmox-i18n.git;a=tree[here]. Then choose the
+language you want to improve. Right click on the "raw" link of this language
+file, and select 'Save Link As…'. Make your changes to the file, and then
+send your final translation directly to office(at)proxmox.com together with a
+signed
+{webwiki-url}Developer_Documentation#Software_License_and_Copyright[contributor
license agreement].
-We use https://www.gnu.org/software/gettext/[gettext] to translate {pve}.
-As a result, the actual translation task is to write a translation of the
-`msgid` into the `msgstr` below it.
-Tools like https://poedit.net/[Poedit] make this process more convenient,
-especially for contributors who are not programmers.
+We use https://www.gnu.org/software/gettext/[gettext] for the management of the
+translation files. Tools like https://poedit.net/[Poedit] offer a nice user
+interface to edit the translation files.
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-guest-common 1/1] vzdump: added "includename" option
On Thu, Nov 14, 2019 at 03:01:37PM +0100, Thomas Lamprecht wrote: > On 11/14/19 6:30 AM, Dietmar Maurer wrote: > >> The main reason for this is to identify backups residing on an old backup > >> store like an archive. > >> > >> But I am open. Would you prefer having a manifest included in the archive > >> or as a separate file on the same storage? > > > > The backup archive already contains the full VM config. I thought the > > manifest should be > > an extra file on the same storage. > > > > An idea for the backup note/description feature request is to have > a simple per backup file where that info is saved, having the same > base name as the backup archive and the log, so those can easily get > moved/copied around all at once by using an extension glob for the > file ending. > > Simple manifest works too, needs to always have the cluster storage > lock though, whereas a per backup file could do with a vmid based one > (finer granularity avoids lock contention). Also it makes it less easier > to copy a whole archive to another storage/folder. If I didn't miss an email, then this feature request (#438 [0]) seems to be still open (I'm the assignee). In which direction should this feature go? Per backup manifest? Or maybe extending the vzdump CLI with an info command that displays some information, parsed from the backup logfile itself. Since the VM/CT name is already in the log. Would that be a possibility too? Example form a backup logfiles: ``` 2020-02-04 15:58:55 INFO: VM Name: testvm 2020-01-13 15:39:35 INFO: CT Name: test ``` [0] https://bugzilla.proxmox.com/show_bug.cgi?id=438 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH container] apply_pending: call cleanup_pending between change/delete loops
instead of calling it while iterating, inbetween the loops is a better
place in terms of similarity with qemu side (also this should fix the bug that
dominik found[0])
[0]: https://pve.proxmox.com/pipermail/pve-devel/2020-February/041573.html
Signed-off-by: Oguz Bektas
---
src/PVE/LXC/Config.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/PVE/LXC/Config.pm b/src/PVE/LXC/Config.pm
index 310aba6..e88ba0b 100644
--- a/src/PVE/LXC/Config.pm
+++ b/src/PVE/LXC/Config.pm
@@ -1268,7 +1268,6 @@ sub vmconfig_apply_pending {
# FIXME: $force deletion is not implemented for CTs
foreach my $opt (sort keys %$pending_delete_hash) {
next if $selection && !$selection->{$opt};
- $class->cleanup_pending($conf);
eval {
if ($opt =~ m/^mp(\d+)$/) {
my $mp = $class->parse_ct_mountpoint($conf->{$opt});
@@ -1289,6 +1288,8 @@ sub vmconfig_apply_pending {
}
}
+$class->cleanup_pending($conf);
+
foreach my $opt (sort keys %{$conf->{pending}}) { # add/change
next if $opt eq 'delete'; # just to be sure
next if $selection && !$selection->{$opt};
@@ -1304,7 +1305,6 @@ sub vmconfig_apply_pending {
if (my $err = $@) {
$add_apply_error->($opt, $err);
} else {
- $class->cleanup_pending($conf);
$conf->{$opt} = delete $conf->{pending}->{$opt};
}
}
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC PATCH container] fix setting same netX value several times
On 2/5/20 12:20 PM, Fabian Grünbichler wrote:
On February 5, 2020 9:29 am, Dominik Csapak wrote:
when setting a netX option that is semantically the same as the
one already set but in a different order, e.g.:
in config:
net0: name=eth0,bridge=vmbr0,hwaddr=AA:AA:AA:AA:AA:AA,type=veth
setting via api:
net0: bridge=vmbr0,name=eth0,hwaddr=AA:AA:AA:AA:AA:AA,type=veth
the code tries to 'hot-apply' the change (which is no change really)
where the api line then gets parsed and printed which results
in the same string already in the config
then we do a 'cleanup_pending' which removes it from pending, since
the config already contains the exact same options, but
then we overwrite the config from pending (which is empty)
resulting in an invalid config line:
--8<--
net0:
-->8--
to prevent this, we only overwrite the config here when
there is still an option in in $conf->{pending}->{$opt}, meaning
there was a meaningful change
Signed-off-by: Dominik Csapak
---
i am not really sure if this is the correct place to fix this, because
i think we never should trigger apply_pending when the requested
config is semantically identical to what is already in the config,
but i did not really see when or how to do that in a good and generic way
(should be parse/print all property strings at the beginning?)
so sending it as an rfc
I think the right way to do it is like in QemuServer.pm - don't cleanup
pending while iterating over it, but before/after iteration.
sounds right, but i am not really versed in that code,
@Oguz can you maybe take a look again at this?
(since i think you worked on this last?)
if not i can do it, but i guess it would take me longer
src/PVE/LXC/Config.pm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/PVE/LXC/Config.pm b/src/PVE/LXC/Config.pm
index 310aba6..49b9f70 100644
--- a/src/PVE/LXC/Config.pm
+++ b/src/PVE/LXC/Config.pm
@@ -1305,7 +1305,10 @@ sub vmconfig_apply_pending {
$add_apply_error->($opt, $err);
} else {
$class->cleanup_pending($conf);
- $conf->{$opt} = delete $conf->{pending}->{$opt};
+ # $conf->{pending}->{$opt} is now empty if we have the same
+ # value already in config, so do not overwrite the value in config
+ $conf->{$opt} = delete $conf->{pending}->{$opt}
+ if defined($conf->{pending}->{$opt});
}
}
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC PATCH container] fix setting same netX value several times
On February 5, 2020 9:29 am, Dominik Csapak wrote:
> when setting a netX option that is semantically the same as the
> one already set but in a different order, e.g.:
>
> in config:
> net0: name=eth0,bridge=vmbr0,hwaddr=AA:AA:AA:AA:AA:AA,type=veth
> setting via api:
> net0: bridge=vmbr0,name=eth0,hwaddr=AA:AA:AA:AA:AA:AA,type=veth
>
> the code tries to 'hot-apply' the change (which is no change really)
> where the api line then gets parsed and printed which results
> in the same string already in the config
>
> then we do a 'cleanup_pending' which removes it from pending, since
> the config already contains the exact same options, but
> then we overwrite the config from pending (which is empty)
> resulting in an invalid config line:
> --8<--
> net0:
> -->8--
>
> to prevent this, we only overwrite the config here when
> there is still an option in in $conf->{pending}->{$opt}, meaning
> there was a meaningful change
>
> Signed-off-by: Dominik Csapak
> ---
> i am not really sure if this is the correct place to fix this, because
> i think we never should trigger apply_pending when the requested
> config is semantically identical to what is already in the config,
> but i did not really see when or how to do that in a good and generic way
> (should be parse/print all property strings at the beginning?)
> so sending it as an rfc
I think the right way to do it is like in QemuServer.pm - don't cleanup
pending while iterating over it, but before/after iteration.
> src/PVE/LXC/Config.pm | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/PVE/LXC/Config.pm b/src/PVE/LXC/Config.pm
> index 310aba6..49b9f70 100644
> --- a/src/PVE/LXC/Config.pm
> +++ b/src/PVE/LXC/Config.pm
> @@ -1305,7 +1305,10 @@ sub vmconfig_apply_pending {
> $add_apply_error->($opt, $err);
> } else {
> $class->cleanup_pending($conf);
> - $conf->{$opt} = delete $conf->{pending}->{$opt};
> + # $conf->{pending}->{$opt} is now empty if we have the same
> + # value already in config, so do not overwrite the value in config
> + $conf->{$opt} = delete $conf->{pending}->{$opt}
> + if defined($conf->{pending}->{$opt});
> }
> }
>
> --
> 2.20.1
>
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager v2 1/2] gui: lxc/Network: add a virtual 'none' option
sometimes, if users do not want a ipv4/6 address, they set the network mode
to 'dhcp' instead of 'static' (with no ip set), in believe
this will result in no ip
in reality, often no ipv6 dhcp server exists in the environment, and
the container start stalls for ~5min trying to get a ipv6
to improve ux, add the option 'none', which functionally is the same
as having selected 'static' with no ip set, and simultaniously
make the ip required
Signed-off-by: Dominik Csapak
---
changes from v1:
* make 'static' default for new nics (e.g. in the wizard)
* rename none4/6 to noIPv4/6Addr
* remove unnecessary comments
* use NoneText (this requires a new widget-toolkit with my other patch
applied)
www/manager6/lxc/Network.js | 63 -
1 file changed, 42 insertions(+), 21 deletions(-)
diff --git a/www/manager6/lxc/Network.js b/www/manager6/lxc/Network.js
index be40a8fa..bfa61180 100644
--- a/www/manager6/lxc/Network.js
+++ b/www/manager6/lxc/Network.js
@@ -36,10 +36,10 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
var newdata = {};
- if (values.ipv6mode !== 'static') {
+ if (values.ipv6mode !== 'static' && values.ipv6mode !== 'none') {
values.ip6 = values.ipv6mode;
}
- if (values.ipv4mode !== 'static') {
+ if (values.ipv4mode !== 'static' && values.ipv4mode !== 'none') {
values.ip = values.ipv4mode;
}
newdata[id] = PVE.Parser.printLxcNetwork(values);
@@ -161,6 +161,7 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
cdata.ip = '';
cdata.gw = '';
}
+ var noIPv4Addr = (!cdata.ip && !cdata.gw && !dhcp4);
var auto6 = (cdata.ip6 === 'auto');
var dhcp6 = (cdata.ip6 === 'dhcp');
@@ -168,26 +169,36 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
cdata.ip6 = '';
cdata.gw6 = '';
}
-
+
+ var noIPv6Addr = (!cdata.ip6 && !cdata.gw6 && !auto6 && !dhcp6);
+
me.column2 = [
+ {
+ xtype: 'label',
+ text: 'IPv4:',
+ },
{
layout: {
type: 'hbox',
align: 'middle'
},
border: false,
- margin: '0 0 5 0',
+ margin: '5 0 5 0',
items: [
{
- xtype: 'label',
- text: 'IPv4:' // do not localize
+ xtype: 'radiofield',
+ boxLabel: Proxmox.Utils.NoneText,
+ name: 'ipv4mode',
+ inputValue: 'none',
+ checked: !me.isCreate && noIPv4Addr,
+ margin: '0 0 0 10',
},
{
xtype: 'radiofield',
boxLabel: gettext('Static'),
name: 'ipv4mode',
inputValue: 'static',
- checked: !dhcp4,
+ checked: me.isCreate || !(dhcp4 || noIPv4Addr),
margin: '0 0 0 10',
listeners: {
change: function(cb, value) {
@@ -198,7 +209,7 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
},
{
xtype: 'radiofield',
- boxLabel: 'DHCP', // do not localize
+ boxLabel: 'DHCP',
name: 'ipv4mode',
inputValue: 'dhcp',
checked: dhcp4,
@@ -211,22 +222,27 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
name: 'ip',
vtype: 'IPCIDRAddress',
value: cdata.ip,
- disabled: dhcp4,
- fieldLabel: 'IPv4/CIDR' // do not localize
+ allowBlank: false,
+ disabled: !me.isCreate && (dhcp4 || noIPv4Addr),
+ fieldLabel: 'IPv4/CIDR',
},
{
xtype: 'textfield',
name: 'gw',
value: cdata.gw,
vtype: 'IPAddress',
- disabled: dhcp4,
+ disabled: dhcp4 || noIPv4Addr,
fieldLabel: gettext('Gateway') + ' (IPv4)',
margin: '0 0 3 0' // override bottom margin to account for the
menuseparator
},
{
xtype: 'menuseparator',
height: '3',
- margin: '0'
+ margin: '0 0 5 0',
+ },
+ {
+ xtype: 'label',
+ text: 'IPv6:',
},
{
layout: {
@@ -234,18 +250,22 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
align: 'middle'
},
border: false,
- margin: '0 0 5 0',
+ margin: '5 0 5 0',
items: [
{
-
[pve-devel] [PATCH manager v2 2/2] gui: lxc/Network: remove trailing whitespace
Signed-off-by: Dominik Csapak
---
new in v2
www/manager6/lxc/Network.js | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/www/manager6/lxc/Network.js b/www/manager6/lxc/Network.js
index bfa61180..7610f598 100644
--- a/www/manager6/lxc/Network.js
+++ b/www/manager6/lxc/Network.js
@@ -8,7 +8,7 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
setNodename: function(nodename) {
var me = this;
-
+
if (!nodename || (me.nodename === nodename)) {
return;
}
@@ -18,7 +18,7 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
var bridgesel = me.query("[isFormField][name=bridge]")[0];
bridgesel.setNodename(nodename);
},
-
+
onGetValues: function(values) {
var me = this;
@@ -314,7 +314,6 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
me.callParent();
}
});
-
Ext.define('PVE.lxc.NetworkEdit', {
extend: 'Proxmox.window.Edit',
@@ -338,7 +337,7 @@ Ext.define('PVE.lxc.NetworkEdit', {
dataCache: me.dataCache,
isCreate: me.isCreate
});
-
+
Ext.apply(me, {
subject: gettext('Network Device') + ' (veth)',
digest: me.dataCache.digest,
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager] gui: tree/SnapshotTree: fix gettext invocation
our gettext extractor cannot handle such statements to extract the
gettext, so change it to two gettexts
Signed-off-by: Dominik Csapak
---
www/manager6/tree/SnapshotTree.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/www/manager6/tree/SnapshotTree.js
b/www/manager6/tree/SnapshotTree.js
index e186bea7..0636ef68 100644
--- a/www/manager6/tree/SnapshotTree.js
+++ b/www/manager6/tree/SnapshotTree.js
@@ -22,7 +22,7 @@ Ext.define('PVE.guest.SnapshotTree', {
canRollback: (get) => get('rollbackAllowed') && get('isSnapshot'),
canRemove: (get) => get('snapshotAllowed') && get('isSnapshot'),
isSnapshot: (get) => get('selected') && get('selected') !==
'current',
- buttonText: (get) => gettext(get('snapshotAllowed') ? 'Edit' :
'View'),
+ buttonText: (get) => get('snapshotAllowed') ? gettext('Edit') :
gettext('View'),
showMemory: (get) => get('type') === 'qemu',
},
},
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH widget-toolkit] add capitalized NoneText
we want this in some cases
Signed-off-by: Dominik Csapak
---
Utils.js | 1 +
1 file changed, 1 insertion(+)
diff --git a/Utils.js b/Utils.js
index e9dcd79..8f8c55f 100644
--- a/Utils.js
+++ b/Utils.js
@@ -42,6 +42,7 @@ Ext.define('Proxmox.Utils', { utilities: {
enabledText: gettext('Enabled'),
disabledText: gettext('Disabled'),
noneText: gettext('none'),
+NoneText: gettext('None'),
errorText: gettext('Error'),
unknownText: gettext('Unknown'),
defaultText: gettext('Default'),
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC storage 6/16] pvesm import: allow specifying storage+vmid instead of full volumeid
On January 29, 2020 2:30 pm, Fabian Ebner wrote:
> Extends the API so that 'volume' can also only be a storage identifier. In
> that case the VMID needs to be specified as well. In 'import_volume' a new
> name for the allocation is determined. This is useful for migration where
> the storage on the target is a different type, since the volume ID might
> look differently. E.g. 'mydir:102/vm-102-disk-0.raw' on a 'dir'
> storage would be 'mylvm:vm-102-disk-0' on an 'lvm' storage.
>
> Signed-off-by: Fabian Ebner
> ---
>
> An alternative approach would be to translate the volids as mentioned
> in the cover letter.
as just discussed off-list, I'd rather add a new optional parameter
"allow-rename" instead of $vmid. volume could stay the same then, and if
allow-rename is true and a volume of the requested name already exists,
volume_import finds a new name using the VMID contained in $volume.
this would also allow us to opt-into the new behaviour more explicitly,
and not-yet-updated third-party plugins should remain compatible (of
course only with regards to the old behaviour ;))
>
> It's not a pretty interface, but to not break backwards compatibility
> the 'volume' parameter needs to be non-optional (or is there a way to get
> around this?) and so it is a hybrid of either full ID or only storage ID.
>
> PVE/CLI/pvesm.pm | 30 +++
> PVE/Storage.pm | 6 ++
> PVE/Storage/LVMPlugin.pm | 28 --
> PVE/Storage/Plugin.pm| 39 ++--
> PVE/Storage/ZFSPoolPlugin.pm | 32 -
> 5 files changed, 91 insertions(+), 44 deletions(-)
>
> diff --git a/PVE/CLI/pvesm.pm b/PVE/CLI/pvesm.pm
> index 74294b4..d91bc31 100755
> --- a/PVE/CLI/pvesm.pm
> +++ b/PVE/CLI/pvesm.pm
> @@ -261,7 +261,9 @@ __PACKAGE__->register_method ({
> additionalProperties => 0,
> properties => {
> volume => {
> - description => "Volume identifier",
> + description => "Either a complete volume identifier of the form
> " .
> + "'storage:volume_name' or just the name of a storage. In the
> " .
> + "latter case the parameter vmid is required.",
> type => 'string',
> completion => \::Storage::complete_volume,
> },
> @@ -297,6 +299,11 @@ __PACKAGE__->register_method ({
> maxLength => 80,
> optional => 1,
> },
> + vmid => get_standard_option('pve-vmid', {
> + description => "Only needed when no volume name is specified.",
> + optional => 1,
> + completion => \::Cluster::complete_vmid,
> + }),
> },
> },
> returns => { type => 'string' },
> @@ -350,10 +357,25 @@ __PACKAGE__->register_method ({
> }
>
> my $cfg = PVE::Storage::config();
> - my $volume = $param->{volume};
> + my $storeid_or_volid = $param->{volume};
> + my $vmid = $param->{vmid};
> +
> + my ($storeid, $volname) =
> PVE::Storage::parse_volume_id($storeid_or_volid, 1);
> + if (!defined($volname) || !defined($storeid)) { # assume it's only a
> storeid
> + $storeid = PVE::JSONSchema::parse_storage_id($storeid_or_volid);
> + $volname = undef;
> + die "vmid needs to be specified if there is no volume name\n"
> + if !defined($vmid);
> + }
> +
> + if (defined($vmid) && defined($volname)) {
> + warn "ignoring parameter vmid='$vmid' since a volume name was
> specified\n";
> + $vmid = undef;
> + }
> +
> my $delete = $param->{'delete-snapshot'};
> - my $volid = PVE::Storage::volume_import($cfg, $infh, $volume,
> $param->{format},
> - $param->{base}, $param->{'with-snapshots'});
> + my $volid = PVE::Storage::volume_import($cfg, $infh, $storeid, $volname,
> + $param->{format}, $param->{base}, $param->{'with-snapshots'},
> $vmid);
> PVE::Storage::volume_snapshot_delete($cfg, $volid, $delete)
> if defined($delete);
> return $volid;
> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
> index 57d723d..7d18b11 100755
> --- a/PVE/Storage.pm
> +++ b/PVE/Storage.pm
> @@ -1420,14 +1420,12 @@ sub volume_export {
> }
>
> sub volume_import {
> -my ($cfg, $fh, $volid, $format, $base_snapshot, $with_snapshots) = @_;
> +my ($cfg, $fh, $storeid, $volname, $format, $base_snapshot,
> $with_snapshots, $vmid) = @_;
>
> -my ($storeid, $volname) = parse_volume_id($volid, 1);
> -die "cannot import into volume '$volid'\n" if !$storeid;
> my $scfg = storage_config($cfg, $storeid);
> my $plugin = PVE::Storage::Plugin->lookup($scfg->{type});
> return $plugin->volume_import($scfg, $storeid, $fh, $volname, $format,
> - $base_snapshot, $with_snapshots);
> + $base_snapshot, $with_snapshots, $vmid);
> }
>
> sub
Re: [pve-devel] [RFC storage 3/16] volume_import: Use a new name when the the name to import with already exists
On January 29, 2020 2:30 pm, Fabian Ebner wrote:
> The ID of the new volume is returned and pvesm import prints it. This is
> useful for migration, since the storage on the target might already contain
> unused/orphaned disks.
this is dangerous, and should be explicitly requested. (see patch #6)
as-is, this can lead to a repeated "allocate and fully replicate into
new volume" cycle when replication meets an orphaned disk with clashing
volid.
>
> Signed-off-by: Fabian Ebner
> ---
>
> Breaks the current migration in QEMU/LXC if there is a collision,
> since the code doesn't die anymore and the config is not updated
> with the new name, i.e. needs patches 1,5,12 and 13.
>
> PVE/CLI/pvesm.pm | 13 -
> PVE/Storage/LVMPlugin.pm | 14 +-
> PVE/Storage/Plugin.pm| 12
> PVE/Storage/ZFSPoolPlugin.pm | 10 ++
> 4 files changed, 31 insertions(+), 18 deletions(-)
>
> diff --git a/PVE/CLI/pvesm.pm b/PVE/CLI/pvesm.pm
> index 510faba..7d8547b 100755
> --- a/PVE/CLI/pvesm.pm
> +++ b/PVE/CLI/pvesm.pm
> @@ -299,7 +299,7 @@ __PACKAGE__->register_method ({
> },
> },
> },
> -returns => { type => 'null' },
> +returns => { type => 'string' },
> code => sub {
> my ($param) = @_;
>
> @@ -352,11 +352,11 @@ __PACKAGE__->register_method ({
> my $cfg = PVE::Storage::config();
> my $volume = $param->{volume};
> my $delete = $param->{'delete-snapshot'};
> - PVE::Storage::volume_import($cfg, $infh, $volume, $param->{format},
> + my $volid = PVE::Storage::volume_import($cfg, $infh, $volume,
> $param->{format},
> $param->{base}, $param->{'with-snapshots'});
> - PVE::Storage::volume_snapshot_delete($cfg, $volume, $delete)
> + PVE::Storage::volume_snapshot_delete($cfg, $volid, $delete)
> if defined($delete);
> - return;
> + return $volid;
> }
> });
>
> @@ -777,7 +777,10 @@ our $cmddef = {
> path => [ __PACKAGE__, 'path', ['volume']],
> extractconfig => [__PACKAGE__, 'extractconfig', ['volume']],
> export => [ __PACKAGE__, 'export', ['volume', 'format', 'filename']],
> -import => [ __PACKAGE__, 'import', ['volume', 'format', 'filename']],
> +import => [ __PACKAGE__, 'import', ['volume', 'format', 'filename'], {},
> sub {
> + my $volid = shift;
> + print "successfully imported '$volid'\n";
> +}],
> };
>
> 1;
> diff --git a/PVE/Storage/LVMPlugin.pm b/PVE/Storage/LVMPlugin.pm
> index f02c110..6c575f2 100644
> --- a/PVE/Storage/LVMPlugin.pm
> +++ b/PVE/Storage/LVMPlugin.pm
> @@ -638,17 +638,20 @@ sub volume_import {
>
> my $vg = $scfg->{vgname};
> my $lvs = lvm_list_volumes($vg);
> -die "volume $vg/$volname already exists\n"
> - if $lvs->{$vg}->{$volname};
> +
> +if ($lvs->{$vg}->{$volname}) {
> + warn "volume $vg/$volname already exists - importing with a different
> name\n";
> + $name = undef;
> +}
>
> my ($size) = PVE::Storage::Plugin::read_common_header($fh);
> $size = int($size/1024);
>
> eval {
> my $allocname = $class->alloc_image($storeid, $scfg, $vmid, 'raw',
> $name, $size);
> - if ($allocname ne $volname) {
> - my $oldname = $volname;
> - $volname = $allocname; # Let the cleanup code know what to free
> + my $oldname = $volname;
> + $volname = $allocname;
> + if (defined($name) && $allocname ne $oldname) {
> die "internal error: unexpected allocated name: '$allocname' !=
> '$oldname'\n";
> }
> my $file = $class->path($scfg, $volname, $storeid)
> @@ -661,6 +664,7 @@ sub volume_import {
> warn $@ if $@;
> die $err;
> }
> +return "$storeid:$volname";
> }
>
> sub volume_import_write {
> diff --git a/PVE/Storage/Plugin.pm b/PVE/Storage/Plugin.pm
> index 0c39cbd..358a831 100644
> --- a/PVE/Storage/Plugin.pm
> +++ b/PVE/Storage/Plugin.pm
> @@ -1198,16 +1198,19 @@ sub volume_import {
> # Check for an existing file first since interrupting alloc_image doesn't
> # free it.
> my $file = $class->path($scfg, $volname, $storeid);
> -die "file '$file' already exists\n" if -e $file;
> +if (-e $file) {
> + warn "file '$file' already exists - importing with a different name\n";
> + $name = undef;
> +}
>
> my ($size) = read_common_header($fh);
> $size = int($size/1024);
>
> eval {
> my $allocname = $class->alloc_image($storeid, $scfg, $vmid,
> $file_format, $name, $size);
> - if ($allocname ne $volname) {
> - my $oldname = $volname;
> - $volname = $allocname; # Let the cleanup code know what to free
> + my $oldname = $volname;
> + $volname = $allocname;
> + if (defined($name) && $allocname ne $oldname) {
> die "internal error: unexpected allocated name: '$allocname' !=
> '$oldname'\n";
> }
> my $file = $class->path($scfg, $volname, $storeid)
> @@ -1227,6 +1230,7 @@ sub
[pve-devel] applied: [PATCH apiclient] implement api token support
Am 1/30/20 um 12:07 PM schrieb Fabian Grünbichler: > and add an example for it. > > Signed-off-by: Fabian Grünbichler > --- > PVE/APIClient/LWP.pm | 22 -- > examples/example3.pl | 24 > 2 files changed, 44 insertions(+), 2 deletions(-) > create mode 100755 examples/example3.pl applied, thanks! > +use PVE::APIClient::LWP; > + > +use JSON; > + > +my $apitoken = 'PVEAPIToken=USER@REALM!TOKENID=TOKENVALUE'; it could make sense to add that ourself for convenience, i.e., if the token does not matches /^PVEAPIToken[ =]/ ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager] gui: lxc/Network: add a virtual 'none' option
Am 2/5/20 um 10:52 AM schrieb Dominik Csapak: >>> +boxLabel: Proxmox.Utils.noneText, >> >> noneText is not capitalized, stands out in a ugly way. > > mhmm.. do we want to add a new gettext for this? Proxmox.Utils.NoneText ? ^^ > we use that already in some contexts where it could be capitalized... > Yes, I've seen this "nuisance" also here and there, but also did not want to double all those gettexts with need to. > is there a good way to capitalize this automatically? > (with regards to all languages) Thinking of the corner cases of languages I'd guess no.. :/ There's some information loss by switching case in certain Languages.. So maybe really add a NoneText and use that, and hope that there are not to many such cases.. ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager] gui: lxc/Network: add a virtual 'none' option
On 2/5/20 10:13 AM, Thomas Lamprecht wrote:
Am 2/5/20 um 9:37 AM schrieb Dominik Csapak:
sometimes, if users do not want a ipv4/6 address, they set the network mode
to 'dhcp' instead of 'static' (with no ip set), in believe
this will result in no ip
in reality, often no ipv6 dhcp server exists in the environment, and
the container start stalls for ~5min trying to get a ipv6
to improve ux, add the option 'none', which functionally is the same
as having selected 'static' with no ip set, and simultaniously
make the ip required
Signed-off-by: Dominik Csapak
---
this panel is a good candidate for a rewrite using viemodel/controller,
but this change is small and the gains of a rewrite not big enough,
so i left it as is for now, but if someone wants to get some extjs experience,
this could be a good exercise
The basic idea is OK, but do not make none the new default! CTs normally do
want a network, our main use case is system CTs after all, no network no fun
yes this makes sense of course...
www/manager6/lxc/Network.js | 51 ++---
1 file changed, 36 insertions(+), 15 deletions(-)
diff --git a/www/manager6/lxc/Network.js b/www/manager6/lxc/Network.js
index be40a8fa..4afcd09b 100644
--- a/www/manager6/lxc/Network.js
+++ b/www/manager6/lxc/Network.js
@@ -36,10 +36,10 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
var newdata = {};
- if (values.ipv6mode !== 'static') {
+ if (values.ipv6mode !== 'static' && values.ipv6mode !== 'none') {
values.ip6 = values.ipv6mode;
}
- if (values.ipv4mode !== 'static') {
+ if (values.ipv4mode !== 'static' && values.ipv4mode !== 'none') {
values.ip = values.ipv4mode;
}
newdata[id] = PVE.Parser.printLxcNetwork(values);
@@ -161,6 +161,7 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
cdata.ip = '';
cdata.gw = '';
}
+ var none4 = (!cdata.ip && !cdata.gw && !dhcp4);
var auto6 = (cdata.ip6 === 'auto');
var dhcp6 = (cdata.ip6 === 'dhcp');
@@ -168,26 +169,36 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
cdata.ip6 = '';
cdata.gw6 = '';
}
+
+ var none6 = (!cdata.ip6 && !cdata.gw6 && !auto6 && !dhcp6);
something more telling could be nice, we do not need to exten the ip4/ip6
namescheme to all related variables, especially if they're not API params
(and thus fixed). Maybe:
noIPv6addr
noIPv4addr
ok
me.column2 = [
+ {
+ xtype: 'label',
+ text: 'IPv4:', // do not localize
+ },
{
layout: {
type: 'hbox',
align: 'middle'
},
border: false,
- margin: '0 0 5 0',
+ margin: '5 0 5 0',
items: [
{
- xtype: 'label',
- text: 'IPv4:' // do not localize
useless comment
i just copied it, but yes it doesn't add anything...
+ xtype: 'radiofield',
+ boxLabel: Proxmox.Utils.noneText,
+ name: 'ipv4mode',
+ inputValue: 'none',
+ checked: none4,
+ margin: '0 0 0 10',
},
{
xtype: 'radiofield',
boxLabel: gettext('Static'),
name: 'ipv4mode',
inputValue: 'static',
- checked: !dhcp4,
+ checked: !(dhcp4 || none4),
margin: '0 0 0 10',
listeners: {
change: function(cb, value) {
@@ -211,7 +222,8 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
name: 'ip',
vtype: 'IPCIDRAddress',
value: cdata.ip,
- disabled: dhcp4,
+ allowBlank: false,
+ disabled: dhcp4 || none4,
fieldLabel: 'IPv4/CIDR' // do not localize
},
{
@@ -219,14 +231,18 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
name: 'gw',
value: cdata.gw,
vtype: 'IPAddress',
- disabled: dhcp4,
+ disabled: dhcp4 || none4,
fieldLabel: gettext('Gateway') + ' (IPv4)',
margin: '0 0 3 0' // override bottom margin to account for the
menuseparator
},
{
xtype: 'menuseparator',
height: '3',
- margin: '0'
+ margin: '0 0 5 0',
+ },
+ {
+ xtype: 'label',
+ text: 'IPv6:' // do not localize
},
{
layout: {
@@ -234,18 +250,22 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
align: 'middle'
},
Re: [pve-devel] [RFC qemu-server 14/16] Allow specifying targetstorage for offline migration
On January 29, 2020 2:30 pm, Fabian Ebner wrote:
> Signed-off-by: Fabian Ebner
> ---
> PVE/API2/Qemu.pm | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index 89e2477..f21fb69 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -3379,9 +3379,6 @@ __PACKAGE__->register_method({
> $param->{online} = 0;
> }
>
> - raise_param_exc({ targetstorage => "Live storage migration can only be
> done online." })
> - if !$param->{online} && $param->{targetstorage};
> -
maybe it makes sense to add a pointer to maybe try live-migration in
case offline fails? e.g., zvol -> raw is not supported by
storage_migrate, but is by NBD (as long as no snapshots exist).
> my $storecfg = PVE::Storage::config();
>
> if( $param->{targetstorage}) {
> --
> 2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH v3 cluster 3/4] Add verification and fallback to cluster join/addnode
Am 1/9/20 um 4:31 PM schrieb Stefan Reiter: > Verify that the config of the new node is valid and compatible with the > cluster (i.e. that the links for the new node match the currently > configured nodes). > > Additionally, fallback is provided via a new parameter to addnode, > 'new_node_ip'. Previously, fallback was handled on the joining node, by > setting it's local IP as 'link0', however, a cluster with only one link, > but numbered 1-7 is still valid, and a fallback is possible, but the old > code would now fail. > > Instead, pass the locally resolved IP via a seperate parameter > (resolving the IP on the cluster side is impractical, as IP resolution > could fail or provide a wrong IP for Corosync). > > For compatibility reasons, allow fallback to occur via the old > method as well, but mark with FIXME for future removal. > > Fallback fails in case the cluster has more than one link, in this case > only the user can know which NIC/IP corresponds to which cluster link. > > Signed-off-by: Stefan Reiter > --- > data/PVE/API2/ClusterConfig.pm | 63 +- > data/PVE/CLI/pvecm.pm | 7 > data/PVE/Cluster/Setup.pm | 7 > 3 files changed, 76 insertions(+), 1 deletion(-) > applied ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH v3 cluster 2/4] Enable support for up to 8 corosync links
Am 1/9/20 um 4:31 PM schrieb Stefan Reiter: > add_corosync_link_properties/extract_corosync_link_args are introduced > as helpers to avoid hardcoding links in parameters=>properties on > several occasions, while still providing autocompletion with pvecm by > being seperate parameters instead of an array. > > Maximum number of links is given as constant MAX_LINK_COUNT, should it > change in the future. > > All necessary functions have been updated to > use the new $links array format instead of seperate $link0/$link1 > parameters, and call sites changed accordingly. > > Signed-off-by: Stefan Reiter > --- > > This patch intentionally removes some verification and fallback code to be > reintroduced in the next one. > > data/PVE/API2/ClusterConfig.pm | 51 +++- > data/PVE/CLI/pvecm.pm | 21 > data/PVE/Cluster/Setup.pm | 20 > data/PVE/Corosync.pm | 88 +++--- > 4 files changed, 97 insertions(+), 83 deletions(-) > applied, thanks! ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC guest-common 1/16] Implement update_volume_ids and add required helpers: foreach_volume and print_volume
On January 29, 2020 2:29 pm, Fabian Ebner wrote:
> This function is intened to be used after doing a migration where some
> of the volume IDs changed.
forgot to ask this - this is in AbstractConfig because you intend to
also re-use this for a similar feature for pve-container? else we could
and probably should keep it in qemu-server for now (although having
abstract volume iterators would still be nice ;))
>
> Signed-off-by: Fabian Ebner
> ---
> PVE/AbstractConfig.pm | 61 +++
> 1 file changed, 61 insertions(+)
>
> diff --git a/PVE/AbstractConfig.pm b/PVE/AbstractConfig.pm
> index a94a379..fb833cb 100644
> --- a/PVE/AbstractConfig.pm
> +++ b/PVE/AbstractConfig.pm
> @@ -366,6 +366,67 @@ sub get_replicatable_volumes {
> die "implement me - abstract method\n";
> }
>
> +sub foreach_volume {
> +my ($class, $conf, $func, @param) = @_;
> +
> +die "abstract method - implement me\n";
> +}
> +
> +sub print_volume {
> +my ($class, $volume) = @_;
> +
> +die "abstract method - implement me\n";
> +}
> +
> +# $volume_map is a hash of 'old_volid' => 'new_volid' pairs.
> +# This method replaces 'old_volid' by 'new_volid' throughout
> +# the config including snapshots, both for volumes appearing in
> +# foreach_volume as well as vmstate and unusedN values.
> +sub update_volume_ids {
> +my ($class, $conf, $volume_map) = @_;
> +
> +my $newconf = {};
> +
> +my $do_replace = sub {
> + my ($key, $volume, $newconf, $volume_map) = @_;
> +
> + my $old_volid = $volume->{file} // $volume->{volume};
> + if (my $new_volid = $volume_map->{$old_volid}) {
> + $volume->{file} = $new_volid if defined($volume->{file});
> + $volume->{volume} = $new_volid if defined($volume->{volume});
> + $newconf->{$key} = $class->print_volume($volume);
> + }
> +};
> +
> +my $replace_volids = sub {
> + my ($conf) = @_;
> +
> + my $newconf = {};
> + foreach my $key (keys %{$conf}) {
> + next if $key =~ m/^snapshots$/;
> + # these keys are not handled by foreach_volume
> + if ($key =~ m/^(vmstate)|(unused\d+)$/) {
> + my $old_volid = $conf->{$key};
> + $newconf->{$key} = $volume_map->{$old_volid};
> + }
> + $newconf->{$key} = $conf->{$key} if !defined($newconf->{$key});
> + }
> +
> + $class->foreach_volume($conf, $do_replace, $newconf, $volume_map);
> + return $newconf;
> +};
> +
> +$newconf = $replace_volids->($conf);
> +foreach my $snap (keys %{$conf->{snapshots}}) {
> + my $newsnap = $replace_volids->($conf->{snapshots}->{$snap});
> + foreach my $k (keys %{$newsnap}) {
> + $newconf->{snapshots}->{$snap}->{$k} = $newsnap->{$k};
> + }
> +}
> +
> +return $newconf;
> +}
> +
> # Internal snapshots
>
> # NOTE: Snapshot create/delete involves several non-atomic
> --
> 2.20.1
>
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC qemu-server 12/16] Implement abstract foreach_volume and print_volume
On January 29, 2020 2:30 pm, Fabian Ebner wrote:
> Signed-off-by: Fabian Ebner
> ---
> PVE/QemuConfig.pm | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/PVE/QemuConfig.pm b/PVE/QemuConfig.pm
> index 1ba728a..a983e52 100644
> --- a/PVE/QemuConfig.pm
> +++ b/PVE/QemuConfig.pm
> @@ -130,6 +130,18 @@ sub get_replicatable_volumes {
> return $volhash;
> }
>
> +sub foreach_volume {
> +my ($class, $conf, $func, @param) = @_;
> +
> +PVE::QemuServer::foreach_drive($conf, $func, @param);
> +}
> +
> +sub print_volume {
> +my ($class, $volume) = @_;
> +
> +return PVE::QemuServer::print_drive($volume);
> +}
> +
I kind of feel like I should apply the same standards as with previous
patch series, and get you to investigate moving drive-related code to
their own files instead of increasing the coupling between QemuConfig
and QemuServer even further ;)
foreach_drive could then remain as a backwards-compatible wrapper around
the new foreach_volume, which could have a new interface (hint: also
taking pve-container into account!) and/or
additional functionality
did you already do that? ideally, it would look similar to what Stefan
did with Machine/CPU/.. related code, so that we end up with
QemuDrive.pm (or multiple such files) which can be called from
QemuServer or QemuConfig, and which contains the schema and helpers,
with the implementation of the new abstract iterator in QemuConfig
re-using the new module(s).
> sub __snapshot_save_vmstate {
> my ($class, $vmid, $conf, $snapname, $storecfg, $statestorage, $suspend)
> = @_;
>
> --
> 2.20.1
>
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC guest-common 1/16] Implement update_volume_ids and add required helpers: foreach_volume and print_volume
On January 29, 2020 2:29 pm, Fabian Ebner wrote:
> This function is intened to be used after doing a migration where some
> of the volume IDs changed.
>
> Signed-off-by: Fabian Ebner
> ---
> PVE/AbstractConfig.pm | 61 +++
> 1 file changed, 61 insertions(+)
>
> diff --git a/PVE/AbstractConfig.pm b/PVE/AbstractConfig.pm
> index a94a379..fb833cb 100644
> --- a/PVE/AbstractConfig.pm
> +++ b/PVE/AbstractConfig.pm
> @@ -366,6 +366,67 @@ sub get_replicatable_volumes {
> die "implement me - abstract method\n";
> }
>
> +sub foreach_volume {
> +my ($class, $conf, $func, @param) = @_;
> +
> +die "abstract method - implement me\n";
> +}
> +
> +sub print_volume {
> +my ($class, $volume) = @_;
> +
> +die "abstract method - implement me\n";
> +}
if we do this, we probably also want a parse_volume here? see comments
on qemu-server #12
> +
> +# $volume_map is a hash of 'old_volid' => 'new_volid' pairs.
> +# This method replaces 'old_volid' by 'new_volid' throughout
> +# the config including snapshots, both for volumes appearing in
> +# foreach_volume as well as vmstate and unusedN values.
> +sub update_volume_ids {
> +my ($class, $conf, $volume_map) = @_;
> +
> +my $newconf = {};
why not modify the config in place? you replace the old one with the
returned new one anyway in the single caller, and write it out directly
afterwards ;) it would make the code shorter, and more inline with how
we usually modify $conf
> +
> +my $do_replace = sub {
> + my ($key, $volume, $newconf, $volume_map) = @_;
no need to pass $newconf and $volume_map as parameter, the one from
update_volume_ids is accessible here anyway.
> +
> + my $old_volid = $volume->{file} // $volume->{volume};
it might make sense to expose this (under which key the volid is stored)
via AbstractConfig/QemuConfig/LXC::Config, Aaron's backup status patch series
also
needs this information in pve-manager.
> + if (my $new_volid = $volume_map->{$old_volid}) {
> + $volume->{file} = $new_volid if defined($volume->{file});
> + $volume->{volume} = $new_volid if defined($volume->{volume});
which would make this a single line
> + $newconf->{$key} = $class->print_volume($volume);
> + }
> +};
> +
> +my $replace_volids = sub {
> + my ($conf) = @_;
> +
> + my $newconf = {};
> + foreach my $key (keys %{$conf}) {
> + next if $key =~ m/^snapshots$/;
> + # these keys are not handled by foreach_volume
would it make sense to include them optionally?
we have lots of use cases where we really want to iterate over ALL the
currently referenced volumes.. I know both of them only have a volid,
but we could just set that into $parsed->{file} or $parsed->{volume} and
leave the rest empty. if you call foreach_volume with
$opts->{include_vmstate} or $opts->{include_unused} you of course need
to be able to handle them properly, and we'd need to look whether
pve-container can easily support such an interface as well.
> + if ($key =~ m/^(vmstate)|(unused\d+)$/) {
> + my $old_volid = $conf->{$key};
> + $newconf->{$key} = $volume_map->{$old_volid};
in-place, this could become
$conf->{$key} = $volume_map->{$conf->{$key}};
> + }
> + $newconf->{$key} = $conf->{$key} if !defined($newconf->{$key});
not needed for in-place
> + }
> +
> + $class->foreach_volume($conf, $do_replace, $newconf, $volume_map);
> + return $newconf;
> +};
> +
> +$newconf = $replace_volids->($conf);
> +foreach my $snap (keys %{$conf->{snapshots}}) {
> + my $newsnap = $replace_volids->($conf->{snapshots}->{$snap});
> + foreach my $k (keys %{$newsnap}) {
> + $newconf->{snapshots}->{$snap}->{$k} = $newsnap->{$k};
> + }
this second foreach should not be needed:
foreach my $snap (keys %${$conf->{snapshots}}) {
$newconf->{snapshots}->{$snap} =
$replace_volids->($conf->{snapshots}->{$snap});
}
(or $conf-> if we drop $newconf)
> +}
> +
> +return $newconf;
> +}
> +
> # Internal snapshots
>
> # NOTE: Snapshot create/delete involves several non-atomic
> --
> 2.20.1
>
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager] gui: increase scsi value to that in the backend
Am 2/5/20 um 9:30 AM schrieb Dominik Csapak:
> we now can have 31 scsi disks, so show/allow them in the gui
>
> Signed-off-by: Dominik Csapak
> ---
> www/manager6/Utils.js | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js
> index 3c2a34d8..86951ed7 100644
> --- a/www/manager6/Utils.js
> +++ b/www/manager6/Utils.js
> @@ -1159,7 +1159,7 @@ Ext.define('PVE.Utils', { utilities: {
> diskControllerMaxIDs: {
> ide: 4,
> sata: 6,
> - scsi: 14,
> + scsi: 31,
> virtio: 16,
> },
>
>
applied, thanks. A note with which qemu-server version this will work
would be nice to have in the commit message for such patches.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager] gui: lxc/Network: add a virtual 'none' option
Am 2/5/20 um 9:37 AM schrieb Dominik Csapak:
> sometimes, if users do not want a ipv4/6 address, they set the network mode
> to 'dhcp' instead of 'static' (with no ip set), in believe
> this will result in no ip
>
> in reality, often no ipv6 dhcp server exists in the environment, and
> the container start stalls for ~5min trying to get a ipv6
>
> to improve ux, add the option 'none', which functionally is the same
> as having selected 'static' with no ip set, and simultaniously
> make the ip required
>
> Signed-off-by: Dominik Csapak
> ---
> this panel is a good candidate for a rewrite using viemodel/controller,
> but this change is small and the gains of a rewrite not big enough,
> so i left it as is for now, but if someone wants to get some extjs experience,
> this could be a good exercise
>
The basic idea is OK, but do not make none the new default! CTs normally do
want a network, our main use case is system CTs after all, no network no fun
> www/manager6/lxc/Network.js | 51 ++---
> 1 file changed, 36 insertions(+), 15 deletions(-)
>
> diff --git a/www/manager6/lxc/Network.js b/www/manager6/lxc/Network.js
> index be40a8fa..4afcd09b 100644
> --- a/www/manager6/lxc/Network.js
> +++ b/www/manager6/lxc/Network.js
> @@ -36,10 +36,10 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
>
> var newdata = {};
>
> - if (values.ipv6mode !== 'static') {
> + if (values.ipv6mode !== 'static' && values.ipv6mode !== 'none') {
> values.ip6 = values.ipv6mode;
> }
> - if (values.ipv4mode !== 'static') {
> + if (values.ipv4mode !== 'static' && values.ipv4mode !== 'none') {
> values.ip = values.ipv4mode;
> }
> newdata[id] = PVE.Parser.printLxcNetwork(values);
> @@ -161,6 +161,7 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
> cdata.ip = '';
> cdata.gw = '';
> }
> + var none4 = (!cdata.ip && !cdata.gw && !dhcp4);
>
> var auto6 = (cdata.ip6 === 'auto');
> var dhcp6 = (cdata.ip6 === 'dhcp');
> @@ -168,26 +169,36 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
> cdata.ip6 = '';
> cdata.gw6 = '';
> }
> +
> + var none6 = (!cdata.ip6 && !cdata.gw6 && !auto6 && !dhcp6);
something more telling could be nice, we do not need to exten the ip4/ip6
namescheme to all related variables, especially if they're not API params
(and thus fixed). Maybe:
noIPv6addr
noIPv4addr
>
> me.column2 = [
> + {
> + xtype: 'label',
> + text: 'IPv4:', // do not localize
> + },
> {
> layout: {
> type: 'hbox',
> align: 'middle'
> },
> border: false,
> - margin: '0 0 5 0',
> + margin: '5 0 5 0',
> items: [
> {
> - xtype: 'label',
> - text: 'IPv4:' // do not localize
useless comment
> + xtype: 'radiofield',
> + boxLabel: Proxmox.Utils.noneText,
> + name: 'ipv4mode',
> + inputValue: 'none',
> + checked: none4,
> + margin: '0 0 0 10',
> },
> {
> xtype: 'radiofield',
> boxLabel: gettext('Static'),
> name: 'ipv4mode',
> inputValue: 'static',
> - checked: !dhcp4,
> + checked: !(dhcp4 || none4),
> margin: '0 0 0 10',
> listeners: {
> change: function(cb, value) {
> @@ -211,7 +222,8 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
> name: 'ip',
> vtype: 'IPCIDRAddress',
> value: cdata.ip,
> - disabled: dhcp4,
> + allowBlank: false,
> + disabled: dhcp4 || none4,
> fieldLabel: 'IPv4/CIDR' // do not localize
> },
> {
> @@ -219,14 +231,18 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
> name: 'gw',
> value: cdata.gw,
> vtype: 'IPAddress',
> - disabled: dhcp4,
> + disabled: dhcp4 || none4,
> fieldLabel: gettext('Gateway') + ' (IPv4)',
> margin: '0 0 3 0' // override bottom margin to account for the
> menuseparator
> },
> {
> xtype: 'menuseparator',
> height: '3',
> - margin: '0'
> + margin: '0 0 5 0',
> + },
> + {
> + xtype: 'label',
> + text: 'IPv6:' // do not localize
> },
> {
> layout: {
> @@ -234,18 +250,22 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
> align: 'middle'
> },
> border: false,
> - margin: '0 0 5 0',
> +
[pve-devel] applied: [PATCH qemu-server 10/16] rename 'volid' to 'drivestr' where it's not only a volume ID
On January 29, 2020 2:30 pm, Fabian Ebner wrote:
> Signed-off-by: Fabian Ebner
> ---
> PVE/QemuMigrate.pm | 10 +-
> PVE/QemuServer.pm | 4 ++--
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
> index 49848e8..d025b09 100644
> --- a/PVE/QemuMigrate.pm
> +++ b/PVE/QemuMigrate.pm
> @@ -491,7 +491,7 @@ sub cleanup_remotedisks {
>
> foreach my $target_drive (keys %{$self->{target_drive}}) {
>
> - my $drive = PVE::QemuServer::parse_drive($target_drive,
> $self->{target_drive}->{$target_drive}->{volid});
> + my $drive = PVE::QemuServer::parse_drive($target_drive,
> $self->{target_drive}->{$target_drive}->{drivestr});
> my ($storeid, $volname) = PVE::Storage::parse_volume_id($drive->{file});
>
> my $cmd = [@{$self->{rem_ssh}}, 'pvesm', 'free', "$storeid:$volname"];
> @@ -612,12 +612,12 @@ sub phase2 {
> $spice_port = int($1);
> }
> elsif ($line =~ m/^storage migration listens on
> nbd:(localhost|[\d\.]+|\[[\d\.:a-fA-F]+\]):(\d+):exportname=(\S+)
> volume:(\S+)$/) {
> - my $volid = $4;
> + my $drivestr = $4;
> my $nbd_uri = "nbd:$1:$2:exportname=$3";
> my $targetdrive = $3;
> $targetdrive =~ s/drive-//g;
>
> - $self->{target_drive}->{$targetdrive}->{volid} = $volid;
> + $self->{target_drive}->{$targetdrive}->{drivestr} = $drivestr;
> $self->{target_drive}->{$targetdrive}->{nbd_uri} = $nbd_uri;
>
> } elsif ($line =~ m/^QEMU: (.*)$/) {
> @@ -687,7 +687,7 @@ sub phase2 {
> my $target = $self->{target_drive}->{$drive};
> my $nbd_uri = $target->{nbd_uri};
> my $source_sid =
> PVE::Storage::Plugin::parse_volume_id($conf->{$drive});
> - my $target_sid =
> PVE::Storage::Plugin::parse_volume_id($target->{volid});
> + my $target_sid =
> PVE::Storage::Plugin::parse_volume_id($target->{drivestr});
> my $bwlimit = PVE::Storage::get_bandwidth_limit('migrate',
> [$source_sid, $target_sid], $opt_bwlimit);
>
> $self->log('info', "$drive: start migration to $nbd_uri");
> @@ -963,7 +963,7 @@ sub phase3_cleanup {
> die "Failed to complete storage migration: $err\n";
> } else {
> foreach my $target_drive (keys %{$self->{target_drive}}) {
> - my $drive = PVE::QemuServer::parse_drive($target_drive,
> $self->{target_drive}->{$target_drive}->{volid});
> + my $drive = PVE::QemuServer::parse_drive($target_drive,
> $self->{target_drive}->{$target_drive}->{drivestr});
> $conf->{$target_drive} = PVE::QemuServer::print_drive($drive);
> PVE::QemuConfig->write_config($vmid, $conf);
> }
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 7374bf1..c1f1c4e 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -5432,10 +5432,10 @@ sub vm_start {
> $localip = "[$localip]" if Net::IP::ip_is_ipv6($localip);
>
> foreach my $opt (sort keys %$local_volumes) {
> - my $volid = $local_volumes->{$opt};
> + my $drivestr = $local_volumes->{$opt};
> mon_cmd($vmid, "nbd-server-add", device => "drive-$opt",
> writable => JSON::true );
> my $migrate_storage_uri =
> "nbd:${localip}:${storage_migrate_port}:exportname=drive-$opt";
> - print "storage migration listens on $migrate_storage_uri
> volume:$volid\n";
> + print "storage migration listens on $migrate_storage_uri
> volume:$drivestr\n";
> }
> }
>
> --
> 2.20.1
>
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH qemu-server 11/16] Extract volume ID before calling 'parse_volume_id'
with slight re-grouping and blank lines added, thanks for catching this
before it bit us!
On January 29, 2020 2:30 pm, Fabian Ebner wrote:
> Signed-off-by: Fabian Ebner
> ---
> PVE/QemuMigrate.pm | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
> index d025b09..81b52d1 100644
> --- a/PVE/QemuMigrate.pm
> +++ b/PVE/QemuMigrate.pm
> @@ -686,8 +686,10 @@ sub phase2 {
> foreach my $drive (keys %{$self->{target_drive}}){
> my $target = $self->{target_drive}->{$drive};
> my $nbd_uri = $target->{nbd_uri};
> - my $source_sid =
> PVE::Storage::Plugin::parse_volume_id($conf->{$drive});
> - my $target_sid =
> PVE::Storage::Plugin::parse_volume_id($target->{drivestr});
> + my $target_drive = PVE::QemuServer::parse_drive($drive,
> $target->{drivestr});
> + my $source_drive = PVE::QemuServer::parse_drive($drive,
> $conf->{$drive});
> + my $source_sid =
> PVE::Storage::Plugin::parse_volume_id($source_drive->{file});
> + my $target_sid =
> PVE::Storage::Plugin::parse_volume_id($target_drive->{file});
> my $bwlimit = PVE::Storage::get_bandwidth_limit('migrate',
> [$source_sid, $target_sid], $opt_bwlimit);
>
> $self->log('info', "$drive: start migration to $nbd_uri");
> --
> 2.20.1
>
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH storage 4/16] storage_migrate: also log with an insecure connection if there is a log function
with the following follow-up:
commit 8e55b4f28838115c9cb3b85637d6b614da759cf6
Author: Fabian Grünbichler
storage_migrate: only set errfunc for send stream
since we redirect the output to our (insecure) socket, logfunc is only
used for STDERR anyway, so we might as well make it explicit on the
caller side.
Signed-off-by: Fabian Grünbichler
diff --git a/PVE/Storage.pm b/PVE/Storage.pm
index 2b292f6..62d72de 100755
--- a/PVE/Storage.pm
+++ b/PVE/Storage.pm
@@ -626,7 +626,7 @@ sub storage_migrate {
or die "failed to connect to tunnel at $ip:$port\n";
# we won't be reading from the socket
shutdown($socket, 0);
- run_command([$send, @cstream], output => '>&'.fileno($socket),
logfunc => $logfunc);
+ run_command([$send, @cstream], output => '>&'.fileno($socket),
errfunc => $logfunc);
# don't close the connection entirely otherwise the receiving end
# might not get all buffered data (and fails with 'connection reset
by peer')
shutdown($socket, 1);
On January 29, 2020 2:30 pm, Fabian Ebner wrote:
> Signed-off-by: Fabian Ebner
> ---
> PVE/Storage.pm | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
> index 5fefa06..2b292f6 100755
> --- a/PVE/Storage.pm
> +++ b/PVE/Storage.pm
> @@ -626,11 +626,21 @@ sub storage_migrate {
> or die "failed to connect to tunnel at $ip:$port\n";
> # we won't be reading from the socket
> shutdown($socket, 0);
> - run_command([$send, @cstream], output => '>&'.fileno($socket));
> + run_command([$send, @cstream], output => '>&'.fileno($socket),
> logfunc => $logfunc);
> # don't close the connection entirely otherwise the receiving end
> # might not get all buffered data (and fails with 'connection reset
> by peer')
> shutdown($socket, 1);
> - 1 while <$info>; # wait for the remote process to finish
> +
> + # wait for the remote process to finish
> + if ($logfunc) {
> + while (my $line = <$info>) {
> + chomp($line);
> + $logfunc->("[$target_sshinfo->{name}] $line");
> + }
> + } else {
> + 1 while <$info>;
> + }
> +
> # now close the socket
> close($socket);
> if (!close($info)) { # does waitpid()
> --
> 2.20.1
>
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH storage 2/16] Remove unused string
On January 29, 2020 2:30 pm, Fabian Ebner wrote:
> Signed-off-by: Fabian Ebner
> ---
> PVE/Storage.pm | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
> index 0bd103e..5fefa06 100755
> --- a/PVE/Storage.pm
> +++ b/PVE/Storage.pm
> @@ -573,7 +573,6 @@ sub storage_migrate {
> my $target_volid = "${target_storeid}:${target_volname}";
>
> my $target_ip = $target_sshinfo->{ip};
> -my $errstr = "unable to migrate '$volid' to '${target_volid}' on host
> '$target_sshinfo->{name}'";
>
> my $ssh = PVE::SSHInfo::ssh_info_to_command($target_sshinfo);
> my $ssh_base = PVE::SSHInfo::ssh_info_to_command_base($target_sshinfo);
> --
> 2.20.1
>
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager] gui: lxc/Network: add a virtual 'none' option
sometimes, if users do not want a ipv4/6 address, they set the network mode
to 'dhcp' instead of 'static' (with no ip set), in believe
this will result in no ip
in reality, often no ipv6 dhcp server exists in the environment, and
the container start stalls for ~5min trying to get a ipv6
to improve ux, add the option 'none', which functionally is the same
as having selected 'static' with no ip set, and simultaniously
make the ip required
Signed-off-by: Dominik Csapak
---
this panel is a good candidate for a rewrite using viemodel/controller,
but this change is small and the gains of a rewrite not big enough,
so i left it as is for now, but if someone wants to get some extjs experience,
this could be a good exercise
www/manager6/lxc/Network.js | 51 ++---
1 file changed, 36 insertions(+), 15 deletions(-)
diff --git a/www/manager6/lxc/Network.js b/www/manager6/lxc/Network.js
index be40a8fa..4afcd09b 100644
--- a/www/manager6/lxc/Network.js
+++ b/www/manager6/lxc/Network.js
@@ -36,10 +36,10 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
var newdata = {};
- if (values.ipv6mode !== 'static') {
+ if (values.ipv6mode !== 'static' && values.ipv6mode !== 'none') {
values.ip6 = values.ipv6mode;
}
- if (values.ipv4mode !== 'static') {
+ if (values.ipv4mode !== 'static' && values.ipv4mode !== 'none') {
values.ip = values.ipv4mode;
}
newdata[id] = PVE.Parser.printLxcNetwork(values);
@@ -161,6 +161,7 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
cdata.ip = '';
cdata.gw = '';
}
+ var none4 = (!cdata.ip && !cdata.gw && !dhcp4);
var auto6 = (cdata.ip6 === 'auto');
var dhcp6 = (cdata.ip6 === 'dhcp');
@@ -168,26 +169,36 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
cdata.ip6 = '';
cdata.gw6 = '';
}
+
+ var none6 = (!cdata.ip6 && !cdata.gw6 && !auto6 && !dhcp6);
me.column2 = [
+ {
+ xtype: 'label',
+ text: 'IPv4:', // do not localize
+ },
{
layout: {
type: 'hbox',
align: 'middle'
},
border: false,
- margin: '0 0 5 0',
+ margin: '5 0 5 0',
items: [
{
- xtype: 'label',
- text: 'IPv4:' // do not localize
+ xtype: 'radiofield',
+ boxLabel: Proxmox.Utils.noneText,
+ name: 'ipv4mode',
+ inputValue: 'none',
+ checked: none4,
+ margin: '0 0 0 10',
},
{
xtype: 'radiofield',
boxLabel: gettext('Static'),
name: 'ipv4mode',
inputValue: 'static',
- checked: !dhcp4,
+ checked: !(dhcp4 || none4),
margin: '0 0 0 10',
listeners: {
change: function(cb, value) {
@@ -211,7 +222,8 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
name: 'ip',
vtype: 'IPCIDRAddress',
value: cdata.ip,
- disabled: dhcp4,
+ allowBlank: false,
+ disabled: dhcp4 || none4,
fieldLabel: 'IPv4/CIDR' // do not localize
},
{
@@ -219,14 +231,18 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
name: 'gw',
value: cdata.gw,
vtype: 'IPAddress',
- disabled: dhcp4,
+ disabled: dhcp4 || none4,
fieldLabel: gettext('Gateway') + ' (IPv4)',
margin: '0 0 3 0' // override bottom margin to account for the
menuseparator
},
{
xtype: 'menuseparator',
height: '3',
- margin: '0'
+ margin: '0 0 5 0',
+ },
+ {
+ xtype: 'label',
+ text: 'IPv6:' // do not localize
},
{
layout: {
@@ -234,18 +250,22 @@ Ext.define('PVE.lxc.NetworkInputPanel', {
align: 'middle'
},
border: false,
- margin: '0 0 5 0',
+ margin: '5 0 5 0',
items: [
{
- xtype: 'label',
- text: 'IPv6:' // do not localize
+ xtype: 'radiofield',
+ boxLabel: Proxmox.Utils.noneText,
+ name: 'ipv6mode',
+ inputValue: 'none',
+ checked: none6,
+ margin: '0 0 0 10',
},
{
[pve-devel] [PATCH manager] gui: increase scsi value to that in the backend
we now can have 31 scsi disks, so show/allow them in the gui
Signed-off-by: Dominik Csapak
---
www/manager6/Utils.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js
index 3c2a34d8..86951ed7 100644
--- a/www/manager6/Utils.js
+++ b/www/manager6/Utils.js
@@ -1159,7 +1159,7 @@ Ext.define('PVE.Utils', { utilities: {
diskControllerMaxIDs: {
ide: 4,
sata: 6,
- scsi: 14,
+ scsi: 31,
virtio: 16,
},
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [RFC PATCH container] fix setting same netX value several times
when setting a netX option that is semantically the same as the
one already set but in a different order, e.g.:
in config:
net0: name=eth0,bridge=vmbr0,hwaddr=AA:AA:AA:AA:AA:AA,type=veth
setting via api:
net0: bridge=vmbr0,name=eth0,hwaddr=AA:AA:AA:AA:AA:AA,type=veth
the code tries to 'hot-apply' the change (which is no change really)
where the api line then gets parsed and printed which results
in the same string already in the config
then we do a 'cleanup_pending' which removes it from pending, since
the config already contains the exact same options, but
then we overwrite the config from pending (which is empty)
resulting in an invalid config line:
--8<--
net0:
-->8--
to prevent this, we only overwrite the config here when
there is still an option in in $conf->{pending}->{$opt}, meaning
there was a meaningful change
Signed-off-by: Dominik Csapak
---
i am not really sure if this is the correct place to fix this, because
i think we never should trigger apply_pending when the requested
config is semantically identical to what is already in the config,
but i did not really see when or how to do that in a good and generic way
(should be parse/print all property strings at the beginning?)
so sending it as an rfc
src/PVE/LXC/Config.pm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/PVE/LXC/Config.pm b/src/PVE/LXC/Config.pm
index 310aba6..49b9f70 100644
--- a/src/PVE/LXC/Config.pm
+++ b/src/PVE/LXC/Config.pm
@@ -1305,7 +1305,10 @@ sub vmconfig_apply_pending {
$add_apply_error->($opt, $err);
} else {
$class->cleanup_pending($conf);
- $conf->{$opt} = delete $conf->{pending}->{$opt};
+ # $conf->{pending}->{$opt} is now empty if we have the same
+ # value already in config, so do not overwrite the value in config
+ $conf->{$opt} = delete $conf->{pending}->{$opt}
+ if defined($conf->{pending}->{$opt});
}
}
--
2.20.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
