On 5/23/19 11:32 AM, Daniel P. Berrangé wrote:
Introduce a virNetworkPortDefPtr struct to represent the data associated
with a virtual network port. Add APIs for parsing/formatting XML docs
with the data.
Signed-off-by: Daniel P. Berrangé
[...]
+
+networkport
+
On Fri, 2019-05-24 at 17:16 +0200, Fabiano Fidêncio wrote:
> Let's explicitly link against the built libvirt-gconfig, libvirt-glib,
> and libvirt-gobject libtool files for introspecting the gobjects.
>
> In case it's *not* done we can run into some issues when where we try to
> link against
Let's use an autogen.sh based on libosinfo's one, which is cleaner and
matches the current GNOME guidelines.
Signed-off-by: Fabiano Fidêncio
---
.gitignore | 3 +++
autogen.sh | 70 +++---
2 files changed, 28 insertions(+), 45 deletions(-)
diff
Let's use a similiar autogen.sh as the one used by libosinfo and, with
the change, let's also drop our own crafted gtk-doc.make (as we'll be
using gtkdocize to generate the file).
Fabiano Fidêncio (2):
autogen.sh: Simplify autogen.sh
gtk-doc.make: Remove the file
.gitignore | 4 +
Now that we're using gtkdocisze as part of autogen.sh, there's no reason
to keep our own gtk-doc.make file.
Signed-off-by: Fabiano Fidêncio
---
.gitignore | 1 +
gtk-doc.make | 256 ---
2 files changed, 1 insertion(+), 256 deletions(-)
delete
Let's explicitly link against the built libvirt-gconfig, libvirt-glib,
and libvirt-gobject libtool files for introspecting the gobjects.
In case it's *not* done we can run into some issues when where we try to
link against installed library, causing failures related to undefined
reference of the
On Fri, 24 May 2019 12:11:06 +0200
Cornelia Huck wrote:
> On Thu, 23 May 2019 17:20:01 -0600
> Alex Williamson wrote:
>
> > Hi,
> >
> > Currently mediated device management, much like SR-IOV VF management,
> > is largely left as an exercise for the user. This is an attempt to
> > provide
On 5/24/19 1:18 PM, Erik Skultety wrote:
formatdomaincaps.html provides explanation of SEV fields, but doesn't
link to the domain XML docs to show how it can be actually used in
libvirt.
Signed-off-by: Erik Skultety
---
docs/formatdomaincaps.html.in | 17 +
1 file changed,
On 5/23/19 5:59 PM, Daniel P. Berrangé wrote:
When libvirtd is run inside a container it is normal that neither
systemd nor pm-utils will be available. In this case there is no way to
suspend the host, so libvirt should just report the feature unsupported
instead of raising an error.
In near future the storage pool object lock will be released
during startPool and buildPool callback (in some backends). But
this means that another thread may acquire the pool object lock
and change its definition rendering the former thread access not
only stale definition but also access freed
On 5/21/19 1:15 PM, Jiri Denemark wrote:
The libvirt-lock-sanlock subpackage requires sanlock to be installed
first and the sanlock package creates the sanlock group on all distros
we care about in the spec file (Fedora and RHEL >= 7). Thus instead of
setting the ownership and permissions in a
Separate storage pool definition assignment into a function.
Signed-off-by: Michal Privoznik
---
src/conf/virstorageobj.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/src/conf/virstorageobj.c b/src/conf/virstorageobj.c
index 7515b5d107..2b9ad6fc98
This flag can be used to denote that the definition we're trying
to assign to a pool object is live definition and thus the
inactive definition should be saved into ->newDef.
Signed-off-by: Michal Privoznik
---
src/conf/virstorageobj.c | 19 ++-
src/conf/virstorageobj.h | 1 +
https://bugzilla.redhat.com/show_bug.cgi?id=1711789
Starting up or building some types of pools may take a very long
time (e.g. a misconfigured NFS). Holding the pool object locked
throughout the whole time hurts concurrency, e.g. if there's
another thread that is listing all the pools.
There will be more boolean information that we want to pass to
this function. Instead of having them in separate arguments per
each one, use @flags.
Signed-off-by: Michal Privoznik
---
src/conf/virstorageobj.c | 16 +++-
src/conf/virstorageobj.h | 6 +-
If there's a persistent storage and user tries to start a new one
with the same name and UUID (e.g. to test new configuration) it
may happen that upon failure we lose the persistent defintion.
Fortunately, we don't remove it from the disk only from the
internal list of the pools.
Signed-off-by:
There is no need for this function to call
virStoragePoolObjEndAPI(). The object is perfectly usable after
return from this function. In fact, all callers will call
virStoragePoolObjEndAPI() eventually.
Signed-off-by: Michal Privoznik
---
src/storage/storage_driver.c | 13 +
1 file
Turns out there's one callback that might remove a storage pool
during its run: storagePoolUpdateAllState() call
storagePoolUpdateStateCallback() which may call
virStoragePoolUpdateInactive() which in turn may call
virStoragePoolObjRemove(). Problem is that the
UpdateStateCallback() sees a storage
This function is doing much more than plain assigning pool
definition to a pool object. Rename it.
Signed-off-by: Michal Privoznik
---
src/conf/virstorageobj.c | 12 ++--
src/conf/virstorageobj.h | 6 +++---
src/libvirt_private.syms | 2 +-
src/storage/storage_driver.c |
The function comment mistakenly refers to 'poolptr' when in fact
the variable is named 'objptr'.
Signed-off-by: Michal Privoznik
---
src/storage/storage_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
index
The fact that we're removing a pool object from the list of pools
doesn't mean we want to unlock it. It violates locking policy
too as object locking and unlocking is not done on the same
level.
Signed-off-by: Michal Privoznik
---
src/conf/virstorageobj.c | 5 ++---
Patches 02/11, 09/11 and finally 11/11 are actual bug fixes. The
rest is a preparation work. More detailed:
02/11 - Fixes a refcounting issue (and thus invalid memory access)
09/11 - Fixes a problem where starting a transitive pool which
has a persistent config may lead to it's
On Fri, May 24, 2019 at 2:39 PM Ján Tomko wrote:
>
> On Thu, May 23, 2019 at 01:37:01PM +0200, Ilias Stamatis wrote:
> >Begins by writing a @start byte in the first position of @buffer and
> >then for every next byte it stores the value of its previous one
> >incremented by one.
> >
> >Behaves
On Thu, May 23, 2019 at 01:37:01PM +0200, Ilias Stamatis wrote:
Begins by writing a @start byte in the first position of @buffer and
then for every next byte it stores the value of its previous one
incremented by one.
Behaves the same for both supported flags.
Signed-off-by: Ilias Stamatis
Caused by commit 326c3f54.
Signed-off-by: Erik Skultety
---
Travis build: https://travis-ci.org/eskultety/libvirt/builds/536736446
Pushed under the build breaker rule.
src/test/test_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/test/test_driver.c
formatdomaincaps.html provides explanation of SEV fields, but doesn't
link to the domain XML docs to show how it can be actually used in
libvirt.
Signed-off-by: Erik Skultety
---
docs/formatdomaincaps.html.in | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git
On Thu, 23 May 2019 17:20:01 -0600
Alex Williamson wrote:
> Hi,
>
> Currently mediated device management, much like SR-IOV VF management,
> is largely left as an exercise for the user. This is an attempt to
> provide something and see where it goes. I doubt we'll solve
> everyone's needs on
On Thu, May 23, 2019 at 03:07:05PM +0200, Jiri Denemark wrote:
While libvirtd creates this directory with the default 0755 mode, the
spec file stores 0700 in the RPM database. Thus RPM verification always
complains about this directory. Let's fix the spec file to match
reality.
Signed-off-by:
On Thu, May 23, 2019 at 02:50:00PM +0200, Ilias Stamatis wrote:
> Ignore @source in the case of the test driver and return fixed private
> IPv4 addresses for all the interfaces defined in the domain.
>
> Signed-off-by: Ilias Stamatis
> ---
Reviewed-by: Erik Skultety
--
libvir-list mailing list
On Thu, May 23, 2019 at 02:50:01PM +0200, Ilias Stamatis wrote:
> Signed-off-by: Ilias Stamatis
> ---
I think this patch should come first, because e.g. 'domiflist' virsh command
can already make use of the data.
I'll swap the order before pushing.
Reviewed-by: Erik Skultety
>
30 matches
Mail list logo
