On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote:
> Could you elaborate why it would fail if with what I proposed?
First I think I was wrong I misunderstood what you said.
To summarise, you said:
- any new feature depending on another package is off by default
- starting qemu on destinati
On Fri, Jul 26, 2024 at 07:39:46PM +0200, Thomas Huth wrote:
> Anyway, while we're discussing solutions: We are in softfreeze already.
> Should we disable the UFO bits in the new 9.1 machine type for the time
> being to avoid that more people are running into this problem?
At the moment I'm lookin
On Tue, Jul 30, 2024 at 02:02:27AM +0900, Akihiko Odaki wrote:
> I think it is simpler to analyze the platform dependency and dump it for the
> management layer. For example, libvirt can request QEMU to analyze the
> platform dependency when it creates a new domain. QEMU will then figure out
> that
On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote:
> >
> > The right solution is to have a tool that can query
> > backends, and that given the results from all of the cluster,
> > generate a set of parameters that will ensure migration works.
> > Kind of like qemu-img, but for migration.
>
On 2024/08/01 11:28, Jason Wang wrote:
On Wed, Jul 31, 2024 at 8:58 PM Peter Xu wrote:
On Wed, Jul 31, 2024 at 03:41:00AM -0400, Michael S. Tsirkin wrote:
On Wed, Jul 31, 2024 at 08:04:24AM +0100, Daniel P. Berrangé wrote:
On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:
On 2024/07/31 4:11, Peter Xu wrote:
On Tue, Jul 30, 2024 at 07:46:12PM +0100, Daniel P. Berrangé wrote:
On Tue, Jul 30, 2024 at 02:13:51PM -0400, Peter Xu wrote:
On Mon, Jul 29, 2024 at 06:26:41PM +0100, Daniel P. Berrangé wrote:
On Mon, Jul 29, 2024 at 01:00:30PM -0400, Peter Xu wrote:
On Mo
On Wed, Jul 31, 2024 at 8:58 PM Peter Xu wrote:
>
> On Wed, Jul 31, 2024 at 03:41:00AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 31, 2024 at 08:04:24AM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 30, 2024 at
Signed-off-by: Ján Tomko
---
scripts/group-qemu-caps.py | 50 ++
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git a/scripts/group-qemu-caps.py b/scripts/group-qemu-caps.py
index 34823931df..e4161f5bb5 100755
--- a/scripts/group-qemu-caps.py
+++ b/s
This removes some newline handling at the cost of adding it elsewhere.
Signed-off-by: Ján Tomko
---
scripts/group-qemu-caps.py | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/scripts/group-qemu-caps.py b/scripts/group-qemu-caps.py
index a43cd1de45..3482393
Separate file loading from its parsing.
Signed-off-by: Ján Tomko
---
scripts/group-qemu-caps.py | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/scripts/group-qemu-caps.py b/scripts/group-qemu-caps.py
index 3581d1545a..a43cd1de45 100755
--- a/scripts/group-
We're only looking at a simple string match.
Signed-off-by: Ján Tomko
---
scripts/group-qemu-caps.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/scripts/group-qemu-caps.py b/scripts/group-qemu-caps.py
index 49b64c93fc..3581d1545a 100755
--- a/scripts/group-qemu
Instead, iterate over (a part of) the array twice:
* once to find where the caps start and end
* once only over the lines with caps
Signed-off-by: Ján Tomko
---
scripts/group-qemu-caps.py | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/scrip
Signed-off-by: Ján Tomko
---
scripts/group-qemu-caps.py | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/scripts/group-qemu-caps.py b/scripts/group-qemu-caps.py
index 8a899a76c2..ec10f24384 100755
--- a/scripts/group-qemu-caps.py
+++ b/scrip
Even though it still stays a Perl script at heart.
Ján Tomko (6):
scripts: group-qemu-caps: use read
scripts: group-qemu-caps: remove cryptic bool
scripts: group-qemu-caps: remove unecessary regex
scripts: group-qemu-caps: separate file loading
scripts: group-qemu-caps: regroup_caps: ope
On Wed, Jul 31, 2024 at 03:41:00AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 31, 2024 at 08:04:24AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Jul 30, 2024 at 04:03:53PM -0400, Peter Xu wrote:
> > > > On Tue, Jul 30, 2
On Tue, Jul 30, 2024 at 05:36:38PM GMT, Michal Privoznik wrote:
> This is a v2 of the following patch:
>
> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/PP4WO2ZYB7UXMV6WQ2N4B33KCUUDIQFK/
>
> NB, 1/2 from the original series is pushed already.
>
> diff to v1:
> - adjusted ar
It's possible to hit the following situation during qemu p2p live
migration:
1. qemu has live migrated and exited (making virDomainObjIsActive()
return false)
2. the live migration job is still in progress, waiting for a
confirmation from the remote libvirt daemon. This may last for
a wh
Reviewed-by: Boris Fiuczynski
On 7/31/24 1:02 PM, Peter Krempa wrote:
The s390(x) machines never supported ACPI. That didn't stop users
enabling ACPI in their config. As of libvirt-9.2 (98c4e3d073) with new
enough qemu we reject configs which require ACPI, but qemu can't satisfy
it.
This break
Reviewed-by: Boris Fiuczynski
On 7/31/24 1:02 PM, Peter Krempa wrote:
Replace the 'misc-acpi' case by testing a bunch of architectures for how
ACPI is handled including a test for the s390 ACPI strip hack added in
previous commit.
Signed-off-by: Peter Krempa
---
.../aarch64-nousb-acpi.aarch
Replace the 'misc-acpi' case by testing a bunch of architectures for how
ACPI is handled including a test for the s390 ACPI strip hack added in
previous commit.
Signed-off-by: Peter Krempa
---
.../aarch64-nousb-acpi.aarch64-latest.err | 1 +
tests/qemuxmlconfdata/aarch64-nousb-acpi.xml | 1
The s390(x) machines never supported ACPI. That didn't stop users
enabling ACPI in their config. As of libvirt-9.2 (98c4e3d073) with new
enough qemu we reject configs which require ACPI, but qemu can't satisfy
it.
This breaks migration of existing VMs with the old wrong configs to new
libvirt inst
See patch 1 for the rationale.
Peter Krempa (2):
qemu_domain: Strip from s390(x) definitions
qemuxmlconftest: Add tests for the ACPI stripping hack on s390
src/qemu/qemu_domain.c| 94 +++
.../aarch64-nousb-acpi.aarch64-latest.err | 1 +
tests/qem
On Wed, Jul 31, 2024 at 12:36:43 +0200, Boris Fiuczynski wrote:
> Migrations of S390 domains from hosts with QEMU supporting ACPI and a
> libvirt version prior 9.1.0 fail when the destination host runs a QEMU
> not supporting ACPI and a libvirt version 9.1.0 or older. Actually S390
> never supporte
Migrations of S390 domains from hosts with QEMU supporting ACPI and a
libvirt version prior 9.1.0 fail when the destination host runs a QEMU
not supporting ACPI and a libvirt version 9.1.0 or older. Actually S390
never supported ACPI but domains were allowed to have the feature ACPI
enabled and it
On Wed, Jul 31, 2024 at 08:04:24AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:
> > On Tue, Jul 30, 2024 at 04:03:53PM -0400, Peter Xu wrote:
> > > On Tue, Jul 30, 2024 at 03:22:50PM -0400, Michael S. Tsirkin wrote:
> > > > This is not what
qemu add sm4 in release 9, but the name of sm4 doesn't have the key
length suffix, So set size to 0, construct cipher name without
key length as suffix.
In order to support the snapshot of encrypted disks, it remove
the restrictions about cipher names in XML
Signed-off-by: luzhipeng
---
docs/for
On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jul 30, 2024 at 04:03:53PM -0400, Peter Xu wrote:
> > On Tue, Jul 30, 2024 at 03:22:50PM -0400, Michael S. Tsirkin wrote:
> > > This is not what we did historically. Why should we start now?
> >
> > It's a matter of whet
27 matches
Mail list logo
