changing from Ext.Array.each to a for loop and changing the return
to a 'break', resulted in exiting the wrong loop (previously the outer,
now the inner) resulting in wrongly looping through all controllers
instead of only until we found a match
using a label and labeled break, we can break the
Some of the recent QMP changes require at least 2.8.0, but since the
oldest version we officially package for 6.x is 4.0.0 anyway, checking
for at least 3.0 should not break anyone's setup.
Note that this does not affect machine version checks, only the
installed QEMU binary version.
On 1/31/20 5:01 PM, Alwin Antreich wrote:
> detection into a separate function to reduce code duplication and allow
> for easier modification.
>
> Signed-off-by: Alwin Antreich
> ---
> PVE/Storage.pm | 78 --
> 1 file changed, 57 insertions(+), 21
Hi,
did you work on these gui patches, or is it roughly the same as last
time? (as in: should i start reviewing these?)
i'll look at them regardless the next days, to see if we could
apply some version of them and hide them for most users
(like thomas suggested)
kind regards
Dominik
On 2/10/20 4:05 PM, Stefan Reiter wrote:
> The previously introduced approach can fail for pinned versions when a
> new QEMU release is introduced. The saner approach is to use a mapping
> that gives one pve-version for each QEMU release.
>
> Fortunately, the old system has not been bumped yet,
On 2/10/20 4:05 PM, Stefan Reiter wrote:
> Live-migrating a VM with more than 14 SCSI disks to a node that doesn't
> support it yet is broken. Use a bumped pve-version to represent that and
> give the user a nice error message instead.
>
> Signed-off-by: Stefan Reiter
> ---
>
> This is more for
On 2/12/20 11:10 AM, Stefan Reiter wrote:
> Some of the recent QMP changes require at least 2.8.0, but since the
> oldest version we officially package for 6.x is 4.0.0 anyway, checking
> for at least 3.0 should not break anyone's setup.
>
> Note that this does not affect machine version checks,
On 2/11/20 5:42 PM, Thomas Lamprecht wrote:
applied series, but not really happy how you just ignored Stefan's and
my comment about why you change title capitalization in just a single
patch (sys requirements one) to something nowhere else used in the docs..
I'm sorry I forgot to answer
Some of the recent QMP changes require at least 2.8.0, but since the
oldest version we officially package for 6.x is 4.0.0 anyway, checking
for at least 3.0 should not break anyone's setup.
Note that this does not affect machine version checks, only the
installed QEMU binary version.
On 2/12/20 10:51 AM, Dominik Csapak wrote:
> changing from Ext.Array.each to a for loop and changing the return
> to a 'break', resulted in exiting the wrong loop (previously the outer,
> now the inner) resulting in wrongly looping through all controllers
> instead of only until we found a match
>
if no storage is selected in 'My Settings' our calculatin was done as follows:
* for every node, count 'local',
* every other storage gets only counted *once*, even if it is a local storage
as we have the 'shared' flag available, we can count local storages
for every node where they are defined
On 2/12/20 11:16 AM, Dominik Csapak wrote:
> if no storage is selected in 'My Settings' our calculatin was done as follows:
> * for every node, count 'local',
> * every other storage gets only counted *once*, even if it is a local storage
>
> as we have the 'shared' flag available, we can count
On 2/10/20 12:20 PM, Stefan Reiter wrote:
> Some of the recent QMP changes require at least 2.8.0, but since the
> oldest version we officially package for 6.x is 4.0.0 anyway, checking
> for at least 3.0 should not break anyone's setup.
>
> Note that this does not affect machine version checks,
On 1/31/20 5:00 PM, Alwin Antreich wrote:
> this, more compact form of the regex should allow easier addition of new
> file extensions.
>
> Signed-off-by: Alwin Antreich
> ---
> PVE/Storage.pm| 2 +-
> PVE/Storage/Plugin.pm | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
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
On 1/14/20 5:47 PM, Oguz Bektas wrote:
> * rephrase some parts.
> * update old information
> * add info about pending changes and other "new" features
>
> Co-Authored-by: Aaron Lauterer
> Signed-off-by: Oguz Bektas
> ---
>
> v1->v2:
> changed some of the writing in terms of phrasing and style,
On 1/30/20 1:54 PM, Fabian Grünbichler wrote:
> Signed-off-by: Fabian Grünbichler
> ---
> api-viewer/PVEAPI.js | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/api-viewer/PVEAPI.js b/api-viewer/PVEAPI.js
> index 2416161..53bc36c 100644
> --- a/api-viewer/PVEAPI.js
> +++
On 2/10/20 4:06 PM, 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.
>
> Signed-off-by: Oguz Bektas
> ---
>
> v1->v2:
> * add more rationale as suggested
We already keep hugepages if they are created with the kernel
commandline (hugepagesz=x hugepages=y), but some setups (specifically
hugepages across multiple NUMA nodes) cannot be configured that way.
Since we always clear these hugepages at VM shutdown, rebooting a VM
that uses them might not
This is required to support custom CPU models, since the
"cpu-models.conf" file is not versioned, and can be changed while a VM
using a custom model is running. Changing the file in such a state can
lead to a different "-cpu" argument on the receiving side.
This patch fixes this by passing the
$cpu_fmt is being reused for custom CPUs as well as VM-specific CPU
settings. The "pve-vm-cpu-conf" format is introduced to verify a config
specifically for use as VM-specific settings.
"pve-cpu-conf" is registered for use in custom CPU API calls (where no
additional checks are required).
Can be specified for a particular VM or via a custom CPU model (VM takes
precedence).
QEMU's default limit only allows up to 1TB of RAM per VM. Increasing the
physical address bits available to a VM can fix this.
Signed-off-by: Stefan Reiter
---
PVE/QemuServer/CPUConfig.pm | 24
Requires a mock CPU-model config, which is given as a raw string to also
test parsing capabilities. Also tests defaulting behaviour.
Signed-off-by: Stefan Reiter
---
test/cfg2cmd/custom-cpu-model-defaults.conf | 8 ++
.../custom-cpu-model-defaults.conf.cmd| 24 +
Just like with live-migration, custom CPU models might change after a
snapshot has been taken (or a VM suspended), which would lead to a
different QEMU invocation on rollback/resume.
Save the "-cpu" argument as a new "runningcpu" option into the VM conf
akin to "runningmachine" and use as
Based on the RFC and following on- and off-list discussion about custom CPU
models [0].
In essence, this revised patch allows a user to specify custom CPU models in
/etc/pve/cpu-models.conf (section-config style [1]), where VMs using that CPU
model inherit details from the definition. This
If a cputype is custom (check via prefix), try to load options from the
custom CPU model config, and set values accordingly.
While at it, extract currently hardcoded values into seperate sub and add
reasonings.
Since the new flag resolving outputs flags in sorted order for
consistency, adapt the
To avoid hardcoding even more CPU-flag related things for custom CPU
models, introduce a dynamic approach to resolving flags.
resolve_cpu_flags takes a list of hashes (as documented in the
comment) and resolves them to a valid "-cpu" argument without
duplicates. This also helps by providing a
Turn CPUConfig into a SectionConfig with parsing/writing support for
custom CPU models. IO is handled using cfs.
Namespacing will be provided using "custom-" prefix for custom model
names (in VM config only, cpu-models.conf will contain unprefixed
names).
Includes two overrides to avoid writing
Hi,
>>did you work on these gui patches, or is it roughly the same as last
>>time? (as in: should i start reviewing these?)
It's almost the same. Only some minor changes in forms field to match the last
updates of the plugins.
So no review needed for now.
(I'll try to polish it a little bit
This patches series is reworked from debian sid ovs 2.11 patches.
All is building fine (including ovs-dpdk is users want it)
last patch is a fix for ovs_mtu with bond.
(I have contacted the upstream maintainer for this)
I have tested all differents kind of ovs interfaces,
all is working fine.
---
debian/changelog | 1551 ++
1 file changed, 52 insertions(+), 1499 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 9d0196e..e687156 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,1546 +1,99 @@
-openvswitch
---
Makefile | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index ff48b92..c76b5d8 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
# also add entry in changelog.Debian
-OVSVER=2.7.0
-PKGRELEASE=3
+OVSVER=2.12.0
+PKGRELEASE=1
ovs_mtu can't be applied on bond directly,
it need to be setup on physical interfaces, but only
after they are in the bond.
Easy way to to apply ovs_mtu from bond interfaces, to it's slave
directly
---
debian/ifupdown.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/debian/ifupdown.sh
---
debian/openvswitch-common.install | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/openvswitch-common.install
b/debian/openvswitch-common.install
index 2770725..1aa9563 100644
--- a/debian/openvswitch-common.install
+++ b/debian/openvswitch-common.install
@@
---
...e-Also-use-LIBS-from-dpkg-pkg-config.patch | 366 --
.../patches/disable-failing-ovn-tests.patch | 327
debian/patches/series | 2 -
3 files changed, 695 deletions(-)
delete mode 100644
This is fixing possible race condition with ovs 2.12
ans also cleanly remove ovs interfaces on networking service stop
Signed-off-by: Alexandre Derumier
---
...ce-ifup-ifdown-allow-ovs-on-start-st.patch | 26 +++
debian/patches/series | 1 +
2 files
On Wed, Feb 12, 2020 at 11:19:06AM +0100, Thomas Lamprecht wrote:
> On 1/31/20 5:00 PM, Alwin Antreich wrote:
> > --- a/PVE/Storage/Plugin.pm
> > +++ b/PVE/Storage/Plugin.pm
> > @@ -423,7 +423,7 @@ sub parse_volname {
> > return ('vztmpl', $1);
> > } elsif ($volname =~ m!^rootdir/(\d+)$!)
37 matches
Mail list logo
