On 11/7/22 04:32, Jiri Denemark wrote:
On Fri, Nov 04, 2022 at 10:09:31 -0600, Jim Fehlig wrote:
On 11/4/22 09:22, Martin Kletzander wrote:
On Thu, Nov 03, 2022 at 05:24:18PM +0100, Jiri Denemark wrote:
The libvirt-daemon subpackage contains libvirt-guests.sh script (used by
libvirt-guests ser
On 9/30/22 02:01, Daniel P. Berrangé wrote:
On Thu, Sep 29, 2022 at 04:22:50PM -0600, Jim Fehlig wrote:
Hi All,
I've procrastinated long enough and finally decided to switch to modular
daemons in openSUSE Factory libvirt package. For the most part, the Factory
spec file mimics the upstream one.
Signed-off-by: Jim Fehlig
---
libvirt.spec.in | 64 +++--
1 file changed, 41 insertions(+), 23 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index c83e6a1ab3..11c163fa69 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -443,11 +443,8
Signed-off-by: Jim Fehlig
---
libvirt.spec.in | 71 +++--
1 file changed, 34 insertions(+), 37 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 86b4922531..c83e6a1ab3 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1810,53 +1810
Move virtlockd, virtlogd, and virtproxyd to the new subpackage
libvirt-daemon-core.
Signed-off-by: Jim Fehlig
---
libvirt.spec.in | 133 +---
1 file changed, 82 insertions(+), 51 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 6b1e35
Remove %triggerpostun. Upgrades from libvirt < 1.3.0 is now unlikely.
Signed-off-by: Jim Fehlig
---
libvirt.spec.in | 12
1 file changed, 12 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 3c9975b684..6b1e351343 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@
Signed-off-by: Jim Fehlig
---
libvirt.spec.in | 250
1 file changed, 125 insertions(+), 125 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 277ecd3eb3..3c9975b684 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -239,33 +239
Signed-off-by: Jim Fehlig
---
libvirt.spec.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index eb8ebbdd3f..277ecd3eb3 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -862,9 +862,7 @@ capabilities of LXC
Summary: Server side daemon & driver requir
Currently it is not possible to install a modular daemon subpackage without
also installing the monolithic daemon
https://listman.redhat.com/archives/libvir-list/2022-September/234554.html
This series is an initial attempt at moving common daemons, utilities, and
files from the daemon subpackage
On Wed, Nov 23, 2022 at 13:35:42 +, John Levon wrote:
> On Wed, Nov 23, 2022 at 02:12:59PM +0100, Jiri Denemark wrote:
>
> > Not to mention that QEMU changed names of several features and even
> > deprecated
> > the old spellings which is completely transparent to libvirt users as they
> > c
Hi,
virDomainNetTypeSharesHostView[1] contains the logic where for some
interface types it swaps TX and RX values, because what TX from the
inside is RX on the outside and vice versa.
We observe a configuration where shows
swapped values in statistics, because, apparently, the values are
s
On Wed, Nov 23, 2022 at 01:35:42PM +, John Levon wrote:
> On Wed, Nov 23, 2022 at 02:12:59PM +0100, Jiri Denemark wrote:
>
> > Not to mention that QEMU changed names of several features and even
> > deprecated
> > the old spellings which is completely transparent to libvirt users as they
> >
On Wed, Nov 23, 2022 at 01:59:54PM +, Daniel P. Berrangé wrote:
> The poster child example of QEMU evolving is the block layer
> which has many syntax versions
Sure, those sorts of things have indeed changed an awful lot, and libvirt
obviously brings value in that interface. But that feels IM
On Wed, Nov 23, 2022 at 01:54:50PM +, John Levon wrote:
> On Wed, Nov 23, 2022 at 01:45:37PM +, Daniel P. Berrangé wrote:
>
> > Indeed, the very fact that libvirt exists and is widely used, is what
> > allows QEMU to deprecated and rename stuff on a pretty aggressive
> > schedule. If libvi
Tested internally and v3 also works well.
Thanks and Regards,
Shaleen Bathla
On Tue, Nov 22, 2022 at 03:08:43PM +0100, Peter Krempa wrote:
> From: Shaleen Bathla
>
> Use of qemuDomainValidateVcpuInfo in the helpers for hotplug and unplug
> of vCPUs can lead to spurious errors reported such as:
On Wed, Nov 23, 2022 at 02:12:59PM +0100, Jiri Denemark wrote:
> Not to mention that QEMU changed names of several features and even deprecated
> the old spellings which is completely transparent to libvirt users as they can
> still use the old names no matter what version of QEMU they use. This i
On Wed, Nov 23, 2022 at 01:45:37PM +, Daniel P. Berrangé wrote:
> Indeed, the very fact that libvirt exists and is widely used, is what
> allows QEMU to deprecated and rename stuff on a pretty aggressive
> schedule. If libvirt wasn't providing this isolation, then it is
> unlikely QEMU would h
On Wed, Nov 23, 2022 at 11:34:24 +, John Levon wrote:
> On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
>
> > > I really don't think we should allow this, especially not for something
> > > which is clearly intended to be used for production deployment. Our
> > > hypervisor CLI
Domain state needs to be refreshed after reset from the guest
side because it may be inconsistent with the internal qemu state.
Signed-off-by: Kristina Hanicova
---
src/qemu/qemu_domain.c | 1 +
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_driver.c | 16
src/qemu/qemu_proces
This series implements domain state refreshing after reset from libvirt
API and reboot from the guest OS.
Kristina Hanicova (2):
qemu: refresh state after reset
qemu: refresh state after reboot initiated from the guest
src/qemu/qemu_domain.c | 1 +
src/qemu/qemu_domain.h | 1 +
src/qemu/
On Wed, Nov 23, 2022 at 12:14:45 +, Daniel P. Berrangé wrote:
> On Wed, Nov 23, 2022 at 12:51:39PM +0100, Jiri Denemark wrote:
> > On Wed, Nov 23, 2022 at 11:41:03 +, Daniel P. Berrangé wrote:
> > > On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
> > > > On Wed, Nov 23, 2022
Domain state may change during the reset and qemu does not always
send events about it. In case it happens, the state would be
inconsistent with the internal state of qemu which could cause
additional problems. The solution is to refresh state after a
successful reset to query qemu about the curr
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index ff5a743716..70368ffb10 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7757,16 +775
'virDomainDeviceDefCopy' formats the definition and parses it back.
Since we already are parsing the XML here, we're better off parsing it
twice and save the formatting step.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 32
1 file changed, 12 insertio
On 23/11/22 6:00 pm, Daniel P. Berrangé wrote:
On Wed, Nov 23, 2022 at 05:58:41PM +0530, manish.mishra wrote:
On 23/11/22 5:44 pm, Daniel P. Berrangé wrote:
On Wed, Nov 23, 2022 at 12:51:39PM +0100, Jiri Denemark wrote:
On Wed, Nov 23, 2022 at 11:41:03 +, Daniel P. Berrangé wrote:
Why c
'virDomainDeviceDefCopy' formats the definition and parses it back.
Since we already are parsing the XML here, we're better off parsing it
twice and save the formatting step.
Signed-off-by: Peter Krempa
---
src/lxc/lxc_driver.c | 36 ++--
1 file changed, 14 insert
Remove the 'cleanup' label and 'ret' variable as we can now directly
return form all cases.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index bb345
Convert code *DomainUpdateDeviceFlags/*DomainDetachDeviceLiveAndConfig
to avoid use of virDomainDeviceDefCopy. We have the original XML string
from the user so it doesn't make sense to parse it and then copy it
(whcih involves formatting and parsing back), when we can simply parse
it twice, saving
On Wed, Nov 23, 2022 at 05:58:41PM +0530, manish.mishra wrote:
>
> On 23/11/22 5:44 pm, Daniel P. Berrangé wrote:
> > On Wed, Nov 23, 2022 at 12:51:39PM +0100, Jiri Denemark wrote:
> > > On Wed, Nov 23, 2022 at 11:41:03 +, Daniel P. Berrangé wrote:
> > > > Why can't it just use the exsting QEM
On 23/11/22 5:44 pm, Daniel P. Berrangé wrote:
On Wed, Nov 23, 2022 at 12:51:39PM +0100, Jiri Denemark wrote:
On Wed, Nov 23, 2022 at 11:41:03 +, Daniel P. Berrangé wrote:
On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
On Wed, Nov 23, 2022 at 11:18:01 +, Daniel P. Berr
The function is now unused. Remove it to dissuade anybody from trying to
use it in the future.
Signed-off-by: Peter Krempa
---
src/conf/domain_conf.c | 121 ---
src/conf/domain_conf.h | 4 --
src/libvirt_private.syms | 1 -
3 files changed, 126 deletio
'virDomainDeviceDefCopy' formats the definition and parses it back.
Since we already are parsing the XML here, we're better off parsing it
twice and save the formatting step.
Signed-off-by: Peter Krempa
---
src/lxc/lxc_driver.c | 39 ---
1 file changed, 16 ins
'virDomainDeviceDefCopy' formats the definition and parses it back.
Since we already are parsing the XML here, we're better off parsing it
twice and save the formatting step.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_driver.c | 32
1 file changed, 12 insertio
On Wed, Nov 23, 2022 at 11:57:08AM +, John Levon wrote:
> On Wed, Nov 23, 2022 at 11:48:17AM +, Daniel P. Berrangé wrote:
>
> > > We're struggling to see what value the libvirt layer is bringing us in
> > > this
> > > area, as opposed to a single-source-of-truth approach.
> >
> > Well li
On Wed, Nov 23, 2022 at 12:51:39PM +0100, Jiri Denemark wrote:
> On Wed, Nov 23, 2022 at 11:41:03 +, Daniel P. Berrangé wrote:
> > On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
> > > On Wed, Nov 23, 2022 at 11:18:01 +, Daniel P. Berrangé wrote:
> > > > On Tue, Nov 22, 2022
On Wed, Nov 23, 2022 at 11:48:17AM +, Daniel P. Berrangé wrote:
> > We're struggling to see what value the libvirt layer is bringing us in this
> > area, as opposed to a single-source-of-truth approach.
>
> Well libvirt's job is to insulate applications from the specific hypervisor
> implemen
On Wed, Nov 23, 2022 at 11:41:03 +, Daniel P. Berrangé wrote:
> On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
> > On Wed, Nov 23, 2022 at 11:18:01 +, Daniel P. Berrangé wrote:
> > > On Tue, Nov 22, 2022 at 01:48:39PM +0100, Jiri Denemark wrote:
> > > > On Mon, Nov 21, 2022
On 23/11/22 5:11 pm, Daniel P. Berrangé wrote:
On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
On Wed, Nov 23, 2022 at 11:18:01 +, Daniel P. Berrangé wrote:
On Tue, Nov 22, 2022 at 01:48:39PM +0100, Jiri Denemark wrote:
On Mon, Nov 21, 2022 at 12:47:58 +0530, manish.mishra
On Wed, Nov 23, 2022 at 11:34:24AM +, John Levon wrote:
> On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
>
> > > I really don't think we should allow this, especially not for something
> > > which is clearly intended to be used for production deployment. Our
> > > hypervisor CL
On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
> On Wed, Nov 23, 2022 at 11:18:01 +, Daniel P. Berrangé wrote:
> > On Tue, Nov 22, 2022 at 01:48:39PM +0100, Jiri Denemark wrote:
> > > On Mon, Nov 21, 2022 at 12:47:58 +0530, manish.mishra wrote:
> > > >
> > > > On 18/11/22 5:00
On Wed, Nov 23, 2022 at 12:29:24PM +0100, Jiri Denemark wrote:
> > I really don't think we should allow this, especially not for something
> > which is clearly intended to be used for production deployment. Our
> > hypervisor CLI passthrough is there to allow for short term workarounds
> > for bug
On Wed, Nov 23, 2022 at 11:18:01 +, Daniel P. Berrangé wrote:
> On Tue, Nov 22, 2022 at 01:48:39PM +0100, Jiri Denemark wrote:
> > On Mon, Nov 21, 2022 at 12:47:58 +0530, manish.mishra wrote:
> > >
> > > On 18/11/22 5:00 pm, Jiri Denemark wrote:
> > > > On Fri, Nov 18, 2022 at 10:18:59 +,
On Tue, Nov 22, 2022 at 01:48:39PM +0100, Jiri Denemark wrote:
> On Mon, Nov 21, 2022 at 12:47:58 +0530, manish.mishra wrote:
> >
> > On 18/11/22 5:00 pm, Jiri Denemark wrote:
> > > On Fri, Nov 18, 2022 at 10:18:59 +, John Levon wrote:
> > >> On Fri, Nov 18, 2022 at 10:52:32AM +0100, Jiri Dene
On Wed, Nov 23, 2022 at 13:40:21 +0530, manish.mishra wrote:
> Hi Jiri, Thanks, We discussed internally, yes something like that
> works for us. We wanted to dicusss how it will look like roughly
> before sending patch. Does something like below works. will
> be a sub-property within and it will
On Wed, Nov 23, 2022 at 10:35:59AM +0100, Michal Privoznik wrote:
> Our RPC calls can be divided into two groups: regular and high
> priority. The latter can be then processed by so called high
> priority worker threads. This is our way of defeating a
> 'deadlock' and allowing some RPCs to be proce
Our RPC calls can be divided into two groups: regular and high
priority. The latter can be then processed by so called high
priority worker threads. This is our way of defeating a
'deadlock' and allowing some RPCs to be processed even when all
(regular) worker threads are stuck. For instance: if al
On 22/11/22 6:18 pm, Jiri Denemark wrote:
On Mon, Nov 21, 2022 at 12:47:58 +0530, manish.mishra wrote:
On 18/11/22 5:00 pm, Jiri Denemark wrote:
On Fri, Nov 18, 2022 at 10:18:59 +, John Levon wrote:
On Fri, Nov 18, 2022 at 10:52:32AM +0100, Jiri Denemark wrote:
* Qemu already provi
47 matches
Mail list logo
