Re: [libvirt] [PATCH] docs: Format text in into a block

On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote: > With the rework of our webpage I've also noticed that we can make > our block look more uniform: stretch the lines so that each > has the equal width. Just like if you hit "align to block" in > your favourite text editor. > >

Re: [libvirt] [PATCH] docs: Format text in into a block

On Fri, Dec 02, 2016 at 01:37:17PM +0100, Michal Privoznik wrote: > On 02.12.2016 12:27, Daniel P. Berrange wrote: > > On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote: > >> With the rework of our webpage I've also noticed that we can make > >> our block look more uniform: stretch

Re: [libvirt] [PATCH] docs: Format text in into a block

On Fri, Dec 02, 2016 at 01:28:05PM +, Daniel P. Berrange wrote: On Fri, Dec 02, 2016 at 01:37:17PM +0100, Michal Privoznik wrote: On 02.12.2016 12:27, Daniel P. Berrange wrote: > On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote: >> With the rework of our webpage I've also

Re: [libvirt] [PATCH] docs: Format text in into a block

On 02.12.2016 12:27, Daniel P. Berrange wrote: > On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote: >> With the rework of our webpage I've also noticed that we can make >> our block look more uniform: stretch the lines so that each >> has the equal width. Just like if you hit

Re: [libvirt] [PATCH] docs: Format text in into a block

On Fri, Dec 02, 2016 at 11:27:10AM +, Daniel P. Berrange wrote: On Fri, Dec 02, 2016 at 12:02:54PM +0100, Michal Privoznik wrote: With the rework of our webpage I've also noticed that we can make our block look more uniform: stretch the lines so that each has the equal width. Just like if

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

On Fri, Dec 02, 2016 at 11:08:14AM +0100, Martin Kletzander wrote: > On Fri, Dec 02, 2016 at 09:16:26AM +, Daniel P. Berrange wrote: > > On Fri, Dec 02, 2016 at 10:14:22AM +0100, Martin Kletzander wrote: > > > On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote: > > > > Google

Re: [libvirt] bug, libvirt, internal error

On Thu, Dec 01, 2016 at 06:37:02PM -0500, CESAR DAVID VASQUEZ ROMERO wrote: Hi, I'm having a problem with libvirt. Since a few days, when I try to create a virtual machine I get the following error and I could not solve it " Imposible completar la instalación: 'internal error: Cannot find

[libvirt] [PATCH] docs: Format text in into a block

With the rework of our webpage I've also noticed that we can make our block look more uniform: stretch the lines so that each has the equal width. Just like if you hit "align to block" in your favourite text editor. Signed-off-by: Michal Privoznik --- docs/generic.css | 1

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On Fri, Dec 02, 2016 at 04:17:50PM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2016-12-02 at 15:18 +1100, David Gibson wrote: > > But if you pass through multiple groups, things get weird.  On q35, > > you'd generally expect physically separate (different slot) devices to > > appear under

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote: > Google announced OSS-Fuzz project [1]. It's aim is to test projects with > significant user base and/or critical projects to the global > infrastructure. I like to think that libvirt falls in both categories :-) > You can find a

Re: [libvirt] bug, libvirt, internal error

Hello. On Thu, Dec 01, 2016 at 18:37:02 -0500, CESAR DAVID VASQUEZ ROMERO wrote: > Hi, I'm having a problem with libvirt. What version of libvirt and virt-manager do you use? > Since a few days, when I try to create a virtual machine I get the > following error and I could not solve it Did

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote: Google announced OSS-Fuzz project [1]. It's aim is to test projects with significant user base and/or critical projects to the global infrastructure. I like to think that libvirt falls in both categories :-) You can find a list of

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

On Fri, Dec 02, 2016 at 10:14:22AM +0100, Martin Kletzander wrote: > On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote: > > Google announced OSS-Fuzz project [1]. It's aim is to test projects with > > significant user base and/or critical projects to the global > > infrastructure. I

Re: [libvirt] Should Libvirt apply for OSS-Fuzz?

On Fri, Dec 02, 2016 at 09:16:26AM +, Daniel P. Berrange wrote: On Fri, Dec 02, 2016 at 10:14:22AM +0100, Martin Kletzander wrote: On Fri, Dec 02, 2016 at 08:44:48AM +0100, Michal Privoznik wrote: > Google announced OSS-Fuzz project [1]. It's aim is to test projects with > significant user

[libvirt] Candidate Release 2 for libvirt-2.5.0 is out

