The following (long) email describes a portion of the work-flow of how
my proposed incremental backup APIs will work, along with the backend
QMP commands that each one executes. I will reply to this thread with
further examples (the first example is long enough to be its own email).
This is
On 10/3/18 5:59 PM, Jim Fehlig wrote:
On 10/3/18 3:25 PM, Marek Marczykowski-Górecki wrote:
On Wed, Oct 03, 2018 at 03:13:30PM -0600, Jim Fehlig wrote:
On 10/2/18 4:50 PM, Jim Fehlig wrote:
On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote:
Since this is something between PV and HVM, it
On 10/3/18 3:25 PM, Marek Marczykowski-Górecki wrote:
On Wed, Oct 03, 2018 at 03:13:30PM -0600, Jim Fehlig wrote:
On 10/2/18 4:50 PM, Jim Fehlig wrote:
On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote:
Since this is something between PV and HVM, it makes sense to put the
setting in place
On 10/2/18 7:05 PM, Jim Fehlig wrote:
On 10/2/18 3:38 PM, Jim Fehlig wrote:
On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote:
This is a respin of my old PVHv1 patch[1], converted to PVHv2.
Should the code use "PVH" name (as libxl does internally), or "PVHv2" as in
many places in Xen
On Wed, Oct 03, 2018 at 03:13:30PM -0600, Jim Fehlig wrote:
> On 10/2/18 4:50 PM, Jim Fehlig wrote:
> > On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote:
> > > Since this is something between PV and HVM, it makes sense to put the
> > > setting in place where domain type is specified.
> > > To
Quoting Jiri Denemark (2018-10-03 09:36:34)
> Hmm, I guess I could have checked the cover letter before looking at the
> individual patches. That would safe me some time and thinking :-)
>
> On Thu, Sep 27, 2018 at 16:26:39 -0500, Chris Venteicher wrote:
> > Some architectures (S390) depend on
On 10/2/18 4:50 PM, Jim Fehlig wrote:
On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote:
Since this is something between PV and HVM, it makes sense to put the
setting in place where domain type is specified.
To enable it, use It is
also included in capabilities.xml, for every supported
On Wed, Oct 03, 2018 at 04:49:35PM +0200, Michal Privoznik wrote:
> On 10/02/2018 10:43 AM, Pavel Hrdina wrote:
> > We cannot detect only mount points to figure out whether cgroup v2
> > is available because systemd uses cgroup v2 for process tracking and
> > all controllers are mounted as cgroup
On 10/02/2018 10:43 AM, Pavel Hrdina wrote:
> Place cgroup v2 backend type before cgroup v1 to make it obvious
> that cgroup v2 is preferred implementation.
>
> Following patches will introduce support for hybrid configuration
> which will allow us to use both at the same time, but we should
>
On 10/02/2018 10:43 AM, Pavel Hrdina wrote:
> When reconnecting to a domain we are validating the cgroup name.
> In case of cgroup v2 we need to validate only the new format for host
> without systemd '{machinename}.libvirt-{drivername}' or scope name
> generated by systemd.
>
> Signed-off-by:
On 10/02/2018 10:43 AM, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina
> ---
> src/util/vircgroupv2.c | 9 +
> 1 file changed, 9 insertions(+)
ACK
Michal
P.S. This is where I stop my review for today. I'll resume tomorrow.
--
libvir-list mailing list
libvir-list@redhat.com
On 10/02/2018 10:43 AM, Pavel Hrdina wrote:
> We cannot detect only mount points to figure out whether cgroup v2
> is available because systemd uses cgroup v2 for process tracking and
> all controllers are mounted as cgroup v1 controllers.
>
> To make sure that this is no the situation we need to
Hmm, I guess I could have checked the cover letter before looking at the
individual patches. That would safe me some time and thinking :-)
On Thu, Sep 27, 2018 at 16:26:39 -0500, Chris Venteicher wrote:
> Some architectures (S390) depend on QEMU to compute baseline CPU model and
> expand a models
On Thu, Sep 27, 2018 at 16:26:44 -0500, Chris Venteicher wrote:
> Libvirt can compute baseline hypervisor cpu from list of S390 cpu models
> by using QEMU QMP messages to compute baseline within QEMU.
>
> QEMU only baselines one pair of CPU models per query so a sequence of
> multiple QMP queries
On Thu, Sep 27, 2018 at 16:26:43 -0500, Chris Venteicher wrote:
> Generalized QEMU process management functions supporting all forms of
> QMP queries including but no limited to capabilities queries.
>
> QEMU process instances can be maintained and used for multiple different QMP
> queries, of
On 18.05.2018 16:04, Nikolay Shirokovskiy wrote:
>
>
> On 14.02.2018 13:34, Daniel P. Berrangé wrote:
>> On Tue, Jan 30, 2018 at 10:34:14AM +0300, Nikolay Shirokovskiy wrote:
>>> Hi, all.
>>>
>>> It turns out that systemd daemon-reload reset settings that are managable
>>> thru 'systemctl
On Thu, Sep 27, 2018 at 16:26:42 -0500, Chris Venteicher wrote:
> A Full CPUModelInfo structure with props is sent to QEMU for expansion.
>
> virQEMUCapsProbeQMPHostCPU migratability logic partitioned into new function
> for clarity.
Unrelated changes should go into separate patches. Please,
On 10/03/2018 01:59 PM, Fabiano Fidêncio wrote:
> This work is preparing the field for adding and using metadata.libosinfo
> in GNOME Boxes (in a similar way that's already done for virt-manager)
> so we can have a cross-app schema for tracking libosinfo OS ID in the
> domain XML.
>
> The tests
On Wed, Oct 03, 2018 at 14:44:28 +0200, Ján Tomko wrote:
> My commit d6b8838 fixed the uid:gid for the pre-created UNIX sockets
> but did not account for the different umask of libvirtd and QEMU.
> Since commit 0e1a1a8c we set umask to '0002' for the QEMU process.
> Manually tune-up the
My commit d6b8838 fixed the uid:gid for the pre-created UNIX sockets
but did not account for the different umask of libvirtd and QEMU.
Since commit 0e1a1a8c we set umask to '0002' for the QEMU process.
Manually tune-up the permissions to match what we would have gotten
if QEMU had created the
On 10/03/2018 01:48 PM, Fabiano Fidêncio wrote:
> Commit 7190c5024d introduced the usage of new GObject define macros with
> private. However as the conversion hasn't been done for abstract types
> (G_DEFINE_ABSTRACT_TYPE) and the addition of the private classes for the
> abstract types has been
This work is preparing the field for adding and using metadata.libosinfo
in GNOME Boxes (in a similar way that's already done for virt-manager)
so we can have a cross-app schema for tracking libosinfo OS ID in the
domain XML.
The tests added are from real cases as:
- current Boxes' metadata (so,
gvir_config_domain_set_custom_xml_ns_children() basically has the same
functionallity as gvir_config_domain_set_custom_xml() but also sets the
namespace to the nodes' children.
Signed-off-by: Fabiano Fidêncio
---
libvirt-gconfig/libvirt-gconfig-domain.c | 41
With the current code, we can only create a custom XML that looks like:
https://wiki.gnome.org/Apps/Boxes;>
installed
http://centos.org/centos/7.0:0
/home/fidencio/Downloads/CentOS-7-x86_64-DVD-1804.iso
Although it works well for some use cases, there are use cases where
we'd
Commit 7190c5024d introduced the usage of new GObject define macros with
private. However as the conversion hasn't been done for abstract types
(G_DEFINE_ABSTRACT_TYPE) and the addition of the private classes for the
abstract types has been removed as part of the commit, crashes can be
seen in
On Tue, Oct 02, 2018 at 06:54:01PM -0600, Jim Fehlig wrote:
> On 10/2/18 5:02 PM, Marek Marczykowski-Górecki wrote:
> > On Tue, Oct 02, 2018 at 04:50:02PM -0600, Jim Fehlig wrote:
> > > My idea to add this variable for clarity now seems diluted by the need for
> > > the extra ifdef's :-/. Your
On Wed, Oct 03, 2018 at 13:16:35 +0200, Michal Privoznik wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1632711
>
> GlusterFS is typically safe when it comes to migration. It's a
> network FS after all. However, it can be mounted via FUSE driver
> they provide. If that is the case we fail
On 10/03/2018 01:04 PM, Jiri Denemark wrote:
> In commit v4.7.0-168-g993d85ae5e I introduced two Icelake CPU models,
> but failed to actually include them in the CPU map index.
>
> Signed-off-by: Jiri Denemark
> ---
> src/cpu_map/Makefile.inc.am | 2 ++
> src/cpu_map/index.xml | 2 ++
> 2
https://bugzilla.redhat.com/show_bug.cgi?id=1632711
GlusterFS is typically safe when it comes to migration. It's a
network FS after all. However, it can be mounted via FUSE driver
they provide. If that is the case we fail to identify it and
think migration is not safe and require
On Tue, Oct 02, 2018 at 17:25:34 +0200, Andrea Bolognani wrote:
> On Tue, 2018-10-02 at 16:43 +0200, Peter Krempa wrote:
> > On Tue, Oct 02, 2018 at 16:14:44 +0200, Andrea Bolognani wrote:
> [...]
> > > @@ -97,6 +97,11 @@ virConnectNumOfDomains(virConnectPtr conn)
> > > int ret =
In commit v4.7.0-168-g993d85ae5e I introduced two Icelake CPU models,
but failed to actually include them in the CPU map index.
Signed-off-by: Jiri Denemark
---
src/cpu_map/Makefile.inc.am | 2 ++
src/cpu_map/index.xml | 2 ++
2 files changed, 4 insertions(+)
diff --git
On Tue, Oct 02, 2018 at 18:26:12 +0200, Andrea Bolognani wrote:
> On Tue, 2018-10-02 at 17:19 +0200, Peter Krempa wrote:
> > Our documentation states in multiple places that fields not populated by
> > the user are mostly hypervisor dependant what the default will become.
> >
> > In my opinion
On Wed, Oct 03, 2018 at 09:13:00AM +0200, Michal Privoznik wrote:
> On 10/02/2018 05:38 PM, Pavel Hrdina wrote:
> > On Tue, Oct 02, 2018 at 05:19:30PM +0200, Peter Krempa wrote:
> >> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
> >>> Background
> >>> ==
> >>
> >> [...]
>
On 10/02/2018 05:38 PM, Pavel Hrdina wrote:
> On Tue, Oct 02, 2018 at 05:19:30PM +0200, Peter Krempa wrote:
>> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
>>> Background
>>> ==
>>
>> [...]
>>
>>> Two concrete examples are considered here: one is the
>>>
34 matches
Mail list logo
