Am 01.06.23 um 23:15 schrieb DERUMIER, Alexandre:
> Hi,
> I found an interesting thread on the forum about kvm_pv_unhalt
>
> https://forum.proxmox.com/threads/live-migration-between-intel-xeon-and-amd-epyc2-linux-guests.68663/
>
>
> Sounds good. Please also take a look at the default flag
> "kvm
Signed-off-by: Fiona Ebner
---
New in v2.
proxmox-apt/tests/repositories.rs | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/proxmox-apt/tests/repositories.rs
b/proxmox-apt/tests/repositories.rs
index 4b3c9de..6319a62 100644
--- a/proxmox-apt/tests/reposit
The old 'main' component stays valid, pointing to no-subscription,
which means the is_referenced_repository() check needs a special case
for it. It will eventually go away, together with the handles for
Quincy.
Alternatively, the standard repository's info() could've been changed
to return multipl
On Proxmox VE 8, only Quincy and newer will be supported.
Signed-off-by: Fiona Ebner
---
No changes in v2.
Changes for the series in v2:
* create temporary test directories inside CARGO_TARGET_TMPDIR
* mention that deprecated 'main' component maps to no-subscription
in description
Signed-off-by: Fiona Ebner
---
No changes in v2.
proxmox-apt/tests/repositories.rs | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/proxmox-apt/tests/repositories.rs
b/proxmox-apt/tests/repositories.rs
index 6319a62..2fb7ac8 100644
--- a/proxmox-apt/tests/repositories.rs
Signed-off-by: Fiona Ebner
---
No changes in v2.
proxmox-apt/tests/repositories.rs | 30 +++
.../ceph-quincy-bookworm.list | 6
.../ceph-quincy-nosub-bookworm.list | 2 ++
.../sources.list.d/ceph-quincy-bookworm.list | 4 +++
.../ce
>
> Note that migration between CPUs of different vendors is not a
> supported
> use case (it will always depend on specific models, kernel versions,
> etc.), so we can only justify not adding it to the new default model
> if
> it doesn't make life worse for everybody else.
>
> And I'd be a bit c
Am 01.06.23 um 15:53 schrieb Aaron Lauterer:
> When scanning all configured storages for disk images belonging to the
> VM, the migration could easily fail if a storage is not available, but
> enabled. That storage might not even be used by the VM at all.
>
> By not doing that and only looking at
Am 02.06.23 um 11:45 schrieb Fiona Ebner:
> Am 01.06.23 um 15:53 schrieb Aaron Lauterer:
>> When scanning all configured storages for disk images belonging to the
>> VM, the migration could easily fail if a storage is not available, but
>> enabled. That storage might not even be used by the VM at a
On 6/1/23 16:22, Thomas Lamprecht wrote:
Am 19/04/2023 um 12:34 schrieb Aaron Lauterer:
Signed-off-by: Aaron Lauterer
---
AFAIK we do not have negative sizes anywhere, and if, it is an
indication that something is wrong.
above belongs in the commit message, additionaly some background for
Hi,
we used kvm64 as default cpumodel since the begin of proxmox. (basically, it's
like a pentium4 cpu flags).
New distros like rhel9 are compiled to use more modern cpu flags.
(and windows already use new flags since year, and we already add some extra
cpu flags)
"
In 2020, AMD, Intel, Red
---
www/manager6/qemu/OSDefaults.js| 1 +
www/manager6/qemu/ProcessorEdit.js | 13 +
2 files changed, 14 insertions(+)
diff --git a/www/manager6/qemu/OSDefaults.js b/www/manager6/qemu/OSDefaults.js
index 5e588a58..58bc76ff 100644
--- a/www/manager6/qemu/OSDefaults.js
+++ b/www/ma
https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg01592.html
"
In 2020, AMD, Intel, Red Hat, and SUSE worked together to define
three microarchitecture levels on top of the historical x86-64
baseline:
* x86-64:original x86_64 baseline instruction set
* x86-64-v2: vector instructions
Am 02.06.23 um 11:13 schrieb DERUMIER, Alexandre:
>>
>> "catastrophic performance collapses" doesn't sound very promising :/
>>
>
> I have found another thread here:
> https://lore.kernel.org/all/0484ea3f-4ba7-4b93-e976-098c57171...@redhat.com/
> where paolo have done benchmark with only 3% differ
Am 01.06.23 um 15:53 schrieb Aaron Lauterer:
> @@ -351,9 +387,9 @@ my $source_vdisks = {
> {
> 'ctime' => '1589277334',
> 'format' => 'raw',
> - 'size' => 108003328,
> - 'vmid' => '111',
> - 'volid' => 'local-zfs:vm-111-disk-0',
> + 'size' =
On May 26, 2023 9:27 am, Alexandre Derumier wrote:
> add a default virtual zone called 'local' in the ressource tree,
> and handle permissions like a true sdn zone
>
> Signed-off-by: Alexandre Derumier
> ---
> PVE/API2/Cluster.pm | 12
> PVE/API2/Network.pm
On May 26, 2023 9:27 am, Alexandre Derumier wrote:
> Signed-off-by: Alexandre Derumier
> ---
> PVE/API2/Network.pm | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
> index b3faba1a..ba3b3e0e 100644
> --- a/PVE/API2/Ne
On May 26, 2023 9:27 am, Alexandre Derumier wrote:
> We need to display the bridge is the user have a permission
> on any vlan on the bridge.
>
> to avoid to check permissions on 4096 vlans for each bridge
> (could be slow with a lot of bridges),
> we first list vlans where acls are defined.
>
>
Am 01.06.23 um 15:53 schrieb Aaron Lauterer:
> @@ -256,42 +262,18 @@ sub phase1 {
(...)
>
> +# then all pending volumes
> +if (defined $conf->{pending} && %{$conf->{pending}}) {
Same style nits I mentioned in the qemu-server patch last time ;)
> + PVE::LXC::Config->foreach_volume(
a few more places that come to my mind that might warrant further
thinking or discussion:
- restoring a backup
- cloning a VM
On May 26, 2023 9:33 am, Alexandre Derumier wrote:
> Signed-off-by: Alexandre Derumier
> ---
> PVE/API2/Qemu.pm | 37 -
> 1 file chang
On May 26, 2023 9:33 am, Alexandre Derumier wrote:
> For proxmox 8, following the pve-manager patch serie
> https://lists.proxmox.com/pipermail/pve-devel/2023-May/056970.html
>
> This patch serie add check of permissions for bridge/vnets access
> (currently only at vm create/update, I'm note surei
> >
> > at minimum, it could be interesting to expose the flag in the gui,
> > for
> > users really needed intel-amd migration.
> >
>
> I'm not opposed to that. We could also add a short note to the docs
> that
> it might be worth a try to disable the flag if you need cross-vendor
> migration an
Am 01.06.23 um 15:53 schrieb Aaron Lauterer:
> Signed-off-by: Aaron Lauterer
> ---
> I am happy for suggestions on how to improve the phrasing if it is not
> clear enough.
>
> pvesm.adoc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/pvesm.adoc b/pvesm.adoc
> index 6ade1a4..7e91c50
This series introduces basic cloudinit support for containers. All in
all, it works quite similar to VMs, with the caveat that we only allow
network configuration through the alrady existing systems, and not via
cloud-init.
pve-container:
Leo Nunner (4):
cloudinit: introduce config parameters
The code to generate the actual configuration works pretty much the same
as with the VM system. We generate an instance ID by hashing the user
configuration, causing cloud-init to run every time said configuration
changes.
Instead of creating a config drive, we write files directly into the
volume
based on the already existing panel for VMs. Some things have been
changed, there is no network configuration, and a separate "enable"
options toggles cloud-init (simillar to adding/removing a cloud-init
drive for VMs).
Signed-off-by: Leo Nunner
---
www/manager6/Makefile | 1 +
www/man
Signed-off-by: Leo Nunner
---
www/manager6/qemu/CloudInit.js | 4 ++--
www/manager6/qemu/Config.js| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/www/manager6/qemu/CloudInit.js b/www/manager6/qemu/CloudInit.js
index 77ff93d41..14117ff6b 100644
--- a/www/manager6/qemu/Cl
Adds a cloudinit_config_properties function which dumps the config
parameters from the cloudinit config description. This is called
automatically when generating the docs.
Signed-off-by: Leo Nunner
---
src/PVE/LXC/Config.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/PVE/LXC/Confi
Introduce a 'pct cloudinit dump ' command to dump the
generated cloudinit configuration for a section.
Signed-off-by: Leo Nunner
---
src/PVE/API2/LXC.pm | 33 +
src/PVE/CLI/pct.pm | 4
src/PVE/LXC/Cloudinit.pm | 11 +++
3 files changed, 4
…the same way as it's already being done for VMs.
Signed-off-by: Leo Nunner
---
gen-pct-cloud-init-opts.pl | 16
1 file changed, 16 insertions(+)
create mode 100755 gen-pct-cloud-init-opts.pl
diff --git a/gen-pct-cloud-init-opts.pl b/gen-pct-cloud-init-opts.pl
new file mode 10
Introduce configuration parameters for cloud-init. Like with VMs, it's
possible to specify:
- user
- password
- ssh keys
- enable/disable updates on first boot
It's also possible to pass through custom config files for the user and
vendor settings. We don't allow configuring the ne
adds documentation for Cloud-Init for containers. Most of it has been
taken from the VM documentation, since the configuration mostly works
the same. Added a script to extract the cloudinit parameters the same
way it's already done for VMs.
Signed-off-by: Leo Nunner
---
Makefile| 1
Le vendredi 02 juin 2023 à 13:43 +0200, Fabian Grünbichler a écrit :
> a few more places that come to my mind that might warrant further
> thinking or discussion:
> - restoring a backup
doesn't it also use create_vm ?
__PACKAGE__->register_method({
name => 'create_vm',
path => '',
meth
Since some languages translate byte units like 'GiB' or write them in their
own script, this patch wraps units in the `gettext` function.
While most occurrences of byte strings can be translated within the
`format_size` function in `proxmox-widget-toolkit/src/Utils.js`, this patch
catches those in
Le vendredi 02 juin 2023 à 13:39 +0200, Fabian Grünbichler a écrit :
> On May 26, 2023 9:27 am, Alexandre Derumier wrote:
> > add a default virtual zone called 'local' in the ressource tree,
> > and handle permissions like a true sdn zone
> >
> > Signed-off-by: Alexandre Derumier
> > ---
> > PVE
Le vendredi 02 juin 2023 à 13:39 +0200, Fabian Grünbichler a écrit :
> On May 26, 2023 9:27 am, Alexandre Derumier wrote:
> > We need to display the bridge is the user have a permission
> > on any vlan on the bridge.
> >
> > to avoid to check permissions on 4096 vlans for each bridge
> > (could be
For the record, I tested on:
AMD Ryzen 9 7900X 12-Core Processor
AMD EPYC 7302P 16-Core Processor (Rome)
AMD EPYC 7313 16-Core Processor (Milan)
VMs were all with 2 or 4 cores, q35 and UEFI boot.
>> qm set -args '-cpu
kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+sep,+lahf_lm,+popcnt,+sse4.1,+sse
On 6/1/23 16:24, Thomas Lamprecht wrote:
Don't we reuse that on PBS/PMG too, and if is it working there?
The commit message isn't excactly telling... ;-)
on PMG we only allow creating bonds in the GUI. On PBS we allow bonds and
bridges. Though that makes we wonder what the use case for a
since rsync 3.2.4, the syntax to give multiple files in one parameter
does not work anymore, so instead add both files explicitly
this fixes the cluster join over ssh on bookworm
Signed-off-by: Dominik Csapak
---
src/PVE/CLI/pvecm.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Thanks Aeron.
I'll try to reproduce on my side on epyc milan.
AMD EPYC 7543 32-Core Processor microcode patch_level=0x0a0011ce
(I just tried again with q35, but I'm still not able de reproduce)
can you share your full vmid.conf ? (numa ? vga ?..).
do you use debian graphical install or conso
Le vendredi 02 juin 2023 à 12:21 +, DERUMIER, Alexandre a écrit :
> > should this als obe guarded by the type check like below? is there
> > anything that ensures that a 'local' zone doesn't already exist as
> > regular SDN-managed zone?
>
> I was more thinking to forbid "local" name in sdn co
The commit hash of the Ceph version might be different between major
releases. For example:
ceph version 17.2.6 (810db68029296377607028a6c6da1ec06f5a2b27) quincy (stable)
ceph version 17.2.6 (995dec2cdae920da21db2d455e55efbc339bde24) quincy (stable)
This can lead to unnecessary warnings of multipl
On 6/2/23 16:15, DERUMIER, Alexandre wrote:
Thanks Aeron.
I'll try to reproduce on my side on epyc milan.
AMD EPYC 7543 32-Core Processor microcode patch_level=0x0a0011ce
(I just tried again with q35, but I'm still not able de reproduce)
can you share your full vmid.conf ? (numa ? vga ?..)
Thanks!
I'll try to upgrade to 6.2 kernel, this is the only difference
Le vendredi 02 juin 2023 à 18:09 +0200, Aaron Lauterer a écrit :
>
>
> On 6/2/23 16:15, DERUMIER, Alexandre wrote:
> > Thanks Aeron.
> >
> > I'll try to reproduce on my side on epyc milan.
> > AMD EPYC 7543 32-Core Processo
little Japanese translation update for 3.0.0
--- ja.po 2023-06-03 11:10:29.097009127 +0900
+++ jan.po 2023-06-03 11:10:08.708856465 +0900
@@ -2104,9 +2104,8 @@
msgstr "データDevs"
#: pve-manager/www/manager6/ceph/FS.js:159
-#, fuzzy
msgid "Data Pool"
-msgstr "メディア Pool"
+msgstr "データPo
45 matches
Mail list logo