As planned I tagged it in git head and pushed the signed tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ Nothing special noticed, seems that Laine patches are in so this looks good to me from my minimal viewpoint. That said having report for other platforms and systems is

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On 03/12/16 08:41, Benjamin Herrenschmidt wrote: > On Fri, 2016-12-02 at 16:50 +1100, David Gibson wrote: >> >> Uh.. I don't entirely follow you. From the host point of view there >> are multiple iommu groups (PEs), but from the guest point of view >> there's only one. On the guest side iommu

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On Fri, 2016-12-02 at 15:18 +1100, David Gibson wrote: > But if you pass through multiple groups, things get weird.  On q35, > you'd generally expect physically separate (different slot) devices to > appear under separate root complexes.  Whereas on pseries they'll > appear as siblings on a

Re: [libvirt] [PATCH 4/5] conf: add global check for duplicate drive addresses

On 30.11.2016 12:47, Marc Hartmayer wrote: > Add a global check for duplicate drive addresses. This will fix the > problem of duplicate disk and hostdev drive addresses. > > Example for duplicate drive addresses: > > ... > > > > ... > > > > > Another example: > > > ... >

Re: [libvirt] [PATCH v2] storage: vz storage pool support

On 20/09/16 23:30, John Ferlan wrote: On 07/14/2016 01:13 PM, Olga Krishtal wrote: This patch supports pool and volume management within Virtuozzo Storage. Virtuozzo Storage is a highly-available distributed software defined storage with built-in replication and disaster recovery. From

Re: [libvirt] [PATCH 0/5] Reject duplicate drive addresses

On 30.11.2016 12:47, Marc Hartmayer wrote: > Reject duplicate drive addresses at domain definition. Hot-plug for > disks and hostdevs is still to fix and this is why the old version of > drive address checking is still there. Additionally, it isn't that > easy to be sure that the changes won't

[libvirt] [PATCH RFC v3 13/15] FSPool: driver methods implementation

Signed-off-by: Olga Krishtal --- src/fs/fs_driver.c | 1723 +--- 1 file changed, 1515 insertions(+), 208 deletions(-) diff --git a/src/fs/fs_driver.c b/src/fs/fs_driver.c index 98d91fa..f913ce5 100644 ---

[libvirt] [PATCH RFC v3 11/15] virsh: filesystem pools commands

Signed-off-by: Nikolay Shirokovskiy Signed-off-by: Maxim Nestratov --- po/POTFILES.in |2 + tools/Makefile.am|2 + tools/virsh-fsitem.c | 1293 + tools/virsh-fsitem.h | 39 ++

[libvirt] [PATCH RFC v3 02/15] storage pools: functions refactoring

After reusage of all possible storage pool structures we will able to use some storage pool functions. Signed-off-by: Olga Krishtal --- src/Makefile.am | 2 +- src/conf/storage_conf.c | 162 --

[libvirt] [PATCH RFC v3 04/15] FSPool: defining the public API

Provides public API for fspools and item management. Signed-off-by: Nikolay Shirokovskiy Signed-off-by: Maxim Nestratov --- docs/schemas/fsitem.rng | 66 +++ docs/schemas/fspool.rng | 82 ++

[libvirt] [PATCH RFC v3 03/15] storage pools: refactoring of fs backend

The fs backend for storage pools works a lot with directories and etc. The same is true for filesystem pools with directory backend. In order to avoid rewriting the same code once again patch moves this code to virpoolcommon.c. Signed-off-by: Olga Krishtal ---

[libvirt] [PATCH RFC v3 00/15] FSPool: backend directory

Hi everyone, we would like to propose the first implementation of fspool with directory backend according to previous discussions: https://www.redhat.com/archives/libvir-list/2016-April/msg01941.html https://www.redhat.com/archives/libvir-list/2016-May/msg00208.html

[libvirt] [PATCH RFC v3 08/15] FSPool: added --with-fs compilation option

In order to use fspool use --with-fs configuration option. It is is turned off by default. Signed-off-by: Olga Krishtal --- configure.ac | 6 ++ m4/virt-driver-fspool.m4 | 33 + 2 files changed, 39 insertions(+) create

[libvirt] [PATCH for-2.9 14/17] qapi: add static/migration-safe info to query-cpu-model-expansion

On x86, "-cpu host" enables some features that can't be represented by a static CPU model definition: cache info passthrough ("host-cache-info") and PMU passthrough ("pmu"). This means a type=static expansion of "host" can't include those features. A type=full expansion of "host", on the other

[libvirt] [PATCH for-2.9 17/17] target-i386: Implement query-cpu-model-expansion QMP command

Implement query-cpu-model-expansion for target-i386. The code needs to be careful to handle non-migration-safe features ("pmu" and "host-cache-info") according to the expansion type. Cc: libvir-list@redhat.com Cc: Jiri Denemark Signed-off-by: Eduardo Habkost

[libvirt] [PATCH for-2.9 00/17] target-i386: Implement query-cpu-model-expansion

This series implements query-cpu-model-expansion on target-i386. QAPI / interface changes When implementing this, I have noticed that the "host" CPU model in i386 includes some migration-unsafe features that can't be translated to any migration-safe representation:

[libvirt] [PATCH] storage: Fix type PLOOP type check for storageVolUpload

Commit id '03e750f3' added support for checking the PLOOP type; however, it used 'target.type' which no storage code ever fills in, so it will never be set. Change to just vol->type (could use vol->target.format as well). Signed-off-by: John Ferlan --- Found this by chance

Re: [libvirt] [PATCH 0/7] Adjustments for storage/qemu volume/file backing size settings

On 02.12.2016 01:39, John Ferlan wrote: > A bit of a mix between fixing some bugs and merging some code between > the block info/stats fetching of backing store data and storage backend > data for volume allocation, capacity, and physical sizes. > > Patch 1 just adjusts some comments > > Patches

[libvirt] [PATCH RFC v3 15/15] FSPool: Tests and documentation

Patch adds general documentation for fspool and tests for directory backend. Signed-off-by: Olga Krishtal --- docs/formatfs.html.in | 206 + docs/fspool.html.in| 41

[libvirt] [PATCH RFC v3 05/15] FSPool: defining the internal API

This patch introduces new filesystem pool driver. Signed-off-by: Olga Krishtal --- src/driver-fs.h | 193 src/driver.h| 1 + 2 files changed, 194 insertions(+) create mode 100644 src/driver-fs.h diff --git

[libvirt] [PATCH RFC v3 12/15] FSPool: empty implementation of driver methods

Signed-off-by: Olga Krishtal --- daemon/Makefile.am | 4 + daemon/libvirtd.c | 9 + po/POTFILES.in | 1 + src/Makefile.am | 33 ++- src/fs/fs_backend.h | 94 +++ src/fs/fs_driver.c | 729

[libvirt] [PATCH RFC v3 06/15] FSpool: implementing the public API

Implementation of driver API and basic structs defenition Signed-off-by: Olga Krishtal --- include/libvirt/virterror.h |7 + po/POTFILES.in |1 + src/conf/fs_conf.h | 159 + src/datatypes.c | 150 + src/datatypes.h

[libvirt] [PATCH RFC v3 01/15] storage pools: refactoring of basic structs

This is the first patch in fspool patchest. FSPool and storage pools has a lot in common, however we want to have separate drivers for its managment. We want to use almost all storage pool descriptional structures for filesystem pool. All common structs is moved to virpoolcommon.h Signed-off-by:

[libvirt] [PATCH RFC v3 14/15] FSPool: directory backend inplementation

Signed-off-by: Olga Krishtal --- m4/virt-driver-fspool.m4 | 14 ++- po/POTFILES.in | 1 + src/Makefile.am | 10 +- src/fs/fs_backend_dir.c | 290 +++ src/fs/fs_backend_dir.h | 8 ++ src/fs/fs_driver.c

[libvirt] [PATCH RFC v3 07/15] FSPool: added access control objects and permissions

Signed-off-by: Olga Krishtal --- src/access/viraccessdriver.h | 15 + src/access/viraccessdrivernop.c| 21 +++ src/access/viraccessdriverpolkit.c | 47 ++ src/access/viraccessdriverstack.c | 50 +++

[libvirt] [PATCH RFC v3 09/15] FSPool: implementation of remote protocol

Signed-off-by: Olga Krishtal --- daemon/remote.c | 35 src/Makefile.am | 6 +- src/check-driverimpls.pl | 2 + src/remote/remote_driver.c | 66 ++ src/remote/remote_protocol.x | 466

[libvirt] [PATCH RFC v3 10/15] FSPool: added configuration description

Due to reusage of structs and some of functions from storage pools we operate in storage terms. Signed-off-by: Olga Krishtal --- po/POTFILES.in |1 + src/Makefile.am |7 +- src/conf/fs_conf.c | 1479

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

On Fri, 2016-12-02 at 16:50 +1100, David Gibson wrote: > > Uh.. I don't entirely follow you.  From the host point of view there > are multiple iommu groups (PEs), but from the guest point of view > there's only one.  On the guest side iommu granularity is always > per-vPHB. Ok so the H_PUT_TCE