[libvirt] [PATCH] src: add missing include access path for bhyve and vz drivers

[Pavel Hrdina]

Commit  forgot to update
bhyve and vz Makefile files as well.

Signed-off-by: Pavel Hrdina 
---

Pushed under build-breaker rule.

 src/bhyve/Makefile.inc.am | 1 +
 src/vz/Makefile.inc.am| 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/bhyve/Makefile.inc.am b/src/bhyve/Makefile.inc.am
index de9fbe9239..1fc100d5ab 100644
--- a/src/bhyve/Makefile.inc.am
+++ b/src/bhyve/Makefile.inc.am
@@ -42,6 +42,7 @@ libvirt_driver_bhyve_la_LDFLAGS = $(AM_LDFLAGS_MOD_NOUNDEF)
 
 libvirt_driver_bhyve_impl_la_CFLAGS = \
-I$(srcdir)/access \
+   -I$(builddir)/access \
-I$(srcdir)/conf \
$(AM_CFLAGS) \
$(NULL)
diff --git a/src/vz/Makefile.inc.am b/src/vz/Makefile.inc.am
index 1757c8ba10..acada11148 100644
--- a/src/vz/Makefile.inc.am
+++ b/src/vz/Makefile.inc.am
@@ -29,6 +29,7 @@ libvirt_driver_vz_la_LDFLAGS = $(AM_LDFLAGS_MOD_NOUNDEF)
 libvirt_driver_vz_impl_la_CFLAGS = \
-I$(srcdir)/conf \
-I$(srcdir)/access \
+   -I$(builddir)/access \
$(AM_CFLAGS) \
$(PARALLELS_SDK_CFLAGS) \
$(LIBNL_CFLAGS) \
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 0/2] qemu: fix type of default video device

[Pavel Mores]

Hi,

could someone please take a look at this so that I can move on with it?

Thanks,

pvl

On Fri, Oct 18, 2019 at 12:27:20PM +0200, Pavel Mores wrote:
> This new version mostly integrates Cole's comments about the first version.
> 
> Pavel Mores (2):
>   qemu: fix type of default video device
>   qemu: add tests of the default video type selection algorithm
> 
>  src/qemu/qemu_domain.c| 39 +++--
>  .../default-video-type-aarch64.xml| 16 +++
>  .../default-video-type-ppc64.xml  | 16 +++
>  .../default-video-type-riscv64.xml| 16 +++
>  .../default-video-type-s390x.xml  | 16 +++
>  .../default-video-type-x86_64-caps-test-0.xml | 17 
>  .../default-video-type-x86_64-caps-test-1.xml | 17 
>  tests/qemuxml2argvtest.c  |  1 +
>  ...ault-video-type-aarch64.aarch64-latest.xml | 42 +++
>  .../default-video-type-ppc64.ppc64-latest.xml | 31 ++
>  ...ault-video-type-riscv64.riscv64-latest.xml | 39 +
>  .../default-video-type-s390x.s390x-latest.xml | 32 ++
>  .../default-video-type-x86_64-caps-test-0.xml | 31 ++
>  .../default-video-type-x86_64-caps-test-1.xml | 31 ++
>  tests/qemuxml2xmltest.c   | 10 -
>  15 files changed, 341 insertions(+), 13 deletions(-)
>  create mode 100644 tests/qemuxml2argvdata/default-video-type-aarch64.xml
>  create mode 100644 tests/qemuxml2argvdata/default-video-type-ppc64.xml
>  create mode 100644 tests/qemuxml2argvdata/default-video-type-riscv64.xml
>  create mode 100644 tests/qemuxml2argvdata/default-video-type-s390x.xml
>  create mode 100644 
> tests/qemuxml2argvdata/default-video-type-x86_64-caps-test-0.xml
>  create mode 100644 
> tests/qemuxml2argvdata/default-video-type-x86_64-caps-test-1.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/default-video-type-aarch64.aarch64-latest.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/default-video-type-ppc64.ppc64-latest.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/default-video-type-riscv64.riscv64-latest.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/default-video-type-s390x.s390x-latest.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/default-video-type-x86_64-caps-test-0.xml
>  create mode 100644 
> tests/qemuxml2xmloutdata/default-video-type-x86_64-caps-test-1.xml
> 
> -- 
> 2.21.0
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2] Add python3-docutils package for libvirt

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 06:08:06PM +0100, Andrea Bolognani wrote:
> On Fri, 2019-11-08 at 14:29 +, Daniel P. Berrangé wrote:
> > This is needed to acquire the rst2html command line tool
> > 
> > Signed-off-by: Daniel P. Berrangé 
> > ---
> >  guests/vars/mappings.yml | 5 +
> >  guests/vars/projects/libvirt.yml | 1 +
> >  2 files changed, 6 insertions(+)
> 
> Reviewed-by: Andrea Bolognani 
> 
> Do you have other patches you think you might want to get in shortly,
> or should I generate new container images once this has been merged?

Nothing pending. Just pushed this.

> Also note that, while everywhere else the command name is rst2html,
> on CentOS 7 we have to invoke it as rst2html-3... This means patch
> 3/6 of your other series will need changes.

Ugh, annoying :-(

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH v2] Add python3-docutils package for libvirt

[Andrea Bolognani]

On Fri, 2019-11-08 at 14:29 +, Daniel P. Berrangé wrote:
> This is needed to acquire the rst2html command line tool
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  guests/vars/mappings.yml | 5 +
>  guests/vars/projects/libvirt.yml | 1 +
>  2 files changed, 6 insertions(+)

Reviewed-by: Andrea Bolognani 

Do you have other patches you think you might want to get in shortly,
or should I generate new container images once this has been merged?

Also note that, while everywhere else the command name is rst2html,
on CentOS 7 we have to invoke it as rst2html-3... This means patch
3/6 of your other series will need changes.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/5] news: Support unmanaged macvtap devices in 5.8

[Laine Stump]

On 11/8/19 2:00 AM, Han Han wrote:

Signed-off-by: Han Han 
---
  docs/news.xml | 12 
  1 file changed, 12 insertions(+)

diff --git a/docs/news.xml b/docs/news.xml
index 88affb66a3..c0fd006a77 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -189,6 +189,18 @@
  


+
+  
+
+  qemu: Support unmanaged macvtap devices
+
+
+  Add new "managed" attribute for target dev of
+  interface type=ethernet to control
+  whether using an existing macvtap device.
+
+  
+
  

  



I already have a patch for this that I'm about to push that has a "more 
descriptive description" :-).


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 00/20] cleanup current build system

[Laine Stump]

make rpm is now broken. I'm making a rash assumption something in this 
series is the cause (if I have time in the morning I'll investigate further)


+ /usr/bin/mkdir -p 
/home/laine/rpmbuild/BUILDROOT/libvirt-5.10.0-1.fc30.x86_64/usr/share/doc/libvirt-docs
+ cp -pr AUTHORS 
/home/laine/rpmbuild/BUILDROOT/libvirt-5.10.0-1.fc30.x86_64/usr/share/doc/libvirt-docs+ 
cp -pr ChangeLog 
/home/laine/rpmbuild/BUILDROOT/libvirt-5.10.0-1.fc30.x86_64/usr/share/doc/libvirt-docs
+ cp -pr NEWS 
/home/laine/rpmbuild/BUILDROOT/libvirt-5.10.0-1.fc30.x86_64/usr/share/doc/libvirt-docs
+ cp -pr README 
/home/laine/rpmbuild/BUILDROOT/libvirt-5.10.0-1.fc30.x86_64/usr/share/doc/libvirt-docs
+ cp -pr README.md 
/home/laine/rpmbuild/BUILDROOT/libvirt-5.10.0-1.fc30.x86_64/usr/share/doc/libvirt-docs
+ cp -pr 'libvirt-docs/*' 
/home/laine/rpmbuild/BUILDROOT/libvirt-5.10.0-1.fc30.x86_64/usr/share/doc/libvirt-docs

cp: cannot stat 'libvirt-docs/*': No such file or directory

On 11/8/19 10:42 AM, Pavel Hrdina wrote:

As preparation to switch to Meson there are some things that needs be
cleaned up to make the conversion easier.

The important thing in Meson is that there is a strict separation
between source and build directory and the distributed tarball by
default contains only files tracked by git with a possibility to
write a script which would add some other sources into the tarball.

Regardless of the adoption of Meson these patches improve our current
build system to fully support VPATH builds.

Changes in v2:
 - some patches from v1 are pushed now
 - added a patch to mandate build dir != src dir
 - added a patch to cleanup .gitignore
 - added patches to fix sc_po_check
 - improved some patches from v1

Changes in v3:
 - python-zanata-client is the tool our Makefile uses

Pavel Hrdina (20):
   build: mandate use of a build dir != src dir
   .gitignore: cleanup old and obsolete ignores
   syntax-check.mk: fix sc_po_check rule
   syntax-check.mk: cleanup sc_po_check dependencies
   syntax-check.mk: cleanup generated_files list for sc_po_check
   po: generate files into build directory
   po: rewrite the way how we generate files
   po: README.md: add a note about which Zanata client is required
   remote: unify rpc server dispatch generated files
   src: generate source files into build directory
   src: access: generate source files into build directory
   src: admin: generate source files into build directory
   src: esx: generate source files into build directory
   src: hyperv: generate source files into build directory
   src: locking: generate source files into build directory
   src: logging: generate source files into build directory
   src: lxc: generate source files into build directory
   src: remote: generate source files into build directory
   src: stop distributing generated source files
   tools: stop distributing generated source files

  .gitignore  | 276 ++---
  .travis.yml |   3 +-
  README-hacking  |  11 +-
  README.md   |  11 +-
  bootstrap.conf  |   6 +
  build-aux/syntax-check.mk   |  47 ++--
  configure.ac|   6 +
  docs/compiling.html.in  |  10 +-
  docs/windows.html.in|   3 +-
  libvirt.spec.in |  10 +-
  po/Makefile.am  |  45 ++--
  po/POTFILES | 320 -
  po/POTFILES.in  | 356 
  po/README.md|   3 +
  src/Makefile.am |  13 +-
  src/access/Makefile.inc.am  |  17 +-
  src/admin/Makefile.inc.am   |  24 +-
  src/bhyve/Makefile.inc.am   |   1 +
  src/esx/Makefile.inc.am |   9 +-
  src/esx/esx_vi_generator.py |  11 +-
  src/hyperv/Makefile.inc.am  |   9 +-
  src/hyperv/hyperv_wmi_generator.py  |  11 +-
  src/interface/Makefile.inc.am   |   2 +
  src/libxl/Makefile.inc.am   |   2 +
  src/locking/Makefile.inc.am |  16 +-
  src/logging/Makefile.inc.am |  18 +-
  src/lxc/Makefile.inc.am |  36 ++-
  src/network/Makefile.inc.am |   2 +
  src/node_device/Makefile.inc.am |   2 +
  src/nwfilter/Makefile.inc.am|   2 +
  src/qemu/Makefile.inc.am|   2 +
  src/remote/Makefile.inc.am  |  45 ++--
  src/remote/remote_daemon_dispatch.c |   4 +-
  src/rpc/Makefile.inc.am |   8 +-
  src/secret/Makefile.inc.am  |   2 +
  src/storage/Makefile.inc.am |   2 +
  src/util/Makefile.inc.am|   6 +-
  src/vbox/Makefile.inc.am|   1 +
  src/vz/Makefile.inc.am  |   1 +
  tests/Makefile.am   |   4 +
  tools/Makefile.am   |   1 -
  41 files changed, 636 insertions(+), 722 deletions(-)
  delete mode 100644 po/POTFILES
  create mode 100644 

Re: [libvirt] [PATCH v2] Add API to change qemu agent response timeout

[Jonathon Jongsma]

Thanks for the thorough review Michal, clearly it needs more work. In
particular, I was not yet aware of the private xml save/restore stuff.
Thanks for the pointers in that regard. But I have one particular
question below:

On Fri, 2019-11-08 at 11:46 +0100, Michal Privoznik wrote:
> 1: It's not that simple. Firstly, you need to grab an agent job 
> (QEMU_AGENT_JOB_MODIFY ideally) to make sure no other thread is in
> the 
> middle of talking to the agent. Secondly, some domains may not have
> an 
> agent configured at all (in which case, priv->agent is going to be 
> NULL). And lastly, we need to track the timeout set in domain
> private 
> data so that if libvirtd restarts the same timeout is preserved. But 
> changing private data means you have to acquire domain job too.


Is this really true? I'm obviously still not intimately familiar with
the libvirt 'job' stuff, but my understanding of jobs is that it is a
method to avoid multiple threads talking to the qemu monitor (or agent,
for agent jobs) at the same time. The data integrity of the structs
themselves are protected by mutex. But a mutex is insufficient to
mediate access to the monitor/agent because waiting for a response may
involve a sleep, and the mutex will be released while the thread
sleeps. So this 'job' system was added on top to indicate that the
monitor/agent was in use and other threads need to wait until the job
is complete before they can interact with the monitor or agent. Is my
understanding correct so far?

In this situation, we're not talking to the qemu monitor or the agent,
we're merely changing some struct data. So from a data-integrity point
of view, we simply need to hold the mutex lock, right? (We do hold the
mutex lock for the domain from calling qemuDomainObjFromDomain()). So
it doesn't seem strictly necessary to acquire a job here (either for
the agent, or for the domain/monitor). 

One argument I can see for acquiring a job here is that it ensures that
any private data is not changed while another thread is in the middle
of a monitor query. And that's potentially a compelling justification
for acquiring a job. But in this circumstance, I don't see that it
gains us much.

For example, let's say Thread A has already acquired an agent job for
getHostname(). This thread will call qemuAgentCommand() and pass the
value of mon->timeout for the 'seconds' argument. Inside this function,
it will further call qemuAgentGuestSync(), which again uses the mon-
>timeout value to determine how long it should wait for a response. It
sends the guest-sync command to the guest agent, and then waits for a
response (releasing the mutex). While it is waiting, let's say that
Thread B calls SetResponseTimeout(). Let's further imagine that
SetResponseTimeout() doesn't acquire a job (as in my patch). It can
acquire the agent mutex (since the other thread released it while
sleeping) and safely change the mon->timeout value immediately. At some
point, Thread A wakes up, handles the guest-sync response and issues
the 'guest-get-host-name' command to the agent. It uses the value
passed as an argument to qemuAgentCommand() to determine how long to
wait for a response from the agent. So it will not use the new value
set by thread B, but will use the old value that was set when it was
first called. (But I think an argument could be made that it would be
fine to use this new timeout value as well.)

This behavior all seems fine to me. Am I misunderstanding something
fundamentally here? Or is there just a general policy that all data
modification should be protected by a job, regardless of whether we're
using the qemu monitor or agent? If so, perhaps that could be better
documented.

One final concern: in your fixup commit, you acquire both a normal
domain job and an agent job (in the case where the agent is active).
But this is something I've been working to remove from libvirt after a
discussion with Daniel Berrange in 
https://bugzilla.redhat.com/show_bug.cgi?id=1759566

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 07/20] [ACKED] po: rewrite the way how we generate files

[Pavel Hrdina]

There was no need to handle files for translation from build directory
but that will change with following patches where we will stop
generating source files into source directory.

In order to have them included for translation we have to prefix each
file with SRCDIR or BUILDDIR.

Signed-off-by: Pavel Hrdina 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- add builddir paths for sc_po_check to detect generated source
  files and generate correct diff if the check fails

 build-aux/syntax-check.mk |   8 +-
 po/Makefile.am|  14 +-
 po/POTFILES   | 352 --
 po/POTFILES.in| 352 ++
 4 files changed, 367 insertions(+), 359 deletions(-)
 delete mode 100644 po/POTFILES
 create mode 100644 po/POTFILES.in

diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 985739b373..75993ee284 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -56,6 +56,7 @@ VC_LIST_ALWAYS_EXCLUDE_REGEX ?= ^$$
 # when $(srcdir) is a pathological name like "", the leading sed command
 # removes only the intended prefix.
 _dot_escaped_srcdir = $(subst .,\.,$(srcdir))
+_dot_escaped_builddir = $(subst .,\.,$(builddir))
 
 # Post-process $(VC_LIST) output, prepending $(srcdir)/, but only
 # when $(srcdir) is not ".".
@@ -1968,11 +1969,13 @@ perl_translatable_files_list_ = 
\
 
 # Verify that all source files using _() (more specifically, files that
 # match $(_gl_translatable_string_re)) are listed in po/POTFILES.in.
-po_file ?= $(srcdir)/po/POTFILES
+po_file ?= $(srcdir)/po/POTFILES.in
 
 # List of additional files that we want to pick up in our POTFILES.in
 # This is all gnulib files, as well as generated files for RPC code.
 generated_files = \
+  $(builddir)/src/*.[ch] \
+  $(builddir)/src/*/*.[ch] \
   
$(srcdir)/src/*/{remote_daemon,admin_server,log_daemon,lock_daemon}_dispatch_*stubs.h
 \
   $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
   $(srcdir)/src/remote/*_client_bodies.h \
@@ -1989,7 +1992,8 @@ sc_po_check: gen_source_files
  { $(VC_LIST_EXCEPT); echo $(generated_files); }   \
| xargs perl $(perl_translatable_files_list_)   \
| xargs $(GREP) -E -l '$(_gl_translatable_string_re)'   \
-   | $(SED) 's|^$(_dot_escaped_srcdir)/||' \
+   | $(SED) 's|^$(_dot_escaped_srcdir)|@SRCDIR@|'  \
+   | $(SED) 's|^$(_dot_escaped_builddir)|@BUILDDIR@|'  \
| sort -u > $@-2;   \
  diff -u -L $(po_file) -L $(po_file) $@-1 $@-2 \
|| { printf '$(ME): '$(fix_po_file_diag) 1>&2; exit 1; };   \
diff --git a/po/Makefile.am b/po/Makefile.am
index 89e831f839..443d8a4dc1 100644
--- a/po/Makefile.am
+++ b/po/Makefile.am
@@ -15,16 +15,21 @@ LANGS := \
uk ur vi wba yo zh_CN zh_HK zh_TW zu
 
 
-POTFILE_DEPS := $(shell $(SED) 's,^,$(top_srcdir)/,' $(srcdir)/POTFILES)
+POTFILES_IN = $(srcdir)/POTFILES.in
+POTFILES: $(POTFILES_IN)
+   $(AM_V_GEN) cat $(POTFILES_IN) | \
+   $(SED) 's|[@]SRCDIR[@]|$(top_srcdir)|' | \
+   $(SED) 's|[@]BUILDDIR[@]|$(top_builddir)|' > $@
+POTFILE_DEPS = $(shell cat POTFILES)
 POTFILE := $(DOMAIN).pot
 POMINIFILES := $(LANGS:%=%.mini.po)
 POFILES := $(LANGS:%=%.po)
 GMOFILES := $(LANGS:%=%.gmo)
 
-CLEANFILES = $(POTFILE) $(POFILES) $(GMOFILES)
+CLEANFILES = $(POTFILE) $(POFILES) $(GMOFILES) POTFILES
 
 EXTRA_DIST = \
-   POTFILES \
+   $(POTFILES_IN) \
$(POMINIFILES)
 
 if HAVE_GNU_GETTEXT_TOOLS
@@ -38,7 +43,6 @@ XGETTEXT_ARGS = \
--package-name="$(PACKAGE_NAME)" \
--package-version="$(PACKAGE_VERSION)" \
--msgid-bugs-address="$(MSGID_BUGS_ADDRESS)" \
-   --directory=$(top_srcdir) \
$(NULL)
 
 SED_PO_FIXUP_ARGS = \
@@ -79,7 +83,7 @@ pull-po: $(POTFILE)
 
 $(POTFILE): POTFILES $(POTFILE_DEPS)
$(XGETTEXT) -o $@-t $(XGETTEXT_ARGS) \
- --files-from=$(abs_srcdir)/POTFILES
+ --files-from=$(abs_builddir)/POTFILES
$(SED) $(SED_PO_FIXUP_ARGS) < $@-t > $@
rm -f $@-t
 
diff --git a/po/POTFILES b/po/POTFILES
deleted file mode 100644
index 217d7e2006..00
--- a/po/POTFILES
+++ /dev/null
@@ -1,352 +0,0 @@
-gnulib/lib/gai_strerror.c
-gnulib/lib/regcomp.c
-src/access/viraccessdriverpolkit.c
-src/access/viraccessmanager.c
-src/admin/admin_server.c
-src/admin/admin_server_dispatch.c
-src/admin/admin_server_dispatch_stubs.h
-src/admin/libvirt-admin.c
-src/bhyve/bhyve_capabilities.c
-src/bhyve/bhyve_command.c
-src/bhyve/bhyve_device.c
-src/bhyve/bhyve_domain.c
-src/bhyve/bhyve_driver.c
-src/bhyve/bhyve_monitor.c
-src/bhyve/bhyve_parse_command.c
-src/bhyve/bhyve_process.c
-src/conf/capabilities.c
-src/conf/checkpoint_conf.c
-src/conf/cpu_conf.c
-src/conf/device_conf.c

[libvirt] [PATCH v4 20/20] [ACKED] tools: stop distributing generated source files

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---
 tools/Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/Makefile.am b/tools/Makefile.am
index 68320c7246..1a541a3984 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -84,7 +84,6 @@ EXTRA_DIST = \
bash-completion/vsh \
libvirt_recover_xattrs.sh \
$(PODFILES) \
-   $(MANINFILES) \
$(NULL)
 
 
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 19/20] [ACKED] src: stop distributing generated source files

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---
 src/Makefile.am |  6 +++---
 src/access/Makefile.inc.am  |  3 ++-
 src/admin/Makefile.inc.am   | 13 +++--
 src/bhyve/Makefile.inc.am   |  1 +
 src/esx/Makefile.inc.am |  4 +---
 src/hyperv/Makefile.inc.am  |  4 +---
 src/interface/Makefile.inc.am   |  1 +
 src/libxl/Makefile.inc.am   |  1 +
 src/locking/Makefile.inc.am |  8 +---
 src/logging/Makefile.inc.am | 12 +++-
 src/lxc/Makefile.inc.am | 27 ++-
 src/network/Makefile.inc.am |  1 +
 src/node_device/Makefile.inc.am |  1 +
 src/nwfilter/Makefile.inc.am|  1 +
 src/qemu/Makefile.inc.am|  1 +
 src/remote/Makefile.inc.am  | 20 
 src/rpc/Makefile.inc.am |  5 -
 src/secret/Makefile.inc.am  |  1 +
 src/storage/Makefile.inc.am |  1 +
 src/util/Makefile.inc.am|  6 --
 src/vbox/Makefile.inc.am|  1 +
 src/vz/Makefile.inc.am  |  1 +
 22 files changed, 75 insertions(+), 44 deletions(-)

diff --git a/src/Makefile.am b/src/Makefile.am
index da7e2e6c80..4a0c121a7d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -655,13 +655,13 @@ endif WITH_LIBVIRTD
< $< > $@-t && \
mv $@-t $@
 
-CLEANFILES += $(man8_MANS)
-MAINTAINERCLEANFILES += $(MANINFILES)
+CLEANFILES += \
+   $(man8_MANS) \
+   $(MANINFILES)
 
 EXTRA_DIST += \
 $(SYSTEMD_UNIT_FILES_IN) \
 $(PODFILES) \
-$(MANINFILES) \
 $(NULL)
 
 
diff --git a/src/access/Makefile.inc.am b/src/access/Makefile.inc.am
index 2d871ec8aa..fd0a5d8098 100644
--- a/src/access/Makefile.inc.am
+++ b/src/access/Makefile.inc.am
@@ -43,13 +43,14 @@ ACCESS_DRIVER_POLKIT_POLICY = access/org.libvirt.api.policy
 GENERATED_SYM_FILES += $(ACCESS_DRIVER_SYM_FILES)
 
 EXTRA_DIST += \
-   $(ACCESS_DRIVER_POLKIT_POLICY) \
access/genpolkit.pl \
$(NULL)
 
 
 libvirt_driver_access_la_SOURCES = \
$(ACCESS_DRIVER_SOURCES) \
+   $(NULL)
+nodist_libvirt_driver_access_la_SOURCES = \
$(ACCESS_DRIVER_GENERATED) \
$(NULL)
 noinst_LTLIBRARIES += libvirt_driver_access.la
diff --git a/src/admin/Makefile.inc.am b/src/admin/Makefile.inc.am
index 448f7e1203..3feb23aa20 100644
--- a/src/admin/Makefile.inc.am
+++ b/src/admin/Makefile.inc.am
@@ -9,22 +9,21 @@ ADMIN_PROTOCOL_GENERATED = \
admin/admin_server_dispatch_stubs.h \
$(NULL)
 
-EXTRA_DIST += $(ADMIN_PROTOCOL) $(ADMIN_PROTOCOL_GENERATED)
+EXTRA_DIST += $(ADMIN_PROTOCOL)
 BUILT_SOURCES += $(ADMIN_PROTOCOL_GENERATED)
-MAINTAINERCLEANFILES += $(ADMIN_PROTOCOL_GENERATED)
+CLEANFILES += $(ADMIN_PROTOCOL_GENERATED)
 
 admin/admin_server_dispatch.c: admin/admin_server_dispatch_stubs.h
 
 noinst_LTLIBRARIES += libvirt_driver_admin.la
 libvirt_driver_admin_la_SOURCES = \
-   admin/admin_protocol.c \
-   admin/admin_protocol.h \
admin/admin_server.c \
admin/admin_server.h \
admin/admin_server_dispatch.c \
admin/admin_server_dispatch.h \
-   admin/admin_server_dispatch_stubs.h \
$(NULL)
+nodist_libvirt_driver_admin_la_SOURCES = \
+   $(ADMIN_PROTOCOL_GENERATED)
 libvirt_driver_admin_la_CFLAGS = \
$(AM_CFLAGS) \
$(XDR_CFLAGS) \
@@ -60,9 +59,11 @@ lib_LTLIBRARIES += libvirt-admin.la
 
 libvirt_admin_la_SOURCES = \
admin/libvirt-admin.c \
-   $(ADMIN_PROTOCOL_GENERATED) \
$(DATATYPES_SOURCES)
 
+nodist_libvirt_admin_la_SOURCES = \
+   $(ADMIN_PROTOCOL_GENERATED)
+
 libvirt_admin_la_LDFLAGS = \
$(VERSION_SCRIPT_FLAGS)$(LIBVIRT_ADMIN_SYMBOL_FILE) \
-version-info $(LIBVIRT_VERSION_INFO) \
diff --git a/src/bhyve/Makefile.inc.am b/src/bhyve/Makefile.inc.am
index 96ae2f5044..de9fbe9239 100644
--- a/src/bhyve/Makefile.inc.am
+++ b/src/bhyve/Makefile.inc.am
@@ -56,6 +56,7 @@ augeastest_DATA += bhyve/test_virtbhyved.aug
 CLEANFILES += bhyve/virtbhyved.aug
 
 virtbhyved_SOURCES = $(REMOTE_DAEMON_SOURCES)
+nodist_virtbhyved_SOURCES = $(REMOTE_DAEMON_GENERATED)
 virtbhyved_CFLAGS = \
$(REMOTE_DAEMON_CFLAGS) \
-DDAEMON_NAME="\"virtbhyved\"" \
diff --git a/src/esx/Makefile.inc.am b/src/esx/Makefile.inc.am
index 7ba9fd1758..6b10755b7e 100644
--- a/src/esx/Makefile.inc.am
+++ b/src/esx/Makefile.inc.am
@@ -44,7 +44,6 @@ ESX_DRIVER_EXTRA_DIST = \
esx/README \
esx/esx_vi_generator.input \
esx/esx_vi_generator.py \
-   $(ESX_DRIVER_GENERATED) \
$(NULL)
 
 ESX_GENERATED_STAMP = .esx_vi_generator.stamp
@@ -54,7 +53,6 @@ DRIVER_SOURCE_FILES += $(ESX_DRIVER_SOURCES)
 EXTRA_DIST += \
$(ESX_DRIVER_SOURCES) \
$(ESX_DRIVER_EXTRA_DIST) \
-   $(ESX_GENERATED_STAMP) \
$(NULL)
 
 BUILT_SOURCES += $(ESX_DRIVER_GENERATED)
@@ -66,7 +64,7 @@ $(ESX_GENERATED_STAMP): $(srcdir)/esx/esx_vi_generator.input \
$(AM_V_GEN) $(RUNUTF8) $(PYTHON) \

[libvirt] [PATCH v4 04/20] [ACKED] syntax-check.mk: cleanup sc_po_check dependencies

[Pavel Hrdina]

Introduce new rule 'generated-sources' as a helper for PO files check
to make sure that all generated files are prepared and to not duplicate
the list on different places.  This will be used as a dependency for
sc_po_check rule instead of duplicated list of generated files.

Signed-off-by: Pavel Hrdina 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
New in v2.

 build-aux/syntax-check.mk | 25 ++---
 src/Makefile.am   |  3 +++
 2 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 5890f4737f..6acda4eea3 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1953,6 +1953,9 @@ sc_m4_quote_check:
halt='quote the first arg to AC_DEF*'   \
  $(_sc_search_regexp)
 
+gen_source_files:
+   $(MAKE) -C src generated-sources
+
 fix_po_file_diag = \
 'you have changed the set of files with translatable diagnostics;\n\
 apply the above patch\n'
@@ -1977,7 +1980,9 @@ perl_translatable_files_list_ =   
\
 po_file ?= $(srcdir)/po/POTFILES
 generated_files ?= $(srcdir)/lib/*.[ch]
 _gl_translatable_string_re ?= \b(N?_|gettext *)\([^)"]*("|$$)
-sc_po_check:
+
+# sc_po_check can fail if generated files are not built first
+sc_po_check: gen_source_files
@if test -f $(po_file); then\
  $(GREP) -E -v '^(#|$$)' $(po_file)\
| $(GREP) -v '^src/false\.c$$' | sort > $@-1;   \
@@ -2160,24 +2165,6 @@ test-wrap-argv:
 group-qemu-caps:
$(AM_V_GEN)$(PERL) $(top_srcdir)/tests/group-qemu-caps.pl --check 
$(top_srcdir)/
 
-# sc_po_check can fail if generated files are not built first
-sc_po_check: \
-   $(srcdir)/src/remote/remote_daemon_dispatch_stubs.h \
-   $(srcdir)/src/remote/remote_daemon_dispatch_qemu_stubs.h \
-   $(srcdir)/src/remote/remote_client_bodies.h \
-   $(srcdir)/src/admin/admin_server_dispatch_stubs.h \
-   $(srcdir)/src/admin/admin_client.h
-$(srcdir)/src/remote/remote_daemon_dispatch_stubs.h: 
$(srcdir)/src/remote/remote_protocol.x
-   $(MAKE) -C src remote/remote_daemon_dispatch_stubs.h
-$(srcdir)/src/remote/remote_daemon_dispatch_qemu_stubs.h: 
$(srcdir)/src/remote/qemu_protocol.x
-   $(MAKE) -C src remote/remote_daemon_dispatch_qemu_stubs.h
-$(srcdir)/src/remote/remote_client_bodies.h: 
$(srcdir)/src/remote/remote_protocol.x
-   $(MAKE) -C src remote/remote_client_bodies.h
-$(srcdir)/src/admin/admin_server_dispatch_stubs.h: 
$(srcdir)/src/admin/admin_protocol.x
-   $(MAKE) -C src admin/admin_server_dispatch_stubs.h
-$(srcdir)/src/admin/admin_client.h: $(srcdir)/src/admin/admin_protocol.x
-   $(MAKE) -C src admin/admin_client.h
-
 # List all syntax-check exemptions:
 exclude_file_name_regexp--sc_avoid_strcase = ^tools/vsh\.h$$
 
diff --git a/src/Makefile.am b/src/Makefile.am
index ebc24610e2..e0b917fcdd 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -717,6 +717,9 @@ libvirt_iohelper_CFLAGS = \
 endif WITH_LIBVIRTD
 
 
+generated-sources: $(BUILT_SOURCES)
+
+
 install-data-local: $(INSTALL_DATA_LOCAL) \
$(INSTALL_DATA_DIRS:%=install-data-%)
$(MKDIR_P) "$(DESTDIR)$(localstatedir)/cache/libvirt"
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 15/20] [ACKED] src: locking: generate source files into build directory

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore
- modify generated_files for sc_po_check as well

 .gitignore  | 1 -
 build-aux/syntax-check.mk   | 2 +-
 src/locking/Makefile.inc.am | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 85a417112d..ed11b77921 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,7 +41,6 @@ Makefile.in
 # libvirt related ignores
 /build/
 /ci/scratch/
-/src/locking/lock_daemon_dispatch_stubs.h
 /src/logging/log_daemon_dispatch_stubs.h
 /src/lxc/lxc_controller_dispatch.h
 /src/lxc/lxc_monitor_dispatch.h
diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index cf60e890d2..62fe528c75 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1976,7 +1976,7 @@ po_file ?= $(srcdir)/po/POTFILES.in
 generated_files = \
   $(builddir)/src/*.[ch] \
   $(builddir)/src/*/*.[ch] \
-  $(srcdir)/src/*/{remote,qemu,lxc,log,lock}_daemon_dispatch_stubs.h \
+  $(srcdir)/src/*/{remote,qemu,lxc,log}_daemon_dispatch_stubs.h \
   $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
   $(srcdir)/src/remote/*_client_bodies.h \
   $(srcdir)/gnulib/lib/*.[ch]
diff --git a/src/locking/Makefile.inc.am b/src/locking/Makefile.inc.am
index ba7a9ea2ea..2bfb662016 100644
--- a/src/locking/Makefile.inc.am
+++ b/src/locking/Makefile.inc.am
@@ -280,7 +280,7 @@ locking/lock_daemon_dispatch_stubs.h: $(LOCK_PROTOCOL) \
$(srcdir)/rpc/gendispatch.pl Makefile.am
$(AM_V_GEN)perl -w $(srcdir)/rpc/gendispatch.pl --mode=server \
virLockSpaceProtocol VIR_LOCK_SPACE_PROTOCOL \
-   $(LOCK_PROTOCOL) > $(srcdir)/locking/lock_daemon_dispatch_stubs.h
+   $(LOCK_PROTOCOL) > locking/lock_daemon_dispatch_stubs.h
 
 
 virtlockd.service: locking/virtlockd.service.in $(top_builddir)/config.status
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 16/20] [ACKED] src: logging: generate source files into build directory

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore
- modify generated_files for sc_po_check as well

 .gitignore  | 1 -
 build-aux/syntax-check.mk   | 2 +-
 src/logging/Makefile.inc.am | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index ed11b77921..eaad5a1883 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,7 +41,6 @@ Makefile.in
 # libvirt related ignores
 /build/
 /ci/scratch/
-/src/logging/log_daemon_dispatch_stubs.h
 /src/lxc/lxc_controller_dispatch.h
 /src/lxc/lxc_monitor_dispatch.h
 /src/remote/*_client_bodies.h
diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 62fe528c75..a7e87e7a81 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1976,7 +1976,7 @@ po_file ?= $(srcdir)/po/POTFILES.in
 generated_files = \
   $(builddir)/src/*.[ch] \
   $(builddir)/src/*/*.[ch] \
-  $(srcdir)/src/*/{remote,qemu,lxc,log}_daemon_dispatch_stubs.h \
+  $(srcdir)/src/*/{remote,qemu,lxc}_daemon_dispatch_stubs.h \
   $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
   $(srcdir)/src/remote/*_client_bodies.h \
   $(srcdir)/gnulib/lib/*.[ch]
diff --git a/src/logging/Makefile.inc.am b/src/logging/Makefile.inc.am
index bb7ea7338d..dbaac2bb0d 100644
--- a/src/logging/Makefile.inc.am
+++ b/src/logging/Makefile.inc.am
@@ -127,7 +127,7 @@ logging/log_daemon_dispatch_stubs.h: $(LOG_PROTOCOL) \
$(srcdir)/rpc/gendispatch.pl Makefile.am
$(AM_V_GEN)perl -w $(srcdir)/rpc/gendispatch.pl --mode=server \
virLogManagerProtocol VIR_LOG_MANAGER_PROTOCOL \
-   $(LOG_PROTOCOL) > $(srcdir)/logging/log_daemon_dispatch_stubs.h
+   $(LOG_PROTOCOL) > logging/log_daemon_dispatch_stubs.h
 
 virtlogd.8.in: logging/virtlogd.pod
$(AM_V_GEN)$(POD2MAN) --section=8 $< $@-t1 && \
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 18/20] [ACKED] src: remote: generate source files into build directory

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore
- modify generated_files for sc_po_check as well

 .gitignore |  2 --
 build-aux/syntax-check.mk  |  2 --
 po/POTFILES.in |  4 ++--
 src/remote/Makefile.inc.am | 12 ++--
 4 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/.gitignore b/.gitignore
index 38d6637c1c..2d6e3e3194 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,6 +41,4 @@ Makefile.in
 # libvirt related ignores
 /build/
 /ci/scratch/
-/src/remote/*_client_bodies.h
-/src/remote/*_stubs.h
 tags
diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 392fc34320..ab9ba33c9c 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1976,8 +1976,6 @@ po_file ?= $(srcdir)/po/POTFILES.in
 generated_files = \
   $(builddir)/src/*.[ch] \
   $(builddir)/src/*/*.[ch] \
-  $(srcdir)/src/*/{remote,qemu,lxc}_daemon_dispatch_stubs.h \
-  $(srcdir)/src/remote/*_client_bodies.h \
   $(srcdir)/gnulib/lib/*.[ch]
 
 _gl_translatable_string_re ?= \b(N?_|gettext *)\([^)"]*("|$$)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index ebd86a6cd3..de6e5ec0d9 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -3,6 +3,8 @@
 @BUILDDIR@/src/access/viraccessapicheckqemu.c
 @BUILDDIR@/src/admin/admin_client.h
 @BUILDDIR@/src/admin/admin_server_dispatch_stubs.h
+@BUILDDIR@/src/remote/remote_client_bodies.h
+@BUILDDIR@/src/remote/remote_daemon_dispatch_stubs.h
 @SRCDIR@/gnulib/lib/gai_strerror.c
 @SRCDIR@/gnulib/lib/regcomp.c
 @SRCDIR@/src/access/viraccessdriverpolkit.c
@@ -167,11 +169,9 @@
 @SRCDIR@/src/qemu/qemu_tpm.c
 @SRCDIR@/src/qemu/qemu_vhost_user.c
 @SRCDIR@/src/qemu/qemu_vhost_user_gpu.c
-@SRCDIR@/src/remote/remote_client_bodies.h
 @SRCDIR@/src/remote/remote_daemon.c
 @SRCDIR@/src/remote/remote_daemon_config.c
 @SRCDIR@/src/remote/remote_daemon_dispatch.c
-@SRCDIR@/src/remote/remote_daemon_dispatch_stubs.h
 @SRCDIR@/src/remote/remote_daemon_stream.c
 @SRCDIR@/src/remote/remote_driver.c
 @SRCDIR@/src/rpc/virkeepalive.c
diff --git a/src/remote/Makefile.inc.am b/src/remote/Makefile.inc.am
index 7361d02cf4..242eb3ed2d 100644
--- a/src/remote/Makefile.inc.am
+++ b/src/remote/Makefile.inc.am
@@ -427,37 +427,37 @@ remote/remote_client_bodies.h: 
$(srcdir)/rpc/gendispatch.pl \
$(REMOTE_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=client \
  remote REMOTE $(REMOTE_PROTOCOL) \
- > $(srcdir)/remote/remote_client_bodies.h
+ > remote/remote_client_bodies.h
 
 remote/lxc_client_bodies.h: $(srcdir)/rpc/gendispatch.pl \
$(LXC_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=client \
  lxc LXC $(LXC_PROTOCOL) \
- > $(srcdir)/remote/lxc_client_bodies.h
+ > remote/lxc_client_bodies.h
 
 remote/qemu_client_bodies.h: $(srcdir)/rpc/gendispatch.pl \
$(QEMU_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=client \
  qemu QEMU $(QEMU_PROTOCOL) \
- > $(srcdir)/remote/qemu_client_bodies.h
+ > remote/qemu_client_bodies.h
 
 remote/remote_daemon_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
$(REMOTE_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
  --mode=server remote REMOTE $(REMOTE_PROTOCOL) \
- > $(srcdir)/remote/remote_daemon_dispatch_stubs.h
+ > remote/remote_daemon_dispatch_stubs.h
 
 remote/lxc_daemon_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
$(LXC_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
  --mode=server lxc LXC $(LXC_PROTOCOL) \
- > $(srcdir)/remote/lxc_daemon_dispatch_stubs.h
+ > remote/lxc_daemon_dispatch_stubs.h
 
 remote/qemu_daemon_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
$(QEMU_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
  --mode=server qemu QEMU $(QEMU_PROTOCOL) \
- > $(srcdir)/remote/qemu_daemon_dispatch_stubs.h
+ > remote/qemu_daemon_dispatch_stubs.h
 
 libvirtd.8.in: remote/libvirtd.pod
$(AM_V_GEN)$(POD2MAN) --section=8 $< $@-t1 && \
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 1/6] rpc: use the return value of virObjectRef directly

[Pavel Hrdina]

On Fri, Nov 01, 2019 at 06:35:43PM +0100, Marc Hartmayer wrote:
> Use the return value of virObjectRef directly. This way, it's easier
> for another reader to identify the reason why the additional reference
> is required.
> 
> Signed-off-by: Marc Hartmayer 
> Reviewed-by: John Ferlan 
> ---
>  src/rpc/virnetserver.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Pavel Hrdina 


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 2/6] virConnectRegisterCloseCallback: Cleanup 'opaque' if there is no connectRegisterCloseCallback

[Pavel Hrdina]

On Fri, Nov 01, 2019 at 06:35:44PM +0100, Marc Hartmayer wrote:
> The commit 'close callback: move it to driver' (88f09b75eb99) moved
> the responsibility for the close callback to the driver. But if the
> driver doesn't support the connectRegisterCloseCallback API this
> function does nothing, even no unsupported error report. This behavior
> may lead to problems, for example memory leaks, as the caller cannot
> differentiate whether the close callback was 'really' registered or
> not.
> 
> Therefore call directly @freecb if the connectRegisterCloseCallback
> API is not supported by the driver used by the connection.
> 
> Signed-off-by: Marc Hartmayer 
> ---
>  src/libvirt-host.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/src/libvirt-host.c b/src/libvirt-host.c
> index 221a1b7a4353..9c3a19f33b12 100644
> --- a/src/libvirt-host.c
> +++ b/src/libvirt-host.c
> @@ -1398,7 +1398,7 @@ virConnectIsAlive(virConnectPtr conn)
>   * @conn: pointer to connection object
>   * @cb: callback to invoke upon close
>   * @opaque: user data to pass to @cb
> - * @freecb: callback to free @opaque
> + * @freecb: callback to free @opaque when not used anymore
>   *
>   * Registers a callback to be invoked when the connection
>   * is closed. This callback is invoked when there is any
> @@ -1428,9 +1428,13 @@ virConnectRegisterCloseCallback(virConnectPtr conn,
>  virCheckConnectReturn(conn, -1);
>  virCheckNonNullArgGoto(cb, error);
>  
> -if (conn->driver->connectRegisterCloseCallback &&
> -conn->driver->connectRegisterCloseCallback(conn, cb, opaque, freecb) 
> < 0)
> -goto error;
> +if (conn->driver->connectRegisterCloseCallback) {
> +if (conn->driver->connectRegisterCloseCallback(conn, cb, opaque, 
> freecb) < 0)
> +goto error;
> +} else {
> +if (freecb)
> +freecb(opaque);
> +}

Looks good but I think we should improve the documentation of this API
to explicitly state that the @freecb is called only on success and if
the API fails the caller is responsible to free the opaque data.

Pavel


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 01/20] build: mandate use of a build dir != src dir

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 04:42:02PM +0100, Pavel Hrdina wrote:
> Historically we've allowed builds in the main src dir, but meson does
> not support this. Explicitly force separate build dir in autotools to
> align with meson. We must re-enable dependency tracking which the RPM
> %configure macro turns off. Without this, the build dir doesn't get
> the source directory tree mirrored.
> 
> Signed-off-by: Daniel P. Berrangé 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> New in v2.
> 
> Changes in v4:
> - Fixed Travis rules and documentation
> 
>  .travis.yml|  3 ++-
>  README-hacking | 11 ---
>  README.md  | 11 +++
>  bootstrap.conf |  6 ++
>  configure.ac   |  6 ++
>  docs/compiling.html.in | 10 ++
>  docs/windows.html.in   |  3 ++-
>  libvirt.spec.in| 10 +-
>  8 files changed, 46 insertions(+), 14 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 06/20] po: generate files into build directory

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 04:42:07PM +0100, Pavel Hrdina wrote:
> Historically we did not support VPATH builds and everything was
> generated into source directory.  The introduction of VPATH builds
> did not changed the way how our translation files are handled.
> 
> This patch changes the rules to generate everything into build
> directory and stops distributing generated files in order to have
> properly separated VPATH builds.
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> Changes in v2:
> - keep the zanata binary name, this will be fixed by separate patch
> 
> Chnages in v3:
> - update --transdir and --srcdir options as they are used by
>   python-zanata-client
> 
> Changes in v4:
> - reverted the HAVE_GNU_GETTEXT_TOOLS move
> 
>  .gitignore |  4 
>  po/Makefile.am | 31 +++
>  2 files changed, 19 insertions(+), 16 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 06/20] po: generate files into build directory

[Pavel Hrdina]

On Fri, Nov 08, 2019 at 03:51:25PM +, Daniel P. Berrangé wrote:
> On Fri, Nov 08, 2019 at 04:42:07PM +0100, Pavel Hrdina wrote:
> > Historically we did not support VPATH builds and everything was
> > generated into source directory.  The introduction of VPATH builds
> > did not changed the way how our translation files are handled.
> > 
> > This patch changes the rules to generate everything into build
> > directory and stops distributing generated files in order to have
> > properly separated VPATH builds.
> > 
> > Signed-off-by: Pavel Hrdina 
> > ---
> > 
> > Notes:
> > Changes in v2:
> > - keep the zanata binary name, this will be fixed by separate patch
> > 
> > Chnages in v3:
> > - update --transdir and --srcdir options as they are used by
> >   python-zanata-client
> > 
> > Changes in v4:
> > - reverted the HAVE_GNU_GETTEXT_TOOLS move
> > 
> >  .gitignore |  4 
> >  po/Makefile.am | 31 +++
> >  2 files changed, 19 insertions(+), 16 deletions(-)
> 
> Reviewed-by: Daniel P. Berrangé 

Thanks, pushed now.

Pavel


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] s390: change default cpu model to host-model?

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 12:49:23PM +0100, Christian Borntraeger wrote:
> 
> 
> On 08.11.19 12:43, Daniel P. Berrangé wrote:
> > On Mon, Nov 04, 2019 at 11:49:01AM +0100, David Hildenbrand wrote:
> >> On 02.11.19 11:32, Daniel P. Berrangé wrote:
> >>> On Fri, Nov 01, 2019 at 06:43:16PM +0100, Christian Borntraeger wrote:
>  On the KVM forum I have discussed the default cpu model mode on s390.
>  Right now if the xml does not specify anything, libvirt defaults to
>  not specifying anything on the qemu command line (no -cpu statement)
>  which is the equivalent of -cpu host for s390 which is equivalent to
>  host-passthrough. While this enables all features it does not provide
>  any migration safety by default.
> 
>  So in fact we are kind of "broken" right now when it comes to safery.
> 
>  So we discussed that it would make sense that an empty xml should 
>  actually
>  be defaulted to host-model, which results in - as of today - the same 
>  guest
>  features but in a migration safe way.
> 
>  There is another change planned right now to actually make the cpu model
>  present in an xml if none was specified. So we could actually do this 
>  change
>  before, together  or after te other. Jiri and I think it probably makes 
>  most
>  sense to have both changes at the same time (in terms of libvirt 
>  version).
> 
>  Does anyone see an issue with changing the default model mode to 
>  "host-model"
>  if the xml does not specify anything else?
> >>>
> >>> Changing from "host-passthrough" to "host-model" is not a huge difference,
> >>> but it is none the less a guest ABI change. "host-passthrough" doesn't
> >>> provide migration safety in the face of differing hardware, it should 
> >>> still
> >>> be valid for people with homogeneous hardware. So changing the model will
> >>> potentially break some existing usage.
> >>
> >> I guess on s390x this is not the case ("-cpu host", no "-cpu", and passing
> >> the expanded "host" model will result in the same guest ABI, in contrast to
> >> x86 AFAIK). There is this special case, though, where we have old QEMUs
> >> without CPU model support. Not sure how to deal with that, then.
> > 
> > I'm still not sure I understand the s390 CPU ABI rules.
> > 
> > Current libvirt, no , and thus no -cpu.
> > 
> > IIUC this is functionally identical to using "-cpu host" and/or
> > 
> > 
> > If you are using "-cpu host" /  can you
> > live migrate to another host with identical physical CPUs + firmware ?
> > 
> > 
> > Assuming this is possible, then, can you live migrate a QEMU guest
> > booted with , to a QEMU guest booted
> > with   ?
> 
> Not sure I understand your question. With "can", do  you mean "the guest
> has the same guest visible CPU features and types"?

Yes, I mean the migration should succeed from QEMU's POV and additionally
the guest OS should not see any change in CPU ABI exposed from the host.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 06/20] po: generate files into build directory

[Andrea Bolognani]

On Fri, 2019-11-08 at 11:24 +, Daniel P. Berrangé wrote:
> On Fri, Nov 08, 2019 at 12:15:53PM +0100, Andrea Bolognani wrote:
> > On Fri, 2019-11-08 at 10:04 +, Daniel P. Berrangé wrote:
> > > Moving this HAVE_GNU_GETTEXT_TOOLS conditional means that on OS that
> > > lack the GNU gettext impl, we are no longer able to 'make install'
> > > the translation files, despite having them prebuilt & bundled in the
> > > tarball.
> > > 
> > > IIRC, this affects any non-Linux host.
> > 
> > We install GNU gettext both on FreeBSD and on macOS, so it shouldn't
> > really be a problem I think? To me it doesn't seem much different
> > from mandating the use of GNU make, which we already do.
> 
> Where we do that on macOS ?   When I first did this new po/Makefile.am
> impl we didn't have GNU gettext on macOS at least, and I don't see us
> installing anything special in the travis config.

You're right that we don't install it explicitly: we used to, but we
stopped doing so with

  commit f28ed2e98c8307655ea53ad5cd1fe5e539cf626d
  Author: Andrea Bolognani 
  Date:   Mon Dec 4 15:54:59 2017 +0100

travis: Don't try to install brew packages twice

gettext, gnutls and libgcrypt are already installed on the
system, so we don't need to request their installation.

Signed-off-by: Andrea Bolognani 
Reviewed-by: Daniel P. Berrange 

Looking at that commit now I'm not sure why I even thought that would
be a good idea? ¯\_(ツ)_/¯ Then again, we're not exactly as
comprehensive in our handling of macOS packages as we are on other
platforms, in part because we're not building our own images but
rather using whatever Travis CI provides us with.

Anyway, GNU gettext is dragged in as a dependency of GLib these days
and we're already making sure we actually use it:

  - compiler: clang
language: c
os: osx
env:
  - PATH="/usr/local/opt/gettext/bin:..."

> If we can assume GNU gettext though, we should enforce that upfront in
> the configure script checks and get rid of the conditional entirely

That would make perfect sense to me.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 0/2] Deprecate implicit filters

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20191108101655.10611-1-vsement...@virtuozzo.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

  SIGNpc-bios/optionrom/pvh.bin
  GEN docs/interop/qemu-ga-ref.7
/tmp/qemu-test/src/qemu-deprecated.texi:210: @option expected braces
make: *** [Makefile:994: qemu-doc.txt] Error 1
make: *** Waiting for unfinished jobs
/tmp/qemu-test/src/qemu-deprecated.texi:210: @option expected braces
make: *** [Makefile:987: qemu-doc.html] Error 1
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 662, in 
sys.exit(main())
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=3d404482279f4fe68fcb2c9971f2480a', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-mlpokwtg/src/docker-src.2019-11-08-06.56.33.23805:/var/tmp/qemu:z,ro',
 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=3d404482279f4fe68fcb2c9971f2480a
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-mlpokwtg/src'
make: *** [docker-run-test-mingw@fedora] Error 2

real4m11.170s
user0m4.404s


The full log is available at
http://patchew.org/logs/20191108101655.10611-1-vsement...@virtuozzo.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH 0/5] Add Fedora 31, drop Fedora 29

[Andrea Bolognani]

On Fri, 2019-11-08 at 10:42 +0100, Fabiano Fidêncio wrote:
> On Fri, Nov 8, 2019 at 9:24 AM Erik Skultety  wrote:
> > On Thu, Nov 07, 2019 at 07:51:56PM +0100, Andrea Bolognani wrote:
> > > Andrea Bolognani (5):
> > >   guests: Explicitly enable ssh root login in kickstart
> > >   guests: Add Fedora 31
> > >   Start building on Fedora 31
> > >   Stop building on Fedora 29
> > >   guests: Drop Fedora 29
> > 
> > Reviewed-by: Erik Skultety 
> 
> Also, Reviewed-by: Fabiano Fidêncio 

Sorry, I had already pushed the patches by the time you replied O:-)
Glad you didn't spot any issues with the series, though!

> Would you mind also sending patches to the dockerfiles?

I'll do that in a bit. Dan has one more patch pending, so I'm going
to wait until that's merged and avoid going through the process
twice.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] s390: change default cpu model to host-model?

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 01:56:47PM +0100, Christian Borntraeger wrote:
> 
> 
> On 08.11.19 12:52, Daniel P. Berrangé wrote:
> > On Fri, Nov 08, 2019 at 12:49:23PM +0100, Christian Borntraeger wrote:
> >>
> >>
> >> On 08.11.19 12:43, Daniel P. Berrangé wrote:
> >>> On Mon, Nov 04, 2019 at 11:49:01AM +0100, David Hildenbrand wrote:
>  On 02.11.19 11:32, Daniel P. Berrangé wrote:
> > On Fri, Nov 01, 2019 at 06:43:16PM +0100, Christian Borntraeger wrote:
> >> On the KVM forum I have discussed the default cpu model mode on s390.
> >> Right now if the xml does not specify anything, libvirt defaults to
> >> not specifying anything on the qemu command line (no -cpu statement)
> >> which is the equivalent of -cpu host for s390 which is equivalent to
> >> host-passthrough. While this enables all features it does not provide
> >> any migration safety by default.
> >>
> >> So in fact we are kind of "broken" right now when it comes to safery.
> >>
> >> So we discussed that it would make sense that an empty xml should 
> >> actually
> >> be defaulted to host-model, which results in - as of today - the same 
> >> guest
> >> features but in a migration safe way.
> >>
> >> There is another change planned right now to actually make the cpu 
> >> model
> >> present in an xml if none was specified. So we could actually do this 
> >> change
> >> before, together  or after te other. Jiri and I think it probably 
> >> makes most
> >> sense to have both changes at the same time (in terms of libvirt 
> >> version).
> >>
> >> Does anyone see an issue with changing the default model mode to 
> >> "host-model"
> >> if the xml does not specify anything else?
> >
> > Changing from "host-passthrough" to "host-model" is not a huge 
> > difference,
> > but it is none the less a guest ABI change. "host-passthrough" doesn't
> > provide migration safety in the face of differing hardware, it should 
> > still
> > be valid for people with homogeneous hardware. So changing the model 
> > will
> > potentially break some existing usage.
> 
>  I guess on s390x this is not the case ("-cpu host", no "-cpu", and 
>  passing
>  the expanded "host" model will result in the same guest ABI, in contrast 
>  to
>  x86 AFAIK). There is this special case, though, where we have old QEMUs
>  without CPU model support. Not sure how to deal with that, then.
> >>>
> >>> I'm still not sure I understand the s390 CPU ABI rules.
> >>>
> >>> Current libvirt, no , and thus no -cpu.
> >>>
> >>> IIUC this is functionally identical to using "-cpu host" and/or
> >>> 
> >>>
> >>> If you are using "-cpu host" /  can you
> >>> live migrate to another host with identical physical CPUs + firmware ?
> >>>
> >>>
> >>> Assuming this is possible, then, can you live migrate a QEMU guest
> >>> booted with , to a QEMU guest booted
> >>> with   ?
> >>
> >> Not sure I understand your question. With "can", do  you mean "the guest
> >> has the same guest visible CPU features and types"?
> > 
> > Yes, I mean the migration should succeed from QEMU's POV and additionally
> > the guest OS should not see any change in CPU ABI exposed from the host.
> 
> The guest ABI is the same and migration also seems to work. 
> I think your concern boils down to the case that source and target
> have a different libvirt version (but qemu and kernel and firmware
> and hardware are identical). So for that case this change would break
> things if host-model and host-passthrough are not identical.
> So as of today we have no concern. 
> 
> Now: Would it be a concern if a future QEMU decides to change that
> equivalence somehow?

If they're the same guest ABI, then what's the benefit in changing the
default to "host-model" instead of just continuing with "host-passthrough".
It seems like we're fine to just carry on with "host-passthrough" as
the default and insulate ourselves from any future risk of change.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 5/5] news: Introduce virConnectSetIdentity API in 5.8

[Jiri Denemark]

On Fri, Nov 08, 2019 at 15:00:22 +0800, Han Han wrote:
> Signed-off-by: Han Han 
> ---
>  docs/news.xml | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/docs/news.xml b/docs/news.xml
> index 571a1b6ea4..c37d0d22ef 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -199,6 +199,16 @@
>backend. It requires qemu over 4.1.
>  
>
> +  
> +
> +  Introduce virConnectSetIdentity API
> +
> +
> +  For splited libvirt daemons, this API can be used to forward uid, 
> gid
> +  and selinux info from virproxyd to
> +  virtqemud.
> +
> +  
>  
>  
>

This API is not really supposed to be used by users. It's an internal
implementation detail and should not be mentioned in news.

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 01/20] build: mandate use of a build dir != src dir

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:19PM +0200, Pavel Hrdina wrote:
> From: Daniel P. Berrangé 
> 
> Historically we've allowed builds in the main src dir, but meson does
> not support this. Explicitly force separate build dir in autotools to
> align with meson. We must re-enable dependency tracking which the RPM
> %configure macro turns off. Without this, the build dir doesn't get
> the source directory tree mirrored.
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
> 
> Notes:
> New in v2.
> 
>  configure.ac|  6 ++
>  libvirt.spec.in | 10 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)

I realized I missed some things needing updates

 - Travis rules for macOS
 - README.md
 - README-hacking
 - docs/compiling.html.in
 - bootstrap's final message
 - docs/window.html.in


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 02/20] .gitignore: cleanup old and obsolete ignores

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:20PM +0200, Pavel Hrdina wrote:
> Now that we forbid builds in source directory we can remove a lot of
> ignores that are created during build time.  To make the cleanup easier
> in the future create a sections in our .gitignore file.
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> New in v2.
> 
>  .gitignore | 249 ++---
>  1 file changed, 26 insertions(+), 223 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 20/20] tools: stop distributing generated source files

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:38PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
>  tools/Makefile.am | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 19/20] src: stop distributing generated source files

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:37PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
>  src/Makefile.am |  6 +++---
>  src/access/Makefile.inc.am  |  3 ++-
>  src/admin/Makefile.inc.am   | 13 +++--
>  src/bhyve/Makefile.inc.am   |  1 +
>  src/esx/Makefile.inc.am |  4 +---
>  src/hyperv/Makefile.inc.am  |  4 +---
>  src/interface/Makefile.inc.am   |  1 +
>  src/libxl/Makefile.inc.am   |  1 +
>  src/locking/Makefile.inc.am |  8 +---
>  src/logging/Makefile.inc.am | 12 +++-
>  src/lxc/Makefile.inc.am | 27 ++-
>  src/network/Makefile.inc.am |  1 +
>  src/node_device/Makefile.inc.am |  1 +
>  src/nwfilter/Makefile.inc.am|  1 +
>  src/qemu/Makefile.inc.am|  1 +
>  src/remote/Makefile.inc.am  | 20 
>  src/rpc/Makefile.inc.am |  5 -
>  src/secret/Makefile.inc.am  |  1 +
>  src/storage/Makefile.inc.am |  1 +
>  src/util/Makefile.inc.am|  6 --
>  src/vbox/Makefile.inc.am|  1 +
>  src/vz/Makefile.inc.am  |  1 +
>  22 files changed, 75 insertions(+), 44 deletions(-)

Reviewed-by: Daniel P. Berrangé 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 17/20] src: lxc: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:35PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> - modify generated_files for sc_po_check as well
> 
>  .gitignore| 2 --
>  build-aux/syntax-check.mk | 1 -
>  src/lxc/Makefile.inc.am   | 4 ++--
>  3 files changed, 2 insertions(+), 5 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 16/20] src: logging: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:34PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> - modify generated_files for sc_po_check as well
> 
>  .gitignore  | 1 -
>  build-aux/syntax-check.mk   | 2 +-
>  src/logging/Makefile.inc.am | 2 +-
>  3 files changed, 2 insertions(+), 3 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 06/20] po: generate files into build directory

[Andrea Bolognani]

On Fri, 2019-11-08 at 10:04 +, Daniel P. Berrangé wrote:
> On Thu, Oct 24, 2019 at 03:05:24PM +0200, Pavel Hrdina wrote:
> > -endif HAVE_GNU_GETTEXT_TOOLS
> > -
> >  if ENABLE_NLS
> >  
> >  # Cannot use 'localedir' since this conflicts with autoconf.
> > @@ -99,7 +104,7 @@ install-data-hook: $(GMOFILES)
> > for lang in $(LANGS); do \
> >   d=$(DESTDIR)$(langinstdir)/$$lang/LC_MESSAGES; \
> >   mkdir -p $$d; \
> > - install -m 0644 $(srcdir)/$$lang.gmo $$d/$(DOMAIN).mo; \
> > + install -m 0644 $$lang.gmo $$d/$(DOMAIN).mo; \
> > done
> >  
> >  uninstall-hook:
> > @@ -109,3 +114,5 @@ uninstall-hook:
> > done
> >  
> >  endif ENABLE_NLS
> > +
> > +endif HAVE_GNU_GETTEXT_TOOLS
> 
> Moving this HAVE_GNU_GETTEXT_TOOLS conditional means that on OS that
> lack the GNU gettext impl, we are no longer able to 'make install'
> the translation files, despite having them prebuilt & bundled in the
> tarball.
> 
> IIRC, this affects any non-Linux host.

We install GNU gettext both on FreeBSD and on macOS, so it shouldn't
really be a problem I think? To me it doesn't seem much different
from mandating the use of GNU make, which we already do.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] s390: change default cpu model to host-model?

[Daniel P . Berrangé]

On Mon, Nov 04, 2019 at 11:49:01AM +0100, David Hildenbrand wrote:
> On 02.11.19 11:32, Daniel P. Berrangé wrote:
> > On Fri, Nov 01, 2019 at 06:43:16PM +0100, Christian Borntraeger wrote:
> > > On the KVM forum I have discussed the default cpu model mode on s390.
> > > Right now if the xml does not specify anything, libvirt defaults to
> > > not specifying anything on the qemu command line (no -cpu statement)
> > > which is the equivalent of -cpu host for s390 which is equivalent to
> > > host-passthrough. While this enables all features it does not provide
> > > any migration safety by default.
> > > 
> > > So in fact we are kind of "broken" right now when it comes to safery.
> > > 
> > > So we discussed that it would make sense that an empty xml should actually
> > > be defaulted to host-model, which results in - as of today - the same 
> > > guest
> > > features but in a migration safe way.
> > > 
> > > There is another change planned right now to actually make the cpu model
> > > present in an xml if none was specified. So we could actually do this 
> > > change
> > > before, together  or after te other. Jiri and I think it probably makes 
> > > most
> > > sense to have both changes at the same time (in terms of libvirt version).
> > > 
> > > Does anyone see an issue with changing the default model mode to 
> > > "host-model"
> > > if the xml does not specify anything else?
> > 
> > Changing from "host-passthrough" to "host-model" is not a huge difference,
> > but it is none the less a guest ABI change. "host-passthrough" doesn't
> > provide migration safety in the face of differing hardware, it should still
> > be valid for people with homogeneous hardware. So changing the model will
> > potentially break some existing usage.
> 
> I guess on s390x this is not the case ("-cpu host", no "-cpu", and passing
> the expanded "host" model will result in the same guest ABI, in contrast to
> x86 AFAIK). There is this special case, though, where we have old QEMUs
> without CPU model support. Not sure how to deal with that, then.

I'm still not sure I understand the s390 CPU ABI rules.

Current libvirt, no , and thus no -cpu.

IIUC this is functionally identical to using "-cpu host" and/or


If you are using "-cpu host" /  can you
live migrate to another host with identical physical CPUs + firmware ?


Assuming this is possible, then, can you live migrate a QEMU guest
booted with , to a QEMU guest booted
with   ?

On x86 the latter is not possible. Is s390 different ?

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] s390: change default cpu model to host-model?

[Christian Borntraeger]

On 08.11.19 12:43, Daniel P. Berrangé wrote:
> On Mon, Nov 04, 2019 at 11:49:01AM +0100, David Hildenbrand wrote:
>> On 02.11.19 11:32, Daniel P. Berrangé wrote:
>>> On Fri, Nov 01, 2019 at 06:43:16PM +0100, Christian Borntraeger wrote:
 On the KVM forum I have discussed the default cpu model mode on s390.
 Right now if the xml does not specify anything, libvirt defaults to
 not specifying anything on the qemu command line (no -cpu statement)
 which is the equivalent of -cpu host for s390 which is equivalent to
 host-passthrough. While this enables all features it does not provide
 any migration safety by default.

 So in fact we are kind of "broken" right now when it comes to safery.

 So we discussed that it would make sense that an empty xml should actually
 be defaulted to host-model, which results in - as of today - the same guest
 features but in a migration safe way.

 There is another change planned right now to actually make the cpu model
 present in an xml if none was specified. So we could actually do this 
 change
 before, together  or after te other. Jiri and I think it probably makes 
 most
 sense to have both changes at the same time (in terms of libvirt version).

 Does anyone see an issue with changing the default model mode to 
 "host-model"
 if the xml does not specify anything else?
>>>
>>> Changing from "host-passthrough" to "host-model" is not a huge difference,
>>> but it is none the less a guest ABI change. "host-passthrough" doesn't
>>> provide migration safety in the face of differing hardware, it should still
>>> be valid for people with homogeneous hardware. So changing the model will
>>> potentially break some existing usage.
>>
>> I guess on s390x this is not the case ("-cpu host", no "-cpu", and passing
>> the expanded "host" model will result in the same guest ABI, in contrast to
>> x86 AFAIK). There is this special case, though, where we have old QEMUs
>> without CPU model support. Not sure how to deal with that, then.
> 
> I'm still not sure I understand the s390 CPU ABI rules.
> 
> Current libvirt, no , and thus no -cpu.
> 
> IIUC this is functionally identical to using "-cpu host" and/or
> 
> 
> If you are using "-cpu host" /  can you
> live migrate to another host with identical physical CPUs + firmware ?
> 
> 
> Assuming this is possible, then, can you live migrate a QEMU guest
> booted with , to a QEMU guest booted
> with   ?

Not sure I understand your question. With "can", do  you mean "the guest
has the same guest visible CPU features and types"?  

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH] Add python-docutils package for libvirt

[Andrea Bolognani]

On Fri, 2019-11-08 at 11:22 +, Daniel P. Berrangé wrote:
> +++ b/guests/vars/mappings.yml
> @@ -795,6 +795,11 @@ mappings:
> +  python-docutils:

The mapping should be called python3-docutils...

> +default: python3-docutils
> +CentOS7: python2-docutils

... and should install python36-docutils from EPEL on CentOS 7.

Down with Python 2! :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] s390: change default cpu model to host-model?

[Christian Borntraeger]

On 08.11.19 12:52, Daniel P. Berrangé wrote:
> On Fri, Nov 08, 2019 at 12:49:23PM +0100, Christian Borntraeger wrote:
>>
>>
>> On 08.11.19 12:43, Daniel P. Berrangé wrote:
>>> On Mon, Nov 04, 2019 at 11:49:01AM +0100, David Hildenbrand wrote:
 On 02.11.19 11:32, Daniel P. Berrangé wrote:
> On Fri, Nov 01, 2019 at 06:43:16PM +0100, Christian Borntraeger wrote:
>> On the KVM forum I have discussed the default cpu model mode on s390.
>> Right now if the xml does not specify anything, libvirt defaults to
>> not specifying anything on the qemu command line (no -cpu statement)
>> which is the equivalent of -cpu host for s390 which is equivalent to
>> host-passthrough. While this enables all features it does not provide
>> any migration safety by default.
>>
>> So in fact we are kind of "broken" right now when it comes to safery.
>>
>> So we discussed that it would make sense that an empty xml should 
>> actually
>> be defaulted to host-model, which results in - as of today - the same 
>> guest
>> features but in a migration safe way.
>>
>> There is another change planned right now to actually make the cpu model
>> present in an xml if none was specified. So we could actually do this 
>> change
>> before, together  or after te other. Jiri and I think it probably makes 
>> most
>> sense to have both changes at the same time (in terms of libvirt 
>> version).
>>
>> Does anyone see an issue with changing the default model mode to 
>> "host-model"
>> if the xml does not specify anything else?
>
> Changing from "host-passthrough" to "host-model" is not a huge difference,
> but it is none the less a guest ABI change. "host-passthrough" doesn't
> provide migration safety in the face of differing hardware, it should 
> still
> be valid for people with homogeneous hardware. So changing the model will
> potentially break some existing usage.

 I guess on s390x this is not the case ("-cpu host", no "-cpu", and passing
 the expanded "host" model will result in the same guest ABI, in contrast to
 x86 AFAIK). There is this special case, though, where we have old QEMUs
 without CPU model support. Not sure how to deal with that, then.
>>>
>>> I'm still not sure I understand the s390 CPU ABI rules.
>>>
>>> Current libvirt, no , and thus no -cpu.
>>>
>>> IIUC this is functionally identical to using "-cpu host" and/or
>>> 
>>>
>>> If you are using "-cpu host" /  can you
>>> live migrate to another host with identical physical CPUs + firmware ?
>>>
>>>
>>> Assuming this is possible, then, can you live migrate a QEMU guest
>>> booted with , to a QEMU guest booted
>>> with   ?
>>
>> Not sure I understand your question. With "can", do  you mean "the guest
>> has the same guest visible CPU features and types"?
> 
> Yes, I mean the migration should succeed from QEMU's POV and additionally
> the guest OS should not see any change in CPU ABI exposed from the host.

The guest ABI is the same and migration also seems to work. 
I think your concern boils down to the case that source and target
have a different libvirt version (but qemu and kernel and firmware
and hardware are identical). So for that case this change would break
things if host-model and host-passthrough are not identical. 

So as of today we have no concern. 

Now: Would it be a concern if a future QEMU decides to change that
equivalence somehow?

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH 1/5] guests: Explicitly enable ssh root login in kickstart

[Andrea Bolognani]

On Fri, 2019-11-08 at 09:22 +0100, Erik Skultety wrote:
> On Thu, Nov 07, 2019 at 07:51:57PM +0100, Andrea Bolognani wrote:
> > Both CentOS and Fedora have had this enabled by default up until
> > now, but that's no longer the case as of Fedora 31. Enabling it
> > explicitly makes the first connection work as expected on the
> > newer distributions without impacting the older ones negatively.
> 
> Now that I read ^this, I'm wondering whether it wouldn't be worth also adding
> 
> services --enabled sshd
> 
> to the kickstart - I know, this is only useful with the workstation flavour
> which comes with SSH daemon disabled, but I think it doesn't hurt to specify
> this explicitly, especially in context of ansible, just my 2c.

I wonder which specific component disables sshd for the Workstation
flavor? Is there a chance the corresponding package is simply not
installed in the first place?

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 0/2] Deprecate implicit filters

[Maxim Levitsky]

On Fri, 2019-11-08 at 13:16 +0300, Vladimir Sementsov-Ogievskiy wrote:
> v2:
> Don't deprecate drive-backup, it is unrelated thing and will be resent
> in separate.
> Don't deprecate drive-mirror. Instead add filter-node-name to
> drive-mirror to behave like blockdev-mirror
> Fix all broken iotests.

I did a quick overview of these patches (I don't know the area well
to do a full review) and it looks fine to me, other than that FIXME you added,
which (at least looking at the explanation) I think should be investigated,
as it might point to a deeper problem somewhere.

Also *I think* that I would merge these two patches together,
but this is only my personal taste.

Best regards,
Maxim Levitsky


> 
> Vladimir Sementsov-Ogievskiy (2):
>   qapi: add filter-node-name option to drive-mirror
>   qapi: deprecate implicit filters
> 
>  qemu-deprecated.texi   |  6 ++
>  qapi/block-core.json   | 14 --
>  include/block/block_int.h  | 10 +-
>  blockdev.c | 12 +++-
>  tests/qemu-iotests/094 |  1 +
>  tests/qemu-iotests/095 |  6 --
>  tests/qemu-iotests/109 |  1 +
>  tests/qemu-iotests/127 |  1 +
>  tests/qemu-iotests/141 |  5 -
>  tests/qemu-iotests/144 |  3 ++-
>  tests/qemu-iotests/156 |  1 +
>  tests/qemu-iotests/161 |  7 +++
>  tests/qemu-iotests/161.out |  1 +
>  tests/qemu-iotests/185 |  3 +++
>  tests/qemu-iotests/191 |  2 ++
>  tests/qemu-iotests/229 |  1 +
>  tests/qemu-iotests/247 |  8 +---
>  tests/qemu-iotests/249 |  5 +++--
>  tests/qemu-iotests/249.out |  2 +-
>  19 files changed, 75 insertions(+), 14 deletions(-)
> 


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 0/2] Deprecate implicit filters

[Vladimir Sementsov-Ogievskiy]

Something strange, I don't think it related to patchset.

08.11.2019 15:00, no-re...@patchew.org wrote:
> Patchew URL: 
> https://patchew.org/QEMU/20191108101655.10611-1-vsement...@virtuozzo.com/
> 
> 
> 
> Hi,
> 
> This series failed the docker-mingw@fedora build test. Please find the 
> testing commands and
> their output below. If you have Docker installed, you can probably reproduce 
> it
> locally.
> 
> === TEST SCRIPT BEGIN ===
> #! /bin/bash
> export ARCH=x86_64
> make docker-image-fedora V=1 NETWORK=1
> time make docker-test-mingw@fedora J=14 NETWORK=1
> === TEST SCRIPT END ===
> 
>SIGNpc-bios/optionrom/pvh.bin
>GEN docs/interop/qemu-ga-ref.7
> /tmp/qemu-test/src/qemu-deprecated.texi:210: @option expected braces
> make: *** [Makefile:994: qemu-doc.txt] Error 1
> make: *** Waiting for unfinished jobs
> /tmp/qemu-test/src/qemu-deprecated.texi:210: @option expected braces
> make: *** [Makefile:987: qemu-doc.html] Error 1
> Traceback (most recent call last):
>File "./tests/docker/docker.py", line 662, in 
>  sys.exit(main())
> ---
>  raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
> '--label', 'com.qemu.instance.uuid=3d404482279f4fe68fcb2c9971f2480a', '-u', 
> '1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
> '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', 
> '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
> '/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
> '/var/tmp/patchew-tester-tmp-mlpokwtg/src/docker-src.2019-11-08-06.56.33.23805:/var/tmp/qemu:z,ro',
>  'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit 
> status 2.
> filter=--filter=label=com.qemu.instance.uuid=3d404482279f4fe68fcb2c9971f2480a
> make[1]: *** [docker-run] Error 1
> make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-mlpokwtg/src'
> make: *** [docker-run-test-mingw@fedora] Error 2
> 
> real4m11.170s
> user0m4.404s
> 
> 
> The full log is available at
> http://patchew.org/logs/20191108101655.10611-1-vsement...@virtuozzo.com/testing.docker-mingw@fedora/?type=message.
> ---
> Email generated automatically by Patchew [https://patchew.org/].
> Please send your feedback to patchew-de...@redhat.com
> 


-- 
Best regards,
Vladimir

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 07/39] qemu: Explicitly add/remove /dev/vfio/vfio to/from NS/CGroups

[Michal Privoznik]

On 10/18/19 12:10 AM, Cole Robinson wrote:

On 9/26/19 12:12 PM, Michal Privoznik wrote:

In near future, the decision what to do with /dev/vfio/vfio with
respect to domain namespace and CGroup is going to be moved out
of qemuDomainGetHostdevPath() because there will be some other
types of devices than hostdevs that need access to VFIO.

All functions that I'm changing assume that hostdev we are
adding/removing to VM is not in the definition yet (because of
how qemuDomainNeedsVFIO() is written). Fortunately, this
assumption is true.



qemuProcessLaunch ->
   qemuSetupCgroup ->
 qemuSetupDevicesCgroup ->

has

 for (i = 0; i < vm->def->nhostdevs; i++) {

 if (qemuSetupHostdevCgroup(vm, vm->def->hostdevs[i]) < 0)

 goto cleanup;

 }

So that above paragraph doesn't seem correct. If I apply up to patch
#17, this breaks VM startup with a PCI passthrough device, but caveat
only with cgroupv1. Apparently cgroupv2 doesn't have any notion of
allowDevice ? or at least there's no impl there.


Yeah, cgroupv2 doesn't implement devices controller just yet.




Signed-off-by: Michal Privoznik 
---
  src/qemu/qemu_cgroup.c | 48 +-
  src/qemu/qemu_domain.c | 36 +++
  2 files changed, 83 insertions(+), 1 deletion(-)




@@ -386,6 +398,17 @@ qemuSetupHostdevCgroup(virDomainObjPtr vm,
  goto cleanup;
  }
  
+if (qemuHostdevNeedsVFIO(dev) &&

+!qemuDomainNeedsVFIO(vm->def)) {
+VIR_DEBUG("Cgroup allow %s perms=%d", QEMU_DEV_VFIO, 
VIR_CGROUP_DEVICE_RW);
+rv = virCgroupAllowDevicePath(priv->cgroup, QEMU_DEV_VFIO,
+  VIR_CGROUP_DEVICE_RW, false);
+virDomainAuditCgroupPath(vm, priv->cgroup, "allow",
+ QEMU_DEV_VFIO, "rw", rv);
+if (rv < 0)
+goto cleanup;
+}
+
  ret = 0;



So on VM startup this code path isn't hit, because dev is already in
vm->def, so the if() condition will never be true.

However this patch itself doesn't break things, because
qemuDomainGetHostdevPath will also return /dev/vfio/vfio if the device
needs it. I guess later patches undo that somehow but I didn't look into
yet why that is.

Is the !qemuDomainNeedsVFIO even necessary? The existing code will
already call virCgroupAllowDevicePath(/dev/vfio/vfio) multiple times if
the device has multiple VFIO devices attached so apparently that's not
problematic.


Ah, good catch. It's not necessary. Will fix and repost.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] s390: change default cpu model to host-model?

[Christian Borntraeger]

On 08.11.19 14:10, Daniel P. Berrangé wrote:
> On Fri, Nov 08, 2019 at 01:56:47PM +0100, Christian Borntraeger wrote:
>>
>>
>> On 08.11.19 12:52, Daniel P. Berrangé wrote:
>>> On Fri, Nov 08, 2019 at 12:49:23PM +0100, Christian Borntraeger wrote:


 On 08.11.19 12:43, Daniel P. Berrangé wrote:
> On Mon, Nov 04, 2019 at 11:49:01AM +0100, David Hildenbrand wrote:
>> On 02.11.19 11:32, Daniel P. Berrangé wrote:
>>> On Fri, Nov 01, 2019 at 06:43:16PM +0100, Christian Borntraeger wrote:
 On the KVM forum I have discussed the default cpu model mode on s390.
 Right now if the xml does not specify anything, libvirt defaults to
 not specifying anything on the qemu command line (no -cpu statement)
 which is the equivalent of -cpu host for s390 which is equivalent to
 host-passthrough. While this enables all features it does not provide
 any migration safety by default.

 So in fact we are kind of "broken" right now when it comes to safery.

 So we discussed that it would make sense that an empty xml should 
 actually
 be defaulted to host-model, which results in - as of today - the same 
 guest
 features but in a migration safe way.

 There is another change planned right now to actually make the cpu 
 model
 present in an xml if none was specified. So we could actually do this 
 change
 before, together  or after te other. Jiri and I think it probably 
 makes most
 sense to have both changes at the same time (in terms of libvirt 
 version).

 Does anyone see an issue with changing the default model mode to 
 "host-model"
 if the xml does not specify anything else?
>>>
>>> Changing from "host-passthrough" to "host-model" is not a huge 
>>> difference,
>>> but it is none the less a guest ABI change. "host-passthrough" doesn't
>>> provide migration safety in the face of differing hardware, it should 
>>> still
>>> be valid for people with homogeneous hardware. So changing the model 
>>> will
>>> potentially break some existing usage.
>>
>> I guess on s390x this is not the case ("-cpu host", no "-cpu", and 
>> passing
>> the expanded "host" model will result in the same guest ABI, in contrast 
>> to
>> x86 AFAIK). There is this special case, though, where we have old QEMUs
>> without CPU model support. Not sure how to deal with that, then.
>
> I'm still not sure I understand the s390 CPU ABI rules.
>
> Current libvirt, no , and thus no -cpu.
>
> IIUC this is functionally identical to using "-cpu host" and/or
> 
>
> If you are using "-cpu host" /  can you
> live migrate to another host with identical physical CPUs + firmware ?
>
>
> Assuming this is possible, then, can you live migrate a QEMU guest
> booted with , to a QEMU guest booted
> with   ?

 Not sure I understand your question. With "can", do  you mean "the guest
 has the same guest visible CPU features and types"?
>>>
>>> Yes, I mean the migration should succeed from QEMU's POV and additionally
>>> the guest OS should not see any change in CPU ABI exposed from the host.
>>
>> The guest ABI is the same and migration also seems to work. 
>> I think your concern boils down to the case that source and target
>> have a different libvirt version (but qemu and kernel and firmware
>> and hardware are identical). So for that case this change would break
>> things if host-model and host-passthrough are not identical.
>> So as of today we have no concern. 
>>
>> Now: Would it be a concern if a future QEMU decides to change that
>> equivalence somehow?
> 
> If they're the same guest ABI, then what's the benefit in changing the
> default to "host-model" instead of just continuing with "host-passthrough".
> It seems like we're fine to just carry on with "host-passthrough" as
> the default and insulate ourselves from any future risk of change.

The benefit is that that todays default is not migration safe and users will
find that out by random guest crashes if any of the parameters (CPU, kernel,
qemu, firmware) is different. So really, todays default is just completely
broken on s390 and thats why I want to change it.

host-model instead is expanded by libvirt and the migration will be rejected
if the target is incompatible (qemu will reject to run).


migh

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 2/2] qapi: deprecate implicit filters

[Peter Krempa]

On Fri, Nov 08, 2019 at 13:16:55 +0300, Vladimir Sementsov-Ogievskiy wrote:
> To get rid of implicit filters related workarounds in future let's
> deprecate them now.
> 
> Deprecation warning breaks some bash iotests output, so fix it here
> too: in most of cases just add filter-node-name in test.
> 
> In 161 add FIXME and deprecation warning into 161.out.
> 
> In 249, the test case is changed, as we don't need to test "default"
> filter node name anymore.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  qemu-deprecated.texi   |  6 ++
>  qapi/block-core.json   |  9 ++---
>  include/block/block_int.h  | 10 +-
>  blockdev.c | 10 ++
>  tests/qemu-iotests/094 |  1 +
>  tests/qemu-iotests/095 |  6 --
>  tests/qemu-iotests/109 |  1 +
>  tests/qemu-iotests/127 |  1 +
>  tests/qemu-iotests/141 |  5 -
>  tests/qemu-iotests/144 |  3 ++-
>  tests/qemu-iotests/156 |  1 +
>  tests/qemu-iotests/161 |  7 +++
>  tests/qemu-iotests/161.out |  1 +
>  tests/qemu-iotests/185 |  3 +++
>  tests/qemu-iotests/191 |  2 ++
>  tests/qemu-iotests/229 |  1 +
>  tests/qemu-iotests/247 |  8 +---
>  tests/qemu-iotests/249 |  5 +++--
>  tests/qemu-iotests/249.out |  2 +-
>  19 files changed, 68 insertions(+), 14 deletions(-)
> 
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index 296bfc93a3..c969faf55a 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -204,6 +204,12 @@ and accurate ``query-qmp-schema'' command.
>  Character devices creating sockets in client mode should not specify
>  the 'wait' field, which is only applicable to sockets in server mode
>  
> +@subsection implicit filters in mirror and commit (since 4.2)
> +
> +Mirror and commit jobs insert filters, which becomes implicit if user
> +omitted @option(filter-node-name) parameter. So omitting it is deprecated
> +in ``blockdev-mirror'', ``drive-mirror'' and ``block-commit'', set it always.
> +
>  @section Human Monitor Protocol (HMP) commands
>  
>  @subsection The hub_id parameter of 'hostfwd_add' / 'hostfwd_remove' (since 
> 3.1)
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 93530d3a13..37caed775f 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1659,7 +1659,8 @@
>  # @filter-node-name: the node name that should be assigned to the
>  #filter driver that the commit job inserts into the graph
>  #above @top. If this option is not given, a node name is
> -#autogenerated. (Since: 2.9)
> +#autogenerated. Omitting this option is deprecated, it 
> will
> +#be required in future. (Since: 2.9)
>  #
>  # @auto-finalize: When false, this job will wait in a PENDING state after it 
> has
>  # finished its work, waiting for @block-job-finalize before

Note that 'block-commit' and 'drive-mirror' commands are used by libvirt
in the pre-blockdev era. In those instances we gather statistics of
block devices by nesting in the output of query-blockstats and
query-block rather than selecting the appropriate info by any other
means (e.g. by node name).

This means that the output MUST stay consistend when block jobs are used
and the hack this patch is deprcating will break those.

Note that in libvirt we don't plan to invest time to add workarounds for
non-blockdev cases since blockdev by itself is complex enough and I'd
strongly prefer not having a third code path to care about.

Given that -blockdev can't be used in all cases (e.g. for sd-cards)
which also blocks deprecation of -drive I don't think that hiding of
implicit filter nodes can be deprecated until -drive is deprecated.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 1/2] qapi: add filter-node-name option to drive-mirror

[Peter Krempa]

On Fri, Nov 08, 2019 at 13:16:54 +0300, Vladimir Sementsov-Ogievskiy wrote:
> To correspond to blockdev-mirror command and make it possible to
> deprecate implicit filters in the next commit.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  qapi/block-core.json | 7 +++
>  blockdev.c   | 2 +-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index aa97ee2641..93530d3a13 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1992,6 +1992,12 @@
>  # @on-target-error: the action to take on an error on the target,
>  #   default 'report' (no limitations, since this applies to
>  #   a different block device than @device).
> +#
> +# @filter-node-name: the node name that should be assigned to the
> +#filter driver that the mirror job inserts into the graph
> +#above @device. If this option is not given, a node name 
> is
> +#autogenerated. (Since: 4.2)
> +#

Speaking for libvirt and based on what I've responded to patch 2 there's
no value in adding this parameter for libvirt's use.

This also kind of means that drive-mirror can be deprecated together
with deprecating -drive.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] Exposing feature deprecation to machine clients

[Max Reitz]

On 07.11.19 20:13, Vladimir Sementsov-Ogievskiy wrote:
> 07.11.2019 21:52, Philippe Mathieu-Daudé wrote:
>> Hi Markus,
>>
>> On 8/15/19 7:40 PM, John Snow wrote:
>>> On 8/15/19 10:16 AM, Markus Armbruster wrote:
 John Snow  writes:
>> [...]
> I asked Markus this not too long ago; do we want to amend the QAPI
> schema specification to allow commands to return with "Warning" strings,
> or "Deprecated" stings to allow in-band deprecation notices for cases
> like these?
>
> example:
>
> { "return": {},
>    "deprecated": True,
>    "warning": "Omitting filter-node-name parameter is deprecated, it will
> be required in the future"
> }
>
> There's no "error" key, so this should be recognized as success by
> compatible clients, but they'll definitely see the extra information.

 This is a compatible evolution of the QMP protocol.

> Part of my motivation is to facilitate a more aggressive deprecation of
> legacy features by ensuring that we are able to rigorously notify users
> through any means that they need to adjust their scripts.

 Yes, we should help libvirt etc. with detecting use of deprecated
 features.  We discussed this at the KVM Forum 2018 BoF on deprecating
 stuff.  Minutes:

  Message-ID: <87mur0ls8o@dusky.pond.sub.org>
  https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html

 Last item is relevant here.

 Adding deprecation information to QMP's success response belongs to "We
 can also pass the buck to the next layer up", next to "emit a QMP
 event".

 Let's compare the two, i.e. "deprecation info in success response"
 vs. "deprecation event".

 1. Possible triggers

 Anything we put in the success response should only ever apply to the
 (successful) command.  So this one's limited to QMP commands.

 A QMP event is not limited to QMP commands.  For instance, it could be
 emitted for deprecated CLI features (long after the fact, in addition to
 human-readable warnings on stderr), or when we detect use of a
 deprecated feature only after we sent the success response, say in a
 job.  Neither use case is particularly convincing.  Reporting use of
 deprecated CLI in QMP feels like a work-around for the CLI's
 machine-unfriendliness.  Job-like commands should really check their
 arguments upfront.

 2. Connection to trigger

 Connecting responses to commands is the QMP protocol's responsibility.
 Transmitting deprecation information in the response trivially ties it
 to the offending command.

 The QMP protocol doesn't tie events to anything.  Thus, a deprecation
 event needs an event-specific tie to its trigger.

 The obvious way to tie it to a command mirrors how the QMP protocol ties
 responses to commands: by command ID.  The event either has to be sent
 just to the offending monitor (currently, all events are broadcast to
 all monitors), or include a suitable monitor ID.

 For non-command triggers, we'd have to invent some other tie.

 3. Interface complexity

 Tying the event to some arbitrary trigger adds complexity.

 Do we need non-command triggers, and badly enough to justify the
 additional complexity?

 4. Implementation complexity

 Emitting an event could be as simple as

  qapi_event_send_deprecated(qmp_command_id(),
     "Omitting 'filter-node-name'");

 where qmp_command_id() returns the ID of the currently executing
 command.  Making qmp_command_id() work is up to the QMP core.  Simple
 enough as long as each QMP command runs to completion before its monitor
 starts the next one.

 The event is "fire and forget".  There is no warning object propagated
 up the call chain into the QMP core like errors objects are.

 "Fire and forget" is ideal for letting arbitrary code decide "this is
 deprecated".

 Note the QAPI schema remains untouched.

 Unlike an event, which can be emitted anywhere, the success response
 gets built in the QMP core.  To have the core add deprecation info to
 it, we need to get the info to the core.

 If deprecation info originates in command code, like errors do, we need
 to propagate it up the call chain into the QMP core like errors.

 Propagating errors is painful.  It has caused massive churn all over the
 place.

 I don't think we can hitch deprecation info to the existing error
 propagation, since we need to take the success path back to the QMP
 core, not an error path.

 Propagating a second object for warnings... thanks, but no thanks.

>>>
>>> Probably the best argument against it. Fire-and-forget avoids the
>>> problem. Events might work just fine, but 

Re: [libvirt] [PATCH v3 13/20] src: esx: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:31PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> 
>  .gitignore  |  1 -
>  src/esx/Makefile.inc.am |  5 +++--
>  src/esx/esx_vi_generator.py | 11 ---
>  tests/Makefile.am   |  3 +++
>  4 files changed, 10 insertions(+), 10 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 14/20] src: hyperv: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:32PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> 
>  .gitignore |  1 -
>  src/hyperv/Makefile.inc.am |  5 +++--
>  src/hyperv/hyperv_wmi_generator.py | 11 +--
>  3 files changed, 8 insertions(+), 9 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 15/20] src: locking: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:33PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> - modify generated_files for sc_po_check as well
> 
>  .gitignore  | 1 -
>  build-aux/syntax-check.mk   | 2 +-
>  src/locking/Makefile.inc.am | 2 +-
>  3 files changed, 2 insertions(+), 3 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 5/5] news: Introduce virConnectSetIdentity API in 5.8

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 10:47:52AM +0100, Jiri Denemark wrote:
> On Fri, Nov 08, 2019 at 15:00:22 +0800, Han Han wrote:
> > Signed-off-by: Han Han 
> > ---
> >  docs/news.xml | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/docs/news.xml b/docs/news.xml
> > index 571a1b6ea4..c37d0d22ef 100644
> > --- a/docs/news.xml
> > +++ b/docs/news.xml
> > @@ -199,6 +199,16 @@
> >backend. It requires qemu over 4.1.
> >  
> >
> > +  
> > +
> > +  Introduce virConnectSetIdentity API
> > +
> > +
> > +  For splited libvirt daemons, this API can be used to forward 
> > uid, gid
> > +  and selinux info from virproxyd to
> > +  virtqemud.
> > +
> > +  
> >  
> >  
> >
> 
> This API is not really supposed to be used by users. It's an internal
> implementation detail and should not be mentioned in news.

Sort of. While the immediate motivation is for internal use, I can
imagine scenarios where mgmt apps might want to use this too. It
applies to any case where one process connecting to libvirt is doing
work on behalf of a user with different privileges.

Consider a web app running under httpd account, but authenticating
its client users. It wants libvirt APIs it invokes to have access
control checks done against the web client user's identity instead
of its own. It would be appropriate for the app to use the new
virConnectSetIdentity API call in this case.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 03/20] syntax-check.mk: fix sc_po_check rule

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:21PM +0200, Pavel Hrdina wrote:
> Commit <22d8e27ccd5faf48ee2bf288a1b9059aa7ffd28b> introduced our
> syntax-check.mk file based on gnulib rules. However, the rule was
> completely ignored as we don't have POTFILES.in file.

Yikes, we've got quite out of date as a result too.

> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> New in v2.
> 
>  build-aux/syntax-check.mk |  2 +-
>  po/POTFILES   | 37 +++--
>  2 files changed, 36 insertions(+), 3 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 04/20] syntax-check.mk: cleanup sc_po_check dependencies

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:22PM +0200, Pavel Hrdina wrote:
> Introduce new rule 'generated-sources' as a helper for PO files check
> to make sure that all generated files are prepared and to not duplicate
> the list on different places.  This will be used as a dependency for
> sc_po_check rule instead of duplicated list of generated files.
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> New in v2.
> 
>  build-aux/syntax-check.mk | 25 ++---
>  src/Makefile.am   |  3 +++
>  2 files changed, 9 insertions(+), 19 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 06/20] po: generate files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:24PM +0200, Pavel Hrdina wrote:
> Historically we did not support VPATH builds and everything was
> generated into source directory.  The introduction of VPATH builds
> did not changed the way how our translation files are handled.
> 
> This patch changes the rules to generate everything into build
> directory and stops distributing generated files in order to have
> properly separated VPATH builds.
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> Changes in v2:
> - keep the zanata binary name, this will be fixed by separate patch
> 
> Chnages in v3:
> - update --transdir and --srcdir options as there are used by
>   python-zanata-client
> 
> Changes in v2:
> - keep the zanata binary name, this will be fixed by separate patch
> 
>  .gitignore |  4 
>  po/Makefile.am | 35 +--
>  2 files changed, 21 insertions(+), 18 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index bd64eb5b1a..4c4807019c 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -39,12 +39,8 @@ Makefile.in
>  .git-module-status
>  
>  # libvirt related ignores
> -!/po/*.mini.po
>  /build/
>  /ci/scratch/
> -/po/*gmo
> -/po/*po
> -/po/*pot
>  /src/access/org.libvirt.api.policy
>  /src/access/viraccessapicheck.c
>  /src/access/viraccessapicheck.h
> diff --git a/po/Makefile.am b/po/Makefile.am
> index b0e2c15d44..7011890255 100644
> --- a/po/Makefile.am
> +++ b/po/Makefile.am
> @@ -16,17 +16,16 @@ LANGS := \
>  
>  
>  POTFILE_DEPS := $(shell $(SED) 's,^,$(top_srcdir)/,' $(srcdir)/POTFILES)
> -POTFILE := $(srcdir)/$(DOMAIN).pot
> -POFILES := $(LANGS:%=$(srcdir)/%.po)
> -GMOFILES := $(LANGS:%=$(srcdir)/%.gmo)
> +POTFILE := $(DOMAIN).pot
> +POMINIFILES := $(LANGS:%=%.mini.po)
> +POFILES := $(LANGS:%=%.po)
> +GMOFILES := $(LANGS:%=%.gmo)
>  
> -MAINTAINERCLEANFILES = $(POTFILE) $(POFILES) $(GMOFILES)
> +CLEANFILES = $(POTFILE) $(POFILES) $(GMOFILES)
>  
>  EXTRA_DIST = \
>   POTFILES \
> - $(POTFILE) \
> - $(POFILES) \
> - $(GMOFILES)
> + $(POMINIFILES)
>  
>  if HAVE_GNU_GETTEXT_TOOLS
>  
> @@ -63,10 +62,18 @@ update-mini-po: $(POTFILE)
>   done
>  
>  push-pot: $(POTFILE)
> - zanata push --push-type=source
> + zanata push \
> + --project-config $(srcdir)/zanata.xml \
> + --push-type=source \
> + --transdir $(builddir) \
> + --srcdir $(srcdir)
>  
>  pull-po: $(POTFILE)
> - zanata pull --create-skeletons
> + zanata pull \
> + --project-config $(srcdir)/zanata.xml \
> + --create-skeletons \
> + --transdir $(builddir) \
> + --srcdir $(srcdir)
>   $(MAKE) update-mini-po
>   $(MAKE) update-gmo
>  
> @@ -76,19 +83,17 @@ $(POTFILE): POTFILES $(POTFILE_DEPS)
>   $(SED) $(SED_PO_FIXUP_ARGS) < $@-t > $@
>   rm -f $@-t
>  
> -$(srcdir)/%.po: $(srcdir)/%.mini.po $(POTFILE)
> +%.po: %.mini.po $(POTFILE)
>   $(MSGMERGE) --no-fuzzy-matching $< $(POTFILE) | \
> $(SED) $(SED_PO_FIXUP_ARGS) > $@
>  
> -$(srcdir)/%.gmo: $(srcdir)/%.po
> +%.gmo: %.po
>   rm -f $@ $@-t
>   $(MSGFMT) -c -o $@-t $<
>   mv $@-t $@
>  
>  .PRECIOUS: $(POTFILE) $(POFILES)
>  
> -endif HAVE_GNU_GETTEXT_TOOLS
> -
>  if ENABLE_NLS
>  
>  # Cannot use 'localedir' since this conflicts with autoconf.
> @@ -99,7 +104,7 @@ install-data-hook: $(GMOFILES)
>   for lang in $(LANGS); do \
> d=$(DESTDIR)$(langinstdir)/$$lang/LC_MESSAGES; \
> mkdir -p $$d; \
> -   install -m 0644 $(srcdir)/$$lang.gmo $$d/$(DOMAIN).mo; \
> +   install -m 0644 $$lang.gmo $$d/$(DOMAIN).mo; \
>   done
>  
>  uninstall-hook:
> @@ -109,3 +114,5 @@ uninstall-hook:
>   done
>  
>  endif ENABLE_NLS
> +
> +endif HAVE_GNU_GETTEXT_TOOLS

Moving this HAVE_GNU_GETTEXT_TOOLS conditional means that on OS that
lack the GNU gettext impl, we are no longer able to 'make install'
the translation files, despite having them prebuilt & bundled in the
tarball.

IIRC, this affects any non-Linux host.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 5/5] news: Introduce virConnectSetIdentity API in 5.8

[Han Han]

Well, excluding developers and testers, few people use libvirt directly by
APIs. Since libvirt is also a library,
it is worthwhile to mention updates on public APIs in release notes even it
is supposed for internal implementation.

On Fri, Nov 8, 2019 at 5:47 PM Jiri Denemark  wrote:

> On Fri, Nov 08, 2019 at 15:00:22 +0800, Han Han wrote:
> > Signed-off-by: Han Han 
> > ---
> >  docs/news.xml | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/docs/news.xml b/docs/news.xml
> > index 571a1b6ea4..c37d0d22ef 100644
> > --- a/docs/news.xml
> > +++ b/docs/news.xml
> > @@ -199,6 +199,16 @@
> >backend. It requires qemu over 4.1.
> >  
> >
> > +  
> > +
> > +  Introduce virConnectSetIdentity API
> > +
> > +
> > +  For splited libvirt daemons, this API can be used to forward
> uid, gid
> > +  and selinux info from virproxyd to
> > +  virtqemud.
> > +
> > +  
> >  
> >  
> >
>
> This API is not really supposed to be used by users. It's an internal
> implementation detail and should not be mentioned in news.
>
> Jirka
>


-- 
Best regards,
---
Han Han
Quality Engineer
Redhat.

Email: h...@redhat.com
Phone: +861065339333
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 07/20] po: rewrite the way how we generate files

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:25PM +0200, Pavel Hrdina wrote:
> There was no need to handle files for translation from build directory
> but that will change with following patches where we will stop
> generating source files into source directory.
> 
> In order to have them included for translation we have to prefix each
> file with SRCDIR or BUILDDIR.
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> Changes in v2:
> - add builddir paths for sc_po_check to detect generated source
>   files and generate correct diff if the check fails
> 
>  build-aux/syntax-check.mk |   8 +-
>  po/Makefile.am|  14 +-
>  po/POTFILES   | 353 --
>  po/POTFILES.in| 353 ++
>  4 files changed, 368 insertions(+), 360 deletions(-)
>  delete mode 100644 po/POTFILES
>  create mode 100644 po/POTFILES.in

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] qemu_process: fix starting VMs if machine group has limited cpuset.cpus

[Pavel Hrdina]

Commit  reworked process
affinity setting but did not take cgroups into account which introduced
an issue when starting VM with custom cpuset.cpus for the whole machine
group.

If the machine group is limited to some pCPUs libvirt should not try to
set a VM to run on all pCPUs as it will result in permission denied when
writing to cpuset.cpus.

To fix this the affinity has to be set separately from cgroups cpuset.

Resolves: 

Signed-off-by: Pavel Hrdina 
---
 src/qemu/qemu_process.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index ed8666e9d1..355b740caf 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -2636,6 +2636,7 @@ qemuProcessSetupPid(virDomainObjPtr vm,
 virDomainNumatuneMemMode mem_mode;
 virCgroupPtr cgroup = NULL;
 virBitmapPtr use_cpumask = NULL;
+virBitmapPtr afinity_cpumask = NULL;
 g_autoptr(virBitmap) hostcpumap = NULL;
 char *mem_mask = NULL;
 int ret = -1;
@@ -2661,7 +2662,7 @@ qemuProcessSetupPid(virDomainObjPtr vm,
  * its config file */
 if (qemuProcessGetAllCpuAffinity() < 0)
 goto cleanup;
-use_cpumask = hostcpumap;
+afinity_cpumask = hostcpumap;
 }
 
 /*
@@ -2702,8 +2703,11 @@ qemuProcessSetupPid(virDomainObjPtr vm,
 
 }
 
+if (!afinity_cpumask)
+afinity_cpumask = use_cpumask;
+
 /* Setup legacy affinity. */
-if (use_cpumask && virProcessSetAffinity(pid, use_cpumask) < 0)
+if (afinity_cpumask && virProcessSetAffinity(pid, afinity_cpumask) < 0)
 goto cleanup;
 
 /* Set scheduler type and priority, but not for the main thread. */
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 1/6] docs: split TLS certificate setup into its own file

[Daniel P . Berrangé]

The generation and deployment of x509 certificates for TLS is complex
and verbose and thus deserves its own standalone page.

Signed-off-by: Daniel P. Berrangé 
---
 docs/docs.html.in |   3 +
 docs/remote.html.in   | 408 +
 docs/tlscerts.html.in | 413 ++
 3 files changed, 417 insertions(+), 407 deletions(-)
 create mode 100644 docs/tlscerts.html.in

diff --git a/docs/docs.html.in b/docs/docs.html.in
index 6cf09f51bc..4b59162e0f 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -18,6 +18,9 @@
 Remote access
 Enable remote access over TCP
 
+TLS certs
+Generate and deploy x509 certificates for TLS
+
 Authentication
 Configure authentication for the libvirt daemon
 
diff --git a/docs/remote.html.in b/docs/remote.html.in
index 78e071a898..5a0ebe4790 100644
--- a/docs/remote.html.in
+++ b/docs/remote.html.in
@@ -61,7 +61,7 @@ Remote libvirt supports a range of transports:
   http://en.wikipedia.org/wiki/Transport_Layer_Security; 
title="Transport Layer Security">TLS
  1.0 (SSL 3.1) authenticated and encrypted TCP/IP socket, usually
  listening on a public port number.  To use this you will need to
- generate 
client and
+ generate client 
and
  server certificates.
  The standard port is 16514.
  
@@ -382,412 +382,6 @@ Note that parameter values must be
  Example: sshauth=privkey,agent 
   
 
-
-  Generating TLS certificates
-
-
-  Public Key Infrastructure set up
-
-
-If you are unsure how to create TLS certificates, skip to the
-next section.
-
-
-  
- Location 
- Machine 
- Description 
- Required fields 
-  
-  
-
-  /etc/pki/CA/cacert.pem
-
- Installed on the client and server 
- CA's certificate (more info)
- n/a 
-  
-  
-
-  $HOME/.pki/cacert.pem
-
- Installed on the client 
- CA's certificate (more info)
- n/a 
-  
-  
-
-  /etc/pki/libvirt/private/serverkey.pem
-
- Installed on the server 
- Server's private key (more info)
- n/a 
-  
-  
-
-  /etc/pki/libvirt/servercert.pem
-
- Installed on the server 
- Server's certificate signed by the CA.
- (more info) 
- CommonName (CN) must be the hostname of the server as it
-  is seen by clients. All hostname and IP address variants that might
-  be used to reach the server should be listed in Subject Alt Name
-  fields.
-  
-  
-
-  /etc/pki/libvirt/private/clientkey.pem
-
- Installed on the client 
- Client's private key. (more info) 
- n/a 
-  
-  
-
-  /etc/pki/libvirt/clientcert.pem
-
- Installed on the client 
- Client's certificate signed by the CA
-  (more info) 
- Distinguished Name (DN) can be checked against an access
-  control list (tls_allowed_dn_list).
-  
-  
-  
-
-  $HOME/.pki/libvirt/clientkey.pem
-
- Installed on the client 
- Client's private key. (more info) 
- n/a 
-  
-  
-
-  $HOME/.pki/libvirt/clientcert.pem
-
- Installed on the client 
- Client's certificate signed by the CA
-  (more info) 
- Distinguished Name (DN) can be checked against an access
-  control list (tls_allowed_dn_list).
-  
-  
-
-
-  If 'pkipath' is specified in URI, then all the client
-  certificates must be found in the path specified, otherwise the
-  connection will fail with a fatal error. If 'pkipath' is not
-  specified:
-
-
-   For a non-root user, libvirt tries to find the certificates
-in $HOME/.pki/libvirt first. If the required CA certificate cannot
-be found, then the global default location
-(/etc/pki/CA/cacert.pem) will be used.
-Likewise, if either the client certificate
-or the client key cannot be found, then the global default
-locations (/etc/pki/libvirt/clientcert.pem,
-/etc/pki/libvirt/private/clientkey.pem) will be used.
-  
-   For the root user, the global default locations will always be 
used.
-
-
-  Background to TLS certificates
-
-
-Libvirt supports TLS certificates for verifying the identity
-of the server and clients.  There are two distinct checks involved:
-
-
-   The client should know that it is connecting to the right
-server.  Checking done by client by matching the certificate that
-the server sends to the server's hostname.  May be disabled by adding
-?no_verify=1 to the
-remote URI.
-
-   The server should know that only permitted clients are
-connecting.  This can be done based on client's IP address, 

[libvirt] [PATCH 4/6] docs: adapt filling of section for rst2html output

[Daniel P . Berrangé]

The HTML from rst2html doesn't have  immediately under the 
tag, instead there is at least one  in between.

There are also many things added in the  section that we don't
want to have copied over, since our templating system already adds
suitable  elements.

We only need to copy the 

[libvirt] [PATCH 3/6] build: introduce rst2html as a mandatory build tool

[Daniel P . Berrangé]

The rst2html tool is provided by python docutils, and as the name
suggests, it converts RST documents into HTML.

This enables us to start writing docs on our website in RST format
instead of HTML, without changing the rest of our website templating
system away from XSLT yet.

Signed-off-by: Daniel P. Berrangé 
---
 libvirt.spec.in  | 2 ++
 m4/virt-external-programs.m4 | 5 +
 mingw-libvirt.spec.in| 1 +
 3 files changed, 8 insertions(+)

diff --git a/libvirt.spec.in b/libvirt.spec.in
index dcad08cb5f..84efe47ffc 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -260,6 +260,8 @@ BuildRequires: automake
 BuildRequires: gettext-devel
 BuildRequires: libtool
 BuildRequires: /usr/bin/pod2man
+# Replace with python3-docutils when we drop py2 support
+BuildRequires: /usr/bin/rst2html
 %endif
 BuildRequires: gcc
 BuildRequires: git
diff --git a/m4/virt-external-programs.m4 b/m4/virt-external-programs.m4
index 0f995998c3..b7779f159e 100644
--- a/m4/virt-external-programs.m4
+++ b/m4/virt-external-programs.m4
@@ -33,6 +33,11 @@ AC_DEFUN([LIBVIRT_CHECK_EXTERNAL_PROGRAMS], [
   then
 AC_MSG_ERROR("xsltproc is required to build libvirt")
   fi
+  AC_PATH_PROG([RST2HTML], [rst2html], [])
+  if test -z "$RST2HTML"
+  then
+AC_MSG_ERROR("rst2html is required to build libvirt")
+  fi
   AC_PATH_PROG([AUGPARSE], [augparse], [/usr/bin/augparse])
   AC_PROG_MKDIR_P
   AC_PROG_LN_S
diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in
index c29f3eeed2..35f1abc13d 100644
--- a/mingw-libvirt.spec.in
+++ b/mingw-libvirt.spec.in
@@ -82,6 +82,7 @@ BuildRequires: automake
 BuildRequires: gettext-devel
 BuildRequires: libtool
 %endif
+BuildRequires: python3-docutils
 
 BuildRequires: mingw32-libssh2
 BuildRequires: mingw64-libssh2
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 5/6] docs: add a kbase page about RPM packaging options

[Daniel P . Berrangé]

The libvirt RPM packaging is quite fine grained but it is not obvious to
users which package is best to install. Add a kbase doc that describes
the different RPMs, and illustrates some example deployment use cases.

Signed-off-by: Daniel P. Berrangé 
---
 .gitignore|   1 +
 docs/Makefile.am  |  14 +-
 docs/kbase.html.in|   4 +
 docs/kbase/rpm-deployment.rst | 410 ++
 4 files changed, 427 insertions(+), 2 deletions(-)
 create mode 100644 docs/kbase/rpm-deployment.rst

diff --git a/.gitignore b/.gitignore
index c45b8bd098..cc6b19a7bf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -64,6 +64,7 @@
 /docs/apibuild.py.stamp
 /docs/devhelp/libvirt.devhelp
 /docs/hvsupport.html.in
+/docs/kbase/rpm-deployment.html.in
 /docs/libvirt-admin-*.xml
 /docs/libvirt-api.xml
 /docs/libvirt-lxc-*.xml
diff --git a/docs/Makefile.am b/docs/Makefile.am
index 0311bbedd8..2b04f3b362 100644
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -114,7 +114,13 @@ internals_html = $(internals_html_in:%.html.in=%.html)
 
 kbase_html_in = \
   $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.html.in))
-kbase_html = $(kbase_html_in:%.html.in=%.html)
+kbase_rst = \
+  $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.rst))
+kbase_rst_html_in = \
+  $(kbase_rst:%.rst=%.html.in)
+kbase_html = \
+  $(kbase_html_in:%.html.in=%.html) \
+  $(kbase_rst_html_in:%.html.in=%.html)
 
 # Generate hvsupport.html and news.html first, since they take one extra step.
 dot_html_generated_in = \
@@ -170,7 +176,7 @@ EXTRA_DIST= \
   $(fig) $(png) $(css) \
   $(javascript) $(logofiles) \
   $(internals_html_in) $(fonts) \
-  $(kbase_html_in) \
+  $(kbase_html_in) $(kbase_rst) \
   aclperms.htmlinc \
   hvsupport.pl \
   $(schema_DATA)
@@ -186,6 +192,7 @@ CLEANFILES = \
   $(apihtml) \
   $(internals_html) \
   $(kbase_html) \
+  $(kbase_rst_html_in) \
   $(xml) \
   $(qemu_xml) \
   $(lxc_xml) \
@@ -235,6 +242,9 @@ EXTRA_DIST += \
 %.png: %.fig
convert -rotate 90 $< $@
 
+%.html.in: %.rst
+   $(AM_V_GEN)rst2html $< > $@
+
 %.html.tmp: %.html.in site.xsl subsite.xsl page.xsl \
$(acl_generated)
$(AM_V_GEN)name=`echo $@ | sed -e 's/.tmp//'`; \
diff --git a/docs/kbase.html.in b/docs/kbase.html.in
index 97d3f4c384..a5504a540f 100644
--- a/docs/kbase.html.in
+++ b/docs/kbase.html.in
@@ -21,6 +21,10 @@
 capture
 Comparison between different methods of capturing domain
   state
+
+RPM deployment
+Explanation of the different RPM packages and illustration of
+  which to pick for installation
   
 
 
diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst
new file mode 100644
index 00..8f1584d7ea
--- /dev/null
+++ b/docs/kbase/rpm-deployment.rst
@@ -0,0 +1,410 @@
+===
+RPM Deployment Guidance
+===
+
+.. contents::
+
+A complete libvirt build includes a wide range of features, many of which are
+dynamically loadable at runtime. Applications using libvirt typically only
+need to use a subset of these features, and so do not require a full install
+of all libvirt RPM packages.
+
+This document provides some guidance on the RPM packages available with libvirt
+on Fedora and related distributions, to enable applications and administrators
+to pick the optimal set for their needs.
+
+The RHEL and CentOS distributions use the same RPM packaging split, but many
+of the drivers will be disabled at build time, so not all of the packages
+listed on this page will exist.
+
+
+RPM packages
+
+
+* libvirt
+
+  This is an empty package that exists solely as a convenient way to install
+  every other libvirt RPM package. Almost every deployment scenario would be
+  better served by picking one of the other RPMs listed below.
+
+* libvirt-admin
+
+  The virt-admin tool, used for administrative operations on any libvirt
+  daemons. Most usefully it allows for logging filters and outputs to be
+  reconfigured on a running daemon without a restart. This is recommended
+  to be installed on any host running a libvirt daemon.
+
+
+* libvirt-bash-completion
+
+  Argument auto-completion support for the Bash shell. This is shared code that
+  is pulled in by either the libvirt-admin or libvirt-clients RPMs, so there is
+  no need to explicitly ask for this package to be installed.
+
+
+* libvirt-client
+
+  The virsh tool, used for interacting with any libvirt driver, both primary
+  virt drivers and secondary drivers for storage, networking, etc. All libvirt
+  installs should have this installed as it provides a useful way to view and
+  debug what is being done by other applications using libvirt.
+
+
+* libvirt-daemon
+
+  The monolithic libvirtd daemon, traditionally used for running all the
+  stateful drivers. This package does not contain any drivers, so further
+  packages need to be installed to provide the desired drivers.
+
+
+* 

[libvirt] [PATCH 0/6] docs: some refactoring and new docs about RPM deployment

[Daniel P . Berrangé]

This refactors existing docs related to the remote driver/daemon and
URIs. It then also adds a kbase page about RPM package options.

This introduces the use of RST for docs as a replacement for HTML.
The intent is that all new docs should use RST from this point.

Existing HTML docs are candidates for conversion to RST by anyone
interested.

Daniel P. Berrangé (6):
  docs: split TLS certificate setup into its own file
  docs: move docs about remote driver URIs into URI docs
  build: introduce rst2html as a mandatory build tool
  docs: adapt filling of  section for rst2html output
  docs: add a kbase page about RPM packaging options
  docs: add page describing the libvirt daemons

 .gitignore|   1 +
 docs/Makefile.am  |  21 +-
 docs/daemons.rst  | 209 +++
 docs/docs.html.in |   6 +
 docs/kbase.html.in|   4 +
 docs/kbase/rpm-deployment.rst | 410 
 docs/page.xsl |   4 +-
 docs/remote.html.in   | 684 +-
 docs/tlscerts.html.in | 413 
 docs/uri.html.in  | 263 +++--
 libvirt.spec.in   |   2 +
 m4/virt-external-programs.m4  |   5 +
 mingw-libvirt.spec.in |   1 +
 13 files changed, 1309 insertions(+), 714 deletions(-)
 create mode 100644 docs/daemons.rst
 create mode 100644 docs/kbase/rpm-deployment.rst
 create mode 100644 docs/tlscerts.html.in

-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [jenkins-ci PATCH] Add python-docutils package for libvirt

[Daniel P . Berrangé]

This is needed to acquire the rst2html command line tool

Signed-off-by: Daniel P. Berrangé 
---
 guests/vars/mappings.yml | 5 +
 guests/vars/projects/libvirt.yml | 1 +
 2 files changed, 6 insertions(+)

diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index ba0f1cf..a6df789 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -795,6 +795,11 @@ mappings:
 default: polkit
 deb: policykit-1
 
+  python-docutils:
+default: python3-docutils
+CentOS7: python2-docutils
+FreeBSD: py36-docutils
+
   python2:
 default: python
 Fedora: python2
diff --git a/guests/vars/projects/libvirt.yml b/guests/vars/projects/libvirt.yml
index 8fcb286..38a979a 100644
--- a/guests/vars/projects/libvirt.yml
+++ b/guests/vars/projects/libvirt.yml
@@ -46,6 +46,7 @@ packages:
   - openwsman
   - parted
   - polkit
+  - python-docutils
   - qemu-img
   - radvd
   - readline
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 6/6] docs: add page describing the libvirt daemons

[Daniel P . Berrangé]

Now that we have more than just the libvirtd daemon, we should be
explaining to users what they are all for & important aspects of their
configuration.

Signed-off-by: Daniel P. Berrangé 
---
 docs/Makefile.am  |   7 +-
 docs/daemons.rst  | 209 ++
 docs/docs.html.in |   3 +
 3 files changed, 218 insertions(+), 1 deletion(-)
 create mode 100644 docs/daemons.rst

diff --git a/docs/Makefile.am b/docs/Makefile.am
index 2b04f3b362..3dd61640b5 100644
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -128,9 +128,14 @@ dot_html_generated_in = \
   news.html.in
 dot_html_in = \
   $(notdir $(wildcard $(srcdir)/*.html.in))
+dot_rst = \
+  $(notdir $(wildcard $(srcdir)/*.rst))
+dot_rst_html_in = \
+  $(dot_rst:%.rst=%.html)
 dot_html = \
   $(dot_html_generated_in:%.html.in=%.html) \
-  $(dot_html_in:%.html.in=%.html)
+  $(dot_html_in:%.html.in=%.html) \
+  $(dot_rst_html_in:%.html.in=%.html)
 
 xml = \
   libvirt-api.xml \
diff --git a/docs/daemons.rst b/docs/daemons.rst
new file mode 100644
index 00..51d4153b99
--- /dev/null
+++ b/docs/daemons.rst
@@ -0,0 +1,209 @@
+===
+Libvirt Daemons
+===
+
+.. contents:: Topics
+
+A libvirt deployment for accessing one of the stateful drivers will require
+one or more daemons to be deployed on the virtualization host. There are a
+number of ways the daemons can be configured which will be outlined in this
+page
+
+Monolithic driver daemon
+
+
+Traditionally libvirt has provided a single monolithic daemon called `libvirtd`
+which exposed support for all the stateful drivers, both primary hypervisor
+drivers and secondary supporting drivers. It also enables secure remote access
+from clients running off host.
+
+Operating modes
+---
+
+The daemon can operate in two modes
+
+* *System mode* - `libvirtd` is running as the root user account, enabling
+  access to its full range of functionality. A read-write connection to
+  `libvirtd` in system mode **implies privileges equivalent to having a root
+  shell**. Suitable `authentication mechanisms `_ **must be 
enabled**
+  to secure it against untrustworthy clients/users.
+
+* *Session mode* - `libvirtd` is running as any non-root user account, enabling
+  access to a more restricted range of functionality. Only client apps/users
+  running under **the same UID are permitted to connect**, thus a connection
+  does not imply any elevation of privileges.
+
+
+Sockets
+---
+
+When running in system mode, `libvirtd` exposes three UNIX domain sockets, and
+optionally, one or two TCP sockets
+
+* `/var/run/libvirt/libvirt-sock` - the primary socket for accessing libvirt
+  APIs, with full read-write privileges. A connection to this socket gives the
+  client privileges that are equivalent to having a root shell. This is the
+  socket that most management applications connect to by default.
+
+* `/var/run/libvirt/libvirt-sock-ro` - the secondary socket for accessing
+  libvirt APIs, with limited read-only privileges. A connection to this socket
+  gives the ability to query the existance of objects and monitor some aspects
+  of their operation. This is the socket that most management applications
+  connect to when requesting read only mode. Typically this is what a
+  monitoring app would use.
+
+* `/var/run/libvirt/libvirt-sock-admin` - the administrative socket for
+  controlling operation of the daemon itself (as opposed to drivers it is
+  running). This can be used to dynamically reconfigure some aspects of the
+  daemon and monitor/control connected clients.
+
+* `TCP 16509` - the non-TLS socket for remotely accessing the libvirt APIs,
+  with full read-write privileges. A connection to this socket gives the
+  client privileges that are equivalent to having a root shell. Since it does
+  not use TLS, an `authentication mechanism `_ that provides
+  encryption must be used. Only the GSSAPI/Kerberos mechanism is capable of
+  satisfying this requirement. In general applications should not use this
+  socket except for debugging in a development/test environment.
+
+* `TCP 16514` - the TLS socket for remotely accessing the libvirt APIs,
+  with full read-write privileges. A connection to this socket gives the
+  client privileges that are equivalent to having a root shell. Access control
+  can be enforced either through validation of `x509 certificates
+  `_, and/or by enabling an `authentication mechanism
+  `_.
+
+When running in session mode, `libvirtd` exposes two UNIX domain sockets
+
+* `$XDG_RUNTIME_DIR/libvirt/libvirt-sock` - the primary socket for accessing
+  libvirt APIs, with full read-write privileges. A connection to this socket
+  does not alter the privileges that the client already has. This is the
+  socket that most management applications connect to by default.
+
+* `$XDG_RUNTIME_DIR/libvirt/libvirt-sock-admin` - the administrative socket for
+  controlling operation of the daemon itself (as opposed 

[libvirt] [PATCH 2/6] docs: move docs about remote driver URIs into URI docs

[Daniel P . Berrangé]

The docs about remote URIs in uri.html are somewhat sparse with the full
docs being in remote.html. Move all the URI content from remote.html
into uri.html so the user only needs to look in one place for URI info.

Signed-off-by: Daniel P. Berrangé 
---
 docs/remote.html.in | 278 +---
 docs/uri.html.in| 263 -
 2 files changed, 238 insertions(+), 303 deletions(-)

diff --git a/docs/remote.html.in b/docs/remote.html.in
index 5a0ebe4790..0b0dc87f6f 100644
--- a/docs/remote.html.in
+++ b/docs/remote.html.in
@@ -34,7 +34,7 @@ the system-wide QEMU daemon on a remote machine called
 qemu://compute1.libvirt.org/system.
 
 
-The section on remote URIs
+The section on remote URIs
 describes in more detail these remote URIs.
 
 
@@ -109,279 +109,9 @@ even with graphical management applications. As with the 
classic ssh transport
 netcat is required on the remote side.
 
 
-The default transport, if no other is specified, is tls.
-
-
-  Remote URIs
-
-
-See also: documentation on ordinary ("local") URIs.
-
-
-Remote URIs have the general form ("[...]" meaning an optional part):
-
-
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
-
-
-Either the transport or the hostname must be given in order
-to distinguish this from a local URI.
-
-
-Some examples:
-
-
-  xen+ssh://rjones@towada/system  Connect to 
a
-remote Xen hypervisor on host towada using ssh transport and ssh
-username rjones.
-
-  xen://towada/system  Connect to a
-remote Xen hypervisor on host towada using TLS.
-
-  xen://towada/system?no_verify=1  Connect 
to a
-remote Xen hypervisor on host towada using TLS.  Do not verify
-the server's certificate.
-
-  
qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
 
-Connect to the local qemu instances over a non-standard
-Unix socket (the full path to the Unix socket is
-supplied explicitly in this case).
-
-  test+tcp://localhost:5000/default 
-Connect to a libvirtd daemon offering unencrypted TCP/IP connections
-on localhost port 5000 and use the test driver with default
-settings.
-
-qemu+libssh2://user@host/system?known_hosts=/home/user/.ssh/known_hosts
 
-Connect to a remote host using a ssh connection with the libssh2 driver
-and use a different known_hosts file.
-qemu+libssh://user@host/system?known_hosts=/home/user/.ssh/known_hosts
 
-Connect to a remote host using a ssh connection with the libssh driver
-and use a different known_hosts file.
-
-
-  Extra parameters
-
-
-Extra parameters can be added to remote URIs as part
-of the query string (the part following ?).
-Remote URIs understand the extra parameters shown below.
-Any others are passed unmodified through to the back end.
-Note that parameter values must be
-http://xmlsoft.org/html/libxml-uri.html#xmlURIEscapeStr;>URI-escaped.
-
-
-  
- Name 
- Transports 
- Meaning 
-  
-  
-
-  name
-
-
-  any transport
-
-
-  The name passed to the remote virConnectOpen function.  The
-  name is normally formed by removing transport, hostname, port
-  number, username and extra parameters from the remote URI, but in certain
-  very complex cases it may be better to supply the name explicitly.
-
-  
-  
-
- Example: name=qemu:///system 
-  
-  
-
-  tls_priority
-
- tls 
-
-  A vaid GNUTLS priority string
-
-  
-  
-
- Example: tls_priority=NORMAL:-VERS-SSL3.0 
-  
-  
-
-  mode
-
- unix, ssh, libssh, libssh2 
-
-  
-autoautomatically determine the 
daemon
-directconnect to per-driver daemons
-legacyconnect to libvirtd
-  
-  Can also be set in libvirt.conf as 
remote_mode
-
-  
-  
-
- Example: mode=direct 
-  
-  
-
-  command
-
- ssh, ext 
-
-  The external command.  For ext transport this is required.
-  For ssh the default is ssh.
-  The PATH is searched for the command.
-
-  
-  
-
- Example: command=/opt/openssh/bin/ssh 
-  
-  
-
-  socket
-
- unix, ssh, libssh2, libssh 
-
-  The path to the Unix domain socket, which overrides the
-  compiled-in default.  For ssh transport, this is passed to
-  the remote netcat command (see next).
-
-  
-  
-
- Example: 
socket=/opt/libvirt/run/libvirt/libvirt-sock 
-  
-  
-
-  netcat
-
- ssh, libssh2, libssh 
-
-  The name of the netcat command on the remote machine.
-  The default is nc.  For ssh transport, libvirt
-  constructs an ssh command which looks like:
-
-command -p port [-l 

Re: [libvirt] [jenkins-ci PATCH 1/5] guests: Explicitly enable ssh root login in kickstart

[Erik Skultety]

On Thu, Nov 07, 2019 at 07:51:57PM +0100, Andrea Bolognani wrote:
> Both CentOS and Fedora have had this enabled by default up until
> now, but that's no longer the case as of Fedora 31. Enabling it
> explicitly makes the first connection work as expected on the
> newer distributions without impacting the older ones negatively.

Now that I read ^this, I'm wondering whether it wouldn't be worth also adding

services --enabled sshd

to the kickstart - I know, this is only useful with the workstation flavour
which comes with SSH daemon disabled, but I think it doesn't hurt to specify
this explicitly, especially in context of ansible, just my 2c.

Erik

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH 0/5] Add Fedora 31, drop Fedora 29

[Erik Skultety]

On Thu, Nov 07, 2019 at 07:51:56PM +0100, Andrea Bolognani wrote:
> You know the drill :)
>
> Andrea Bolognani (5):
>   guests: Explicitly enable ssh root login in kickstart
>   guests: Add Fedora 31
>   Start building on Fedora 31
>   Stop building on Fedora 29
>   guests: Drop Fedora 29

Reviewed-by: Erik Skultety 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 09/20] remote: unify rpc server dispatch generated files

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:27PM +0200, Pavel Hrdina wrote:
> Our naming was not consistent.  Use the protocol name as prefix for all
> generated files.
> 
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - modify generated_files in for sc_po_check as well
> 
>  build-aux/syntax-check.mk   |  3 ++-
>  src/remote/Makefile.inc.am  | 12 ++--
>  src/remote/remote_daemon_dispatch.c |  4 ++--
>  3 files changed, 10 insertions(+), 9 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 08/20] po: README.md: add a note about which Zanata client is required

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:26PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> New in v3.
> 
>  po/README.md | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Daniel P. Berrangé 

> 
> diff --git a/po/README.md b/po/README.md
> index 71b5793a2d..2f77c5d48c 100644
> --- a/po/README.md
> +++ b/po/README.md
> @@ -4,6 +4,9 @@ Libvirt Message Translation
>  Libvirt translatable messages are maintained using the GNU Gettext tools and
>  file formats, in combination with the Zanata web service.
>  
> +python-zanata-client is required in order to use make to pull/push 
> translations
> +from/to Zanata server.
> +

FYI, as a heads up the Zanata project is dead as Red Hat reorg disbanded
its development team.

Fedora is intending to switch to a new tool called Weblate, and most likely
libvirt (and related projects) will do likewise in order to keep the Fedora
translation team engaged.

I'm hopeful it shouldn't be disruptive to us, just swapping in a new tool
for upload/download.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 18/20] src: remote: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:36PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> - modify generated_files for sc_po_check as well
> 
>  .gitignore |  2 --
>  build-aux/syntax-check.mk  |  2 --
>  po/POTFILES.in |  4 ++--
>  src/remote/Makefile.inc.am | 12 ++--
>  4 files changed, 8 insertions(+), 12 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2 1/2] qapi: add filter-node-name option to drive-mirror

[Vladimir Sementsov-Ogievskiy]

To correspond to blockdev-mirror command and make it possible to
deprecate implicit filters in the next commit.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 qapi/block-core.json | 7 +++
 blockdev.c   | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index aa97ee2641..93530d3a13 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1992,6 +1992,12 @@
 # @on-target-error: the action to take on an error on the target,
 #   default 'report' (no limitations, since this applies to
 #   a different block device than @device).
+#
+# @filter-node-name: the node name that should be assigned to the
+#filter driver that the mirror job inserts into the graph
+#above @device. If this option is not given, a node name is
+#autogenerated. (Since: 4.2)
+#
 # @unmap: Whether to try to unmap target sectors where source has
 # only zero. If true, and target unallocated sectors will read as zero,
 # target image sectors will be unmapped; otherwise, zeroes will be
@@ -2022,6 +2028,7 @@
 '*speed': 'int', '*granularity': 'uint32',
 '*buf-size': 'int', '*on-source-error': 'BlockdevOnError',
 '*on-target-error': 'BlockdevOnError',
+'*filter-node-name': 'str',
 '*unmap': 'bool', '*copy-mode': 'MirrorCopyMode',
 '*auto-finalize': 'bool', '*auto-dismiss': 'bool' } }
 
diff --git a/blockdev.c b/blockdev.c
index 8e029e9c01..2ca614c77f 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -4008,7 +4008,7 @@ void qmp_drive_mirror(DriveMirror *arg, Error **errp)
arg->has_on_source_error, arg->on_source_error,
arg->has_on_target_error, arg->on_target_error,
arg->has_unmap, arg->unmap,
-   false, NULL,
+   arg->has_filter_node_name, arg->filter_node_name,
arg->has_copy_mode, arg->copy_mode,
arg->has_auto_finalize, arg->auto_finalize,
arg->has_auto_dismiss, arg->auto_dismiss,
-- 
2.21.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] Exposing feature deprecation to machine clients

[Vladimir Sementsov-Ogievskiy]

07.11.2019 21:52, Philippe Mathieu-Daudé wrote:
> Hi Markus,
> 
> On 8/15/19 7:40 PM, John Snow wrote:
>> On 8/15/19 10:16 AM, Markus Armbruster wrote:
>>> John Snow  writes:
> [...]
 I asked Markus this not too long ago; do we want to amend the QAPI
 schema specification to allow commands to return with "Warning" strings,
 or "Deprecated" stings to allow in-band deprecation notices for cases
 like these?

 example:

 { "return": {},
    "deprecated": True,
    "warning": "Omitting filter-node-name parameter is deprecated, it will
 be required in the future"
 }

 There's no "error" key, so this should be recognized as success by
 compatible clients, but they'll definitely see the extra information.
>>>
>>> This is a compatible evolution of the QMP protocol.
>>>
 Part of my motivation is to facilitate a more aggressive deprecation of
 legacy features by ensuring that we are able to rigorously notify users
 through any means that they need to adjust their scripts.
>>>
>>> Yes, we should help libvirt etc. with detecting use of deprecated
>>> features.  We discussed this at the KVM Forum 2018 BoF on deprecating
>>> stuff.  Minutes:
>>>
>>>  Message-ID: <87mur0ls8o@dusky.pond.sub.org>
>>>  https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html
>>>
>>> Last item is relevant here.
>>>
>>> Adding deprecation information to QMP's success response belongs to "We
>>> can also pass the buck to the next layer up", next to "emit a QMP
>>> event".
>>>
>>> Let's compare the two, i.e. "deprecation info in success response"
>>> vs. "deprecation event".
>>>
>>> 1. Possible triggers
>>>
>>> Anything we put in the success response should only ever apply to the
>>> (successful) command.  So this one's limited to QMP commands.
>>>
>>> A QMP event is not limited to QMP commands.  For instance, it could be
>>> emitted for deprecated CLI features (long after the fact, in addition to
>>> human-readable warnings on stderr), or when we detect use of a
>>> deprecated feature only after we sent the success response, say in a
>>> job.  Neither use case is particularly convincing.  Reporting use of
>>> deprecated CLI in QMP feels like a work-around for the CLI's
>>> machine-unfriendliness.  Job-like commands should really check their
>>> arguments upfront.
>>>
>>> 2. Connection to trigger
>>>
>>> Connecting responses to commands is the QMP protocol's responsibility.
>>> Transmitting deprecation information in the response trivially ties it
>>> to the offending command.
>>>
>>> The QMP protocol doesn't tie events to anything.  Thus, a deprecation
>>> event needs an event-specific tie to its trigger.
>>>
>>> The obvious way to tie it to a command mirrors how the QMP protocol ties
>>> responses to commands: by command ID.  The event either has to be sent
>>> just to the offending monitor (currently, all events are broadcast to
>>> all monitors), or include a suitable monitor ID.
>>>
>>> For non-command triggers, we'd have to invent some other tie.
>>>
>>> 3. Interface complexity
>>>
>>> Tying the event to some arbitrary trigger adds complexity.
>>>
>>> Do we need non-command triggers, and badly enough to justify the
>>> additional complexity?
>>>
>>> 4. Implementation complexity
>>>
>>> Emitting an event could be as simple as
>>>
>>>  qapi_event_send_deprecated(qmp_command_id(),
>>>     "Omitting 'filter-node-name'");
>>>
>>> where qmp_command_id() returns the ID of the currently executing
>>> command.  Making qmp_command_id() work is up to the QMP core.  Simple
>>> enough as long as each QMP command runs to completion before its monitor
>>> starts the next one.
>>>
>>> The event is "fire and forget".  There is no warning object propagated
>>> up the call chain into the QMP core like errors objects are.
>>>
>>> "Fire and forget" is ideal for letting arbitrary code decide "this is
>>> deprecated".
>>>
>>> Note the QAPI schema remains untouched.
>>>
>>> Unlike an event, which can be emitted anywhere, the success response
>>> gets built in the QMP core.  To have the core add deprecation info to
>>> it, we need to get the info to the core.
>>>
>>> If deprecation info originates in command code, like errors do, we need
>>> to propagate it up the call chain into the QMP core like errors.
>>>
>>> Propagating errors is painful.  It has caused massive churn all over the
>>> place.
>>>
>>> I don't think we can hitch deprecation info to the existing error
>>> propagation, since we need to take the success path back to the QMP
>>> core, not an error path.
>>>
>>> Propagating a second object for warnings... thanks, but no thanks.
>>>
>>
>> Probably the best argument against it. Fire-and-forget avoids the
>> problem. Events might work just fine, but the "tie" bit seems like a yak
>> in need of a shave.
>>
>>> The QMP core could provide a function for recording deprecation info for
>>> the currently executing QMP command.  

[libvirt] [PATCH v2 2/2] qapi: deprecate implicit filters

[Vladimir Sementsov-Ogievskiy]

To get rid of implicit filters related workarounds in future let's
deprecate them now.

Deprecation warning breaks some bash iotests output, so fix it here
too: in most of cases just add filter-node-name in test.

In 161 add FIXME and deprecation warning into 161.out.

In 249, the test case is changed, as we don't need to test "default"
filter node name anymore.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 qemu-deprecated.texi   |  6 ++
 qapi/block-core.json   |  9 ++---
 include/block/block_int.h  | 10 +-
 blockdev.c | 10 ++
 tests/qemu-iotests/094 |  1 +
 tests/qemu-iotests/095 |  6 --
 tests/qemu-iotests/109 |  1 +
 tests/qemu-iotests/127 |  1 +
 tests/qemu-iotests/141 |  5 -
 tests/qemu-iotests/144 |  3 ++-
 tests/qemu-iotests/156 |  1 +
 tests/qemu-iotests/161 |  7 +++
 tests/qemu-iotests/161.out |  1 +
 tests/qemu-iotests/185 |  3 +++
 tests/qemu-iotests/191 |  2 ++
 tests/qemu-iotests/229 |  1 +
 tests/qemu-iotests/247 |  8 +---
 tests/qemu-iotests/249 |  5 +++--
 tests/qemu-iotests/249.out |  2 +-
 19 files changed, 68 insertions(+), 14 deletions(-)

diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 296bfc93a3..c969faf55a 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -204,6 +204,12 @@ and accurate ``query-qmp-schema'' command.
 Character devices creating sockets in client mode should not specify
 the 'wait' field, which is only applicable to sockets in server mode
 
+@subsection implicit filters in mirror and commit (since 4.2)
+
+Mirror and commit jobs insert filters, which becomes implicit if user
+omitted @option(filter-node-name) parameter. So omitting it is deprecated
+in ``blockdev-mirror'', ``drive-mirror'' and ``block-commit'', set it always.
+
 @section Human Monitor Protocol (HMP) commands
 
 @subsection The hub_id parameter of 'hostfwd_add' / 'hostfwd_remove' (since 
3.1)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 93530d3a13..37caed775f 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1659,7 +1659,8 @@
 # @filter-node-name: the node name that should be assigned to the
 #filter driver that the commit job inserts into the graph
 #above @top. If this option is not given, a node name is
-#autogenerated. (Since: 2.9)
+#autogenerated. Omitting this option is deprecated, it will
+#be required in future. (Since: 2.9)
 #
 # @auto-finalize: When false, this job will wait in a PENDING state after it 
has
 # finished its work, waiting for @block-job-finalize before
@@ -1996,7 +1997,8 @@
 # @filter-node-name: the node name that should be assigned to the
 #filter driver that the mirror job inserts into the graph
 #above @device. If this option is not given, a node name is
-#autogenerated. (Since: 4.2)
+#autogenerated. Omitting this option is deprecated, it will
+#be required in future. (Since: 4.2)
 #
 # @unmap: Whether to try to unmap target sectors where source has
 # only zero. If true, and target unallocated sectors will read as zero,
@@ -2311,7 +2313,8 @@
 # @filter-node-name: the node name that should be assigned to the
 #filter driver that the mirror job inserts into the graph
 #above @device. If this option is not given, a node name is
-#autogenerated. (Since: 2.9)
+#autogenerated. Omitting this option is deprecated, it will
+#be required in future. (Since: 2.9)
 #
 # @copy-mode: when to copy data to the destination; defaults to 'background'
 # (Since: 3.0)
diff --git a/include/block/block_int.h b/include/block/block_int.h
index dd033d0b37..48ff3af48d 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -793,7 +793,15 @@ struct BlockDriverState {
 bool sg;/* if true, the device is a /dev/sg* */
 bool probed;/* if true, format was probed rather than specified */
 bool force_share; /* if true, always allow all shared permissions */
-bool implicit;  /* if true, this filter node was automatically inserted */
+
+/*
+ * @implicit field is deprecated, don't set it to true for new filters.
+ * If true, this filter node was automatically inserted and user don't
+ * know about it and unprepared for any effects of it. So, implicit
+ * filters are workarounded and skipped in many places of the block
+ * layer code.
+ */
+bool implicit;
 
 BlockDriver *drv; /* NULL means no media */
 void *opaque;
diff --git a/blockdev.c b/blockdev.c
index 2ca614c77f..8c3a409c94 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -,6 +,11 @@ void qmp_block_commit(bool has_job_id, const char 
*job_id, const char *device,

[libvirt] [PATCH v2 0/2] Deprecate implicit filters

[Vladimir Sementsov-Ogievskiy]

v2:
Don't deprecate drive-backup, it is unrelated thing and will be resent
in separate.
Don't deprecate drive-mirror. Instead add filter-node-name to
drive-mirror to behave like blockdev-mirror
Fix all broken iotests.

Vladimir Sementsov-Ogievskiy (2):
  qapi: add filter-node-name option to drive-mirror
  qapi: deprecate implicit filters

 qemu-deprecated.texi   |  6 ++
 qapi/block-core.json   | 14 --
 include/block/block_int.h  | 10 +-
 blockdev.c | 12 +++-
 tests/qemu-iotests/094 |  1 +
 tests/qemu-iotests/095 |  6 --
 tests/qemu-iotests/109 |  1 +
 tests/qemu-iotests/127 |  1 +
 tests/qemu-iotests/141 |  5 -
 tests/qemu-iotests/144 |  3 ++-
 tests/qemu-iotests/156 |  1 +
 tests/qemu-iotests/161 |  7 +++
 tests/qemu-iotests/161.out |  1 +
 tests/qemu-iotests/185 |  3 +++
 tests/qemu-iotests/191 |  2 ++
 tests/qemu-iotests/229 |  1 +
 tests/qemu-iotests/247 |  8 +---
 tests/qemu-iotests/249 |  5 +++--
 tests/qemu-iotests/249.out |  2 +-
 19 files changed, 75 insertions(+), 14 deletions(-)

-- 
2.21.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Deprecating stuff for 4.2

[Vladimir Sementsov-Ogievskiy]

08.11.2019 9:41, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy  writes:
> 
>> 07.11.2019 21:52, Philippe Mathieu-Daudé wrote:
> [...]
>>> Pre-release period, time to deprecate some stuffs :)
>>>
>>> How should we proceed? Do you have something in mind?
>>>
>>> There are older threads about this. Should we start a new thread? Gather 
>>> the different ideas on the Wiki?
>>>
>>> (Obviously you are not the one responsible of this topic, you just happen 
>>> to be the last one worried about it on the list).
>>>
>>> Regards,
>>>
>>> Phil.
> 
> 4.2.0-rc0 has been tagged, i.e. we're in hard freeze already.  Only bug
> fixes are accepted during hard freeze.  We've occasionally bent this
> rule after -rc0 for borderline cases, e.g. to tweak a new external
> interface before the release calcifies it.  Making a case for bending
> the rules becomes harder with each -rc.
> 
> Ideally, we'd double-check new interfaces for gaffes before a release,
> and whether old interfaces that have been replaced now should be
> deprecated.  There's rarely time for that, and pretty much never for
> releases right after KVM Forum.
> 
> So no, I don't have anything in mind for 4.2.
> 
> We intend to tag -rc1 next Tuesday.  To make that deadline, we'd need
> patches, not just ideas.
> 
>> Hi!
>>
>> I wanted to resend, but faced some problems, and understand that I can't do 
>> it in time before soft-freeze..
>> But you say, that we can deprecate something even after hard-freeze?
> 
> See above.
> 
>> Ok, the problem that I faced, is that deprecation warnings breaks some 
>> iotests.. What can we do?
>>
>> 1. Update iotests...
>> 1.1 Just update iotests outputs to show warnings. Then, in next release 
>> cycle, update iotests, to not use deprecated things
> 
> Sounds workable to me, but I'm not the maintainer.
> 
>> or
>> 1.2 Update iotests to not use deprecated things.. Not appropriate for 
>> hard freeze.
> 
> Unnecessarily risky compared to 1.1.
> 
>> or
>> 2. Commit deprecations without warnings.. But how do people find out about 
>> this?
> 
> Not nice.
> 
> We do it for QMP, but only because we still lack the means to warn
> there.
> 
>> Next, what exactly to deprecate? As I understand, we can't deprecate 
>> drive-mirror now?
>> So I propose to:
>>
>> 1. deprecate drive-backup
>> 2. add optional filter-node-name parameter to drive-mirror, to correspond to 
>> commit and mirror
>> 3. deprecate that filter-node-name is optional for commit and mirror.
> 
> To have a chance there, we need patches a.s.a.p.
> 

OK, I'll send today and we'll see, what to do with it.

-- 
Best regards,
Vladimir

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2] Add API to change qemu agent response timeout

[Michal Privoznik]

On 11/6/19 10:13 PM, Jonathon Jongsma wrote:

Some layered products such as oVirt have requested a way to avoid being
blocked by guest agent commands when querying a loaded vm. For example,
many guest agent commands are polled periodically to monitor changes,
and rather than blocking the calling process, they'd prefer to simply
time out when an agent query is taking too long.

This patch adds a way for the user to specify a custom agent timeout
that is applied to all agent commands.

One special case to note here is the 'guest-sync' command. 'guest-sync'
is issued internally prior to calling any other command. (For example,
when libvirt wants to call 'guest-get-fsinfo', we first call
'guest-sync' and then call 'guest-get-fsinfo').

Previously, the 'guest-sync' command used a 5-second timeout
(VIR_DOMAIN_QEMU_AGENT_COMMAND_DEFAULT), whereas the actual command that
followed always blocked indefinitely
(VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK). As part of this patch, if a
custom timeout is specified that is shorter than
5 seconds,  this new timeout is also used for 'guest-sync'. If there is
no custom timeout or if the custom timeout is longer than 5 seconds, we
will continue to use the 5-second timeout.

See https://bugzilla.redhat.com/show_bug.cgi?id=1705426 for additional details.

Signed-off-by: Jonathon Jongsma 
---
I've addressed most of the previous review comments from Peter, Daniel, and
Michal but I'm unsure yet whether there's concensus on this feature. Here's a
v2 for your consideration.

I admit that the proposed API is not perfect. It would probably be more elegant
if each agent command instead had its own 'timeout' argument so that the caller
could specify the timeout for each invocation. But that is not the case, and
introducing duplicate API for each agent command (with an additional timeout
argument) would clutter the public API. In addition, we still have the issue
Michal mentioned elsewhere in the thread where some commands like shutdown may
or may not use the agent, so a timeout argument could be confusing.

So: is this a viable approach, or should I rethink it?


It's on the right path, but there are some issues. See below. It's not 
this simple.




Changes in v2:
- Make this an official public API rather than putting it in libvirt-qemu.
- Don't use the qemuDomainObjEnterAgent()/ExitAgent() API, which expects you
   to acquire an agent job. Instead, introduce
   qemuDomainObjSetAgentResponseTimeout() which simply locks the agent while
   setting the variable.
- rename the function slightly for better descriptiveness:
   virDomainQemuAgentSetTimeout() -> virDomainAgentSetResponseTimeout()
- added 'flags' argument for future-proofing.

  include/libvirt/libvirt-domain.h |  9 
  include/libvirt/libvirt-qemu.h   |  8 +--
  src/driver-hypervisor.h  |  6 +++
  src/libvirt-domain.c | 45 +
  src/libvirt_public.syms  |  1 +
  src/qemu/qemu_agent.c| 84 
  src/qemu/qemu_agent.h|  4 ++
  src/qemu/qemu_domain.c   | 15 ++
  src/qemu/qemu_domain.h   |  5 ++
  src/qemu/qemu_driver.c   | 22 +
  src/remote/remote_driver.c   |  1 +
  src/remote/remote_protocol.x | 18 ++-
  src/remote_protocol-structs  |  9 
  13 files changed, 190 insertions(+), 37 deletions(-)

diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index 22277b0a84..83f6c1b835 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -4916,4 +4916,13 @@ int virDomainGetGuestInfo(virDomainPtr domain,
int *nparams,
unsigned int flags);
  
+typedef enum {

+VIR_DOMAIN_AGENT_COMMAND_BLOCK = -2,
+VIR_DOMAIN_AGENT_COMMAND_DEFAULT = -1,
+VIR_DOMAIN_AGENT_COMMAND_NOWAIT = 0,
+} virDomainAgentCommandTimeoutValues;
+int virDomainAgentSetResponseTimeout(virDomainPtr domain,
+ int timeout,
+ unsigned int flags);
+
  #endif /* LIBVIRT_DOMAIN_H */
diff --git a/include/libvirt/libvirt-qemu.h b/include/libvirt/libvirt-qemu.h
index 891617443f..4a541167ad 100644
--- a/include/libvirt/libvirt-qemu.h
+++ b/include/libvirt/libvirt-qemu.h
@@ -43,10 +43,10 @@ virDomainPtr virDomainQemuAttach(virConnectPtr domain,
   unsigned int flags);
  
  typedef enum {

-VIR_DOMAIN_QEMU_AGENT_COMMAND_MIN = -2,
-VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK = -2,
-VIR_DOMAIN_QEMU_AGENT_COMMAND_DEFAULT = -1,
-VIR_DOMAIN_QEMU_AGENT_COMMAND_NOWAIT = 0,
+VIR_DOMAIN_QEMU_AGENT_COMMAND_MIN = VIR_DOMAIN_AGENT_COMMAND_BLOCK,
+VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK = VIR_DOMAIN_AGENT_COMMAND_BLOCK,
+VIR_DOMAIN_QEMU_AGENT_COMMAND_DEFAULT = VIR_DOMAIN_AGENT_COMMAND_DEFAULT,
+VIR_DOMAIN_QEMU_AGENT_COMMAND_NOWAIT = VIR_DOMAIN_AGENT_COMMAND_NOWAIT,
  VIR_DOMAIN_QEMU_AGENT_COMMAND_SHUTDOWN 

Re: [libvirt] [PATCH 2/2] qemu: Check for job being set when getting iothread stats

[Michal Privoznik]

On 11/7/19 6:29 PM, Jonathon Jongsma wrote:

On Thu, 2019-11-07 at 14:19 +0100, Michal Privoznik wrote:

The qemuDomainGetStatsIOThread() accesses the monitor by calling
qemuDomainGetIOThreadsMon(). And it's also marked as "need
monitor" in qemuDomainGetStatsWorkers[]. However, it's not
checking if acquiring job was successful.

Signed-off-by: Michal Privoznik 
---
  src/qemu/qemu_driver.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index d17c18705b..146b4ee319 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -21194,7 +21194,7 @@ static int
  qemuDomainGetStatsIOThread(virQEMUDriverPtr driver,
 virDomainObjPtr dom,
 virTypedParamListPtr params,
-   unsigned int privflags G_GNUC_UNUSED)
+   unsigned int privflags)
  {
  qemuDomainObjPrivatePtr priv = dom->privateData;
  size_t i;
@@ -21202,7 +21202,7 @@ qemuDomainGetStatsIOThread(virQEMUDriverPtr
driver,
  int niothreads;
  int ret = -1;
  
-if (!virDomainObjIsActive(dom))

+if (!HAVE_JOB(privflags) || !virDomainObjIsActive(dom))
  return 0;


It seems to me that not having acquired a job would be an error
condition. Here you return 0 indicating that the query was successful.

Also, although this change doesn't really harm anything, it doesn't
quite seem like the proper fix to me. You're essentially calling a
function that requires a job, and passing it a flag indicating whether
we've acquired a job or not. That's a bit of an odd pattern; a flag
parameter indicating whether the function should actually execute or
not:

   void do_something(bool yes_i_really_mean_it)

:) It seems like the proper fix would be to simply not call the
function if we haven't acquired a job.

Of course, you could still keep the above patch if you want to be
cautious, but perhaps the real fix should be to filter out monitor-
requiring jobs in qemuDomainGetStats() when we failed to acquire a
job? Something like:

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 42922d2f04..a935ef6d97 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -21456,7 +21456,10 @@ qemuDomainGetStats(virConnectPtr conn,
  return -1;
  
  for (i = 0; qemuDomainGetStatsWorkers[i].func; i++) {

-if (stats & qemuDomainGetStatsWorkers[i].stats) {
+if (stats & qemuDomainGetStatsWorkers[i].stats &&
+(!qemuDomainGetStatsWorkers[i].monitor ||
HAVE_JOB(flags))) {
  if (qemuDomainGetStatsWorkers[i].func(conn->privateData,
dom, params,
flags) < 0)
  return -1;


These stats querying callbacks work in a different way than the rest of 
the code. The entry point is qemuConnectGetAllDomainStats(). It iterates 
over the list of domains and tries to acquire job for each domain that 
it's currently iterating over. This may of course fail (or, if NOWAIT 
flag is specified then user specifically requested to skip domains 
"blocked" with a job). Anyway, there are some stats that require job, 
some that don't, and some that are somewhere in the middle (e.g. 
qemuDomainGetStatsVcpu), i.e. they can get some basic info and if job is 
acquired they can gather even more info. Therefore, we can't check for 
HAVE_JOB() in qemuDomainGetStats() but rather in each callback individually.


As for returning success, the virConnectGetAllDomainStats() API is 
document as:


Note that entire stats groups or individual stat fields may be missing 
from the output in case they are not supported by the given hypervisor, 
are not applicable for the current state of the guest domain, or their 
retrieval was not successful.


The way I read this is: if unable to acquire job, omit iothread stats 
without reporting error. In fact, this is what other callbacks do too.


Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [jenkins-ci PATCH 0/5] Add Fedora 31, drop Fedora 29

[Fabiano Fidêncio]

On Fri, Nov 8, 2019 at 9:24 AM Erik Skultety  wrote:
>
> On Thu, Nov 07, 2019 at 07:51:56PM +0100, Andrea Bolognani wrote:
> > You know the drill :)
> >
> > Andrea Bolognani (5):
> >   guests: Explicitly enable ssh root login in kickstart
> >   guests: Add Fedora 31
> >   Start building on Fedora 31
> >   Stop building on Fedora 29
> >   guests: Drop Fedora 29
>
> Reviewed-by: Erik Skultety 

Also, Reviewed-by: Fabiano Fidêncio 

Would you mind also sending patches to the dockerfiles?

Best Regards,

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 05/20] syntax-check.mk: cleanup generated_files list for sc_po_check

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:23PM +0200, Pavel Hrdina wrote:
> Move generated_files variable closer to the sc_po_check rule and
> remove non-existent gnulib internal path.
> 
> Signed-off-by: Pavel Hrdina 
> ---
> 
> Notes:
> New in v2.
> 
>  build-aux/syntax-check.mk | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 10/20] src: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:28PM +0200, Pavel Hrdina wrote:
> This affects more than src/Makefile.am as the rule to generate source
> files for protocols is generic for all sub-directories.
> 
> Affected files are:
> src/admin/admin_protocol.{h,c}
> src/locking/lock_protocol.{h,c}
> src/logging/log_protocol.{h,c}
> src/lxc/lxc_monitor_protocol.{h,c}
> src/remote/{lxc,qemu,remote}_protocol.{h,c}
> src/rpc/{virkeepalive,virnet}protocol.{h,c}
> 
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> - modify generated_files for sc_po_check as well
> 
>  .gitignore  | 8 
>  build-aux/syntax-check.mk   | 1 -
>  src/Makefile.am | 4 ++--
>  src/admin/Makefile.inc.am   | 3 +++
>  src/locking/Makefile.inc.am | 6 ++
>  src/logging/Makefile.inc.am | 4 
>  src/lxc/Makefile.inc.am | 4 
>  src/remote/Makefile.inc.am  | 4 
>  src/rpc/Makefile.inc.am | 3 +++
>  tests/Makefile.am   | 1 +
>  10 files changed, 27 insertions(+), 11 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 11/20] src: access: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:29PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> 
>  .gitignore  |  7 ---
>  po/POTFILES.in  |  3 +++
>  src/access/Makefile.inc.am  | 14 +++---
>  src/admin/Makefile.inc.am   |  1 +
>  src/interface/Makefile.inc.am   |  1 +
>  src/libxl/Makefile.inc.am   |  1 +
>  src/lxc/Makefile.inc.am |  1 +
>  src/network/Makefile.inc.am |  1 +
>  src/node_device/Makefile.inc.am |  1 +
>  src/nwfilter/Makefile.inc.am|  1 +
>  src/qemu/Makefile.inc.am|  1 +
>  src/remote/Makefile.inc.am  |  1 +
>  src/secret/Makefile.inc.am  |  1 +
>  src/storage/Makefile.inc.am |  1 +
>  14 files changed, 21 insertions(+), 14 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 12/20] src: admin: generate source files into build directory

[Daniel P . Berrangé]

On Thu, Oct 24, 2019 at 03:05:30PM +0200, Pavel Hrdina wrote:
> Signed-off-by: Pavel Hrdina 
> Reviewed-by: Ján Tomko 
> ---
> 
> Notes:
> Changes in v2:
> - remove entries from .gitignore
> - modify generated_files for sc_po_check as well
> 
>  .gitignore| 2 --
>  build-aux/syntax-check.mk | 1 -
>  po/POTFILES.in| 3 ++-
>  src/admin/Makefile.inc.am | 7 ---
>  4 files changed, 6 insertions(+), 7 deletions(-)

Reviewed-by: Daniel P. Berrangé 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/3] conf: Set rebootTimeout valid range to 0..0xffff

[Han Han]

On Tue, Oct 15, 2019 at 4:04 PM Michal Privoznik 
wrote:

> On 10/15/19 7:23 AM, Han Han wrote:
> > Hi Michal,
> > Any more advice update?
>
> Well, as I've said earlier, since we document that -1 is accepted value
> and it means that it suppresses automatic reboots we need a way to
> preserve this behaviour. For instance, what happens if you don't put
> reboot-timeout onto the cmd line at all? Does qemu use some default and
>
If no  reboot-timeout, qemu will not reboot by default. I have updated the
qemu doc:
https://github.com/qemu/qemu/commit/bbd9e6985ff342cbe15b9cb7eb30e842796fbbe8

> reboot anyways? If it doesn't reboot then -1 should mean to not put
>
I think they use the same defaults and will not reboot by default. That can
be checked by
the code before and after qemu commit ee5d0f8. The values passed to
fw_cfg_add_file are
same by default.

Markus Armbruster,
Could you please confirm that, for cases of
- reboot-timeout=-1 before ee5d0f8
- reboot-timeout by default before ee5d0f8
- reboot-timeout by default after  ee5d0f8
they all will not reboot?

reboot-timeout onto the cmd line. However, if it does reboot then we
> need to talk to qemu developers to provide us a way to suppress
> automatic reboots.
>
> Michal
>


-- 
Best regards,
---
Han Han
Quality Engineer
Redhat.

Email: h...@redhat.com
Phone: +861065339333
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2] Add API to change qemu agent response timeout

[Daniel P . Berrangé]

On Wed, Nov 06, 2019 at 03:13:21PM -0600, Jonathon Jongsma wrote:
> Some layered products such as oVirt have requested a way to avoid being
> blocked by guest agent commands when querying a loaded vm. For example,
> many guest agent commands are polled periodically to monitor changes,
> and rather than blocking the calling process, they'd prefer to simply
> time out when an agent query is taking too long.
> 
> This patch adds a way for the user to specify a custom agent timeout
> that is applied to all agent commands.
> 
> One special case to note here is the 'guest-sync' command. 'guest-sync'
> is issued internally prior to calling any other command. (For example,
> when libvirt wants to call 'guest-get-fsinfo', we first call
> 'guest-sync' and then call 'guest-get-fsinfo').
> 
> Previously, the 'guest-sync' command used a 5-second timeout
> (VIR_DOMAIN_QEMU_AGENT_COMMAND_DEFAULT), whereas the actual command that
> followed always blocked indefinitely
> (VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK). As part of this patch, if a
> custom timeout is specified that is shorter than
> 5 seconds,  this new timeout is also used for 'guest-sync'. If there is
> no custom timeout or if the custom timeout is longer than 5 seconds, we
> will continue to use the 5-second timeout.
> 
> See https://bugzilla.redhat.com/show_bug.cgi?id=1705426 for additional 
> details.
> 
> Signed-off-by: Jonathon Jongsma 
> ---
> I've addressed most of the previous review comments from Peter, Daniel, and
> Michal but I'm unsure yet whether there's concensus on this feature. Here's a
> v2 for your consideration.
> 
> I admit that the proposed API is not perfect. It would probably be more 
> elegant
> if each agent command instead had its own 'timeout' argument so that the 
> caller
> could specify the timeout for each invocation. But that is not the case, and
> introducing duplicate API for each agent command (with an additional timeout
> argument) would clutter the public API. In addition, we still have the issue
> Michal mentioned elsewhere in the thread where some commands like shutdown may
> or may not use the agent, so a timeout argument could be confusing.
> 
> So: is this a viable approach, or should I rethink it?
> 
> Changes in v2:
> - Make this an official public API rather than putting it in libvirt-qemu.
> - Don't use the qemuDomainObjEnterAgent()/ExitAgent() API, which expects you
>   to acquire an agent job. Instead, introduce
>   qemuDomainObjSetAgentResponseTimeout() which simply locks the agent while
>   setting the variable.
> - rename the function slightly for better descriptiveness: 
>   virDomainQemuAgentSetTimeout() -> virDomainAgentSetResponseTimeout()
> - added 'flags' argument for future-proofing.
> 
>  include/libvirt/libvirt-domain.h |  9 
>  include/libvirt/libvirt-qemu.h   |  8 +--
>  src/driver-hypervisor.h  |  6 +++
>  src/libvirt-domain.c | 45 +
>  src/libvirt_public.syms  |  1 +
>  src/qemu/qemu_agent.c| 84 
>  src/qemu/qemu_agent.h|  4 ++
>  src/qemu/qemu_domain.c   | 15 ++
>  src/qemu/qemu_domain.h   |  5 ++
>  src/qemu/qemu_driver.c   | 22 +
>  src/remote/remote_driver.c   |  1 +
>  src/remote/remote_protocol.x | 18 ++-
>  src/remote_protocol-structs  |  9 
>  13 files changed, 190 insertions(+), 37 deletions(-)
> 
> diff --git a/include/libvirt/libvirt-domain.h 
> b/include/libvirt/libvirt-domain.h
> index 22277b0a84..83f6c1b835 100644
> --- a/include/libvirt/libvirt-domain.h
> +++ b/include/libvirt/libvirt-domain.h
> @@ -4916,4 +4916,13 @@ int virDomainGetGuestInfo(virDomainPtr domain,
>int *nparams,
>unsigned int flags);
>  
> +typedef enum {
> +VIR_DOMAIN_AGENT_COMMAND_BLOCK = -2,
> +VIR_DOMAIN_AGENT_COMMAND_DEFAULT = -1,
> +VIR_DOMAIN_AGENT_COMMAND_NOWAIT = 0,
> +} virDomainAgentCommandTimeoutValues;

These constants should all have the word "TIMEOUT_" in their name
eg VIR_DOMAIN_AGENT_COMMAND_TIMEOUT_NOWAIT

> +int virDomainAgentSetResponseTimeout(virDomainPtr domain,
> + int timeout,
> + unsigned int flags);


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v6] util: Set SIGPIPE to a no-op handler in virFork

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 08:25:15AM +0800, Wang Yechao wrote:
> Libvirtd has set SIGPIPE to ignored, and virFork resets all signal
> handlers to the defaults. But child process may write logs to
> stderr/stdout, that may generate SIGPIPE if journald has stopped.
> 
> So set SIGPIPE to a dummy no-op handler before unmask signals in
> virFork(), and the handler will get reset to SIG_DFL when execve()
> runs. Now we can delete sigaction() call entirely in virExec().
> 
> Signed-off-by: Wang Yechao 
> 
> ---
> v3 patch:
> https://www.redhat.com/archives/libvir-list/2019-October/msg00934.html
> 
> Changes in v4:
>  -  don't block SIGPIPE, ignore it when invoke VIR_FORCE_CLOSE and 
> virCommandMassClose
> 
> Changes in v5:
>  - chang from SIG_IGN to a no-op handler in child process
> 
> Changes in v6:
>  - add a comment and delete sigaction() call entirely in virExec
> ---
>  src/util/vircommand.c | 32 ++--
>  1 file changed, 10 insertions(+), 22 deletions(-)
> 
> diff --git a/src/util/vircommand.c b/src/util/vircommand.c
> index 93b3dd2..8b10253 100644
> --- a/src/util/vircommand.c
> +++ b/src/util/vircommand.c
> @@ -217,6 +217,8 @@ virCommandFDSet(virCommandPtr cmd,
>  
>  #ifndef WIN32
>  
> +static void virDummyHandler(int sig G_GNUC_UNUSED) {}

'make syntax-check' didn't like {} on the same line like this.

I've fixed that trivial style issue and pushed to git.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3 00/52] qemu: Store default CPU in domain XML

[Christian Borntraeger]

As discussed, does it make sense to add the default change to host-model for 
s390 
in this series or should that be a separate patch?


On 05.11.19 14:26, Jiri Denemark wrote:
> When starting a domain without a CPU model specified in the domain XML,
> QEMU will choose a default one. Which is fine unless the domain gets
> migrated to another host because libvirt doesn't perform any CPU ABI
> checks and the virtual CPU provided by QEMU on the destination host can
> differ from the one on the source host.
> 
> With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for
> a particular machine type and store it in the domain XML. This way the
> chosen CPU model is more visible to users and libvirt will make sure
> the guest will see the exact same CPU after migration.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1598151
> https://bugzilla.redhat.com/show_bug.cgi?id=1598162
> 
> Version 2:
> - more tests
> - TCG-only support for non x86_64 architectures
> 
> Version 3:
> - as a result of talking with QEMU developers dealing with s390 and
>   ppc64 I have to enhance the series so that libvirt is able to fetch
>   different default CPU models on TCG vs. KVM
> 
> ---
> 
> Some patches were too large so I decided to shorten them before sending
> to the list. You can check the full version of this series with
> 
> git fetch https://gitlab.com/jirkade/libvirt cpu-default-type
> 
> Jiri Denemark (52):
>   tests: Add capabilities for QEMU 4.2.0 on s390x
>   tests: Update 4.2.0 capabilities data on ppc64
>   conf: Use VIR_AUTO* in virDomainCapsCPUModelsAdd
>   conf: Drop nameLen parameter from virDomainCapsCPUModelsAdd
>   qemu: Copy CPU models in virQEMUCapsGetCPUDefinitions
>   qemu: Filter models in virQEMUCapsGetCPUDefinitions
>   qemu: Use virQEMUCapsGetCPUDefinitions more
>   qemu: Use g_autoptr in qemuMonitorJSONGetCPUDefinitions
>   qemu: Change return type of virQEMUCapsFetchCPUDefinitions
>   qemu: Introduce qemuMonitorCPUDefs struct
>   qemu: Flatten qemuMonitorCPUDefs.cpus
>   qemu: Add qemuMonitorCPUDefsCopy
>   qemu: Use g_autofree in virQEMUCapsLoadCPUModels
>   qemu: Use virDomainCapsCPUUsable in qemuMonitorCPUDefInfo
>   qemu: Introduce virQEMUCapsCPUDefsToModels
>   qemu: Rename virQEMUCaps{Get,Fetch}CPUDefinitions
>   qemu: Split virQEMUCapsFetchCPUModels
>   qemu: Switch qemuCaps to use qemuMonitorCPUDefs
>   conf: Drop unused virDomainCapsCPUModelsFilter
>   conf: Drop virDomainCapsCPUModelsAddSteal
>   qemu: Store typename from query-cpu-definitions in qemuCaps
>   qemu: Drop unused virQEMUCapsGetDefaultMachine
>   qemu: Add virQEMUCaps{Load,Format}Accel
>   qemu: Introduce virQEMUCapsAccel structure
>   qemu: Introduce virQEMUCapsAccelCopy
>   qemu: Introduce virQEMUCapsAccelClear
>   qemu: Introduce and use virQEMUCapsGetAccel
>   qemu: Drop virQEMUCapsGetHostCPUData
>   qemu: Refactor virQEMUCapsLoadAccel
>   qemu: Refactor virQEMUCapsFormatAccel
>   qemu: Introduce virQEMUCapsProbeCPUDefinitionsTest
>   qemu: Refactor probing of accelerator dependent data
>   qemu: Make virQEMUCapsGetMachineTypesCaps static
>   qemu: Make virQEMUCapsIsMachineSupported static
>   qemu: Refactor virQEMUCapsLoadCache a bit
>   qemu: Refactor virQEMUCapsFormatCache a bit
>   qemu: Pass virDomainVirtType to APIs dealing with machine types
>   qemu: Move machine type data in capabilities cache
>   qemu: Use typedef for virQEMUCapsMachineType
>   qemu: Introduce virQEMUCapsCopyMachineTypes
>   qemu: Make probed machine types depend on accelerator
>   qemu: Probe machine types for both KVM and TCG
>   qemu: Probe for default CPU types
>   qemu: Introduce virQEMUCapsGetMachineDefaultCPU
>   qemu: Use g_autoptr in qemuDomainDefPostParse
>   conf: Define g_autoptr cleanup function for virCPUDef
>   qemuxml2argvtest: Update host arch for DO_TEST*ARCH* tests
>   qemuxml2*test: Add test cases for default CPU models on aarch64
>   qemuxml2*test: Add test cases for default CPU models on ppc64
>   qemuxml2*test: Add test cases for default CPU models on s390x
>   qemuxml2*test: Add test cases for default CPU models on x86_64
>   qemu: Store default CPU in domain XML
> 
>  src/conf/cpu_conf.h   | 1 +
>  src/conf/domain_capabilities.c|86 +-
>  src/conf/domain_capabilities.h|10 +-
>  src/libvirt_private.syms  | 2 -
>  src/qemu/qemu_capabilities.c  |  1064 +-
>  src/qemu/qemu_capabilities.h  |29 +-
>  src/qemu/qemu_capspriv.h  | 5 +-
>  src/qemu/qemu_domain.c|97 +-
>  src/qemu/qemu_driver.c| 4 +-
>  src/qemu/qemu_monitor.c   |61 +-
>  src/qemu/qemu_monitor.h   |19 +-
>  src/qemu/qemu_monitor_json.c  |82 +-
>  src/qemu/qemu_monitor_json.h  | 2 +-
>  src/qemu/qemu_process.c   |24 +-
>  

Re: [libvirt] [PATCH v3 06/20] po: generate files into build directory

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 12:15:53PM +0100, Andrea Bolognani wrote:
> On Fri, 2019-11-08 at 10:04 +, Daniel P. Berrangé wrote:
> > On Thu, Oct 24, 2019 at 03:05:24PM +0200, Pavel Hrdina wrote:
> > > -endif HAVE_GNU_GETTEXT_TOOLS
> > > -
> > >  if ENABLE_NLS
> > >  
> > >  # Cannot use 'localedir' since this conflicts with autoconf.
> > > @@ -99,7 +104,7 @@ install-data-hook: $(GMOFILES)
> > >   for lang in $(LANGS); do \
> > > d=$(DESTDIR)$(langinstdir)/$$lang/LC_MESSAGES; \
> > > mkdir -p $$d; \
> > > -   install -m 0644 $(srcdir)/$$lang.gmo $$d/$(DOMAIN).mo; \
> > > +   install -m 0644 $$lang.gmo $$d/$(DOMAIN).mo; \
> > >   done
> > >  
> > >  uninstall-hook:
> > > @@ -109,3 +114,5 @@ uninstall-hook:
> > >   done
> > >  
> > >  endif ENABLE_NLS
> > > +
> > > +endif HAVE_GNU_GETTEXT_TOOLS
> > 
> > Moving this HAVE_GNU_GETTEXT_TOOLS conditional means that on OS that
> > lack the GNU gettext impl, we are no longer able to 'make install'
> > the translation files, despite having them prebuilt & bundled in the
> > tarball.
> > 
> > IIRC, this affects any non-Linux host.
> 
> We install GNU gettext both on FreeBSD and on macOS, so it shouldn't
> really be a problem I think? To me it doesn't seem much different
> from mandating the use of GNU make, which we already do.

Where we do that on macOS ?   When I first did this new po/Makefile.am
impl we didn't have GNU gettext on macOS at least, and I don't see us
installing anything special in the travis config.

If we can assume GNU gettext though, we should enforce that upfront in
the configure script checks and get rid of the conditional entirely

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/2] qemu: Check for job being set when getting iothread stats

[Michal Privoznik]

On 11/8/19 4:05 PM, Jonathon Jongsma wrote:

On Fri, 2019-11-08 at 10:44 +0100, Michal Privoznik wrote:

On 11/7/19 6:29 PM, Jonathon Jongsma wrote:

On Thu, 2019-11-07 at 14:19 +0100, Michal Privoznik wrote:

The qemuDomainGetStatsIOThread() accesses the monitor by calling
qemuDomainGetIOThreadsMon(). And it's also marked as "need
monitor" in qemuDomainGetStatsWorkers[]. However, it's not
checking if acquiring job was successful.

Signed-off-by: Michal Privoznik 
---
   src/qemu/qemu_driver.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index d17c18705b..146b4ee319 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -21194,7 +21194,7 @@ static int
   qemuDomainGetStatsIOThread(virQEMUDriverPtr driver,
  virDomainObjPtr dom,
  virTypedParamListPtr params,
-   unsigned int privflags G_GNUC_UNUSED)
+   unsigned int privflags)
   {
   qemuDomainObjPrivatePtr priv = dom->privateData;
   size_t i;
@@ -21202,7 +21202,7 @@
qemuDomainGetStatsIOThread(virQEMUDriverPtr
driver,
   int niothreads;
   int ret = -1;
   
-if (!virDomainObjIsActive(dom))

+if (!HAVE_JOB(privflags) || !virDomainObjIsActive(dom))
   return 0;


It seems to me that not having acquired a job would be an error
condition. Here you return 0 indicating that the query was
successful.

Also, although this change doesn't really harm anything, it doesn't
quite seem like the proper fix to me. You're essentially calling a
function that requires a job, and passing it a flag indicating
whether
we've acquired a job or not. That's a bit of an odd pattern; a flag
parameter indicating whether the function should actually execute
or
not:

void do_something(bool yes_i_really_mean_it)

:) It seems like the proper fix would be to simply not call the
function if we haven't acquired a job.

Of course, you could still keep the above patch if you want to be
cautious, but perhaps the real fix should be to filter out monitor-
requiring jobs in qemuDomainGetStats() when we failed to acquire a
job? Something like:

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 42922d2f04..a935ef6d97 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -21456,7 +21456,10 @@ qemuDomainGetStats(virConnectPtr conn,
   return -1;
   
   for (i = 0; qemuDomainGetStatsWorkers[i].func; i++) {

-if (stats & qemuDomainGetStatsWorkers[i].stats) {
+if (stats & qemuDomainGetStatsWorkers[i].stats &&
+(!qemuDomainGetStatsWorkers[i].monitor ||
HAVE_JOB(flags))) {
   if (qemuDomainGetStatsWorkers[i].func(conn-

privateData,

dom, params,
 flags) < 0)
   return -1;


These stats querying callbacks work in a different way than the rest
of
the code. The entry point is qemuConnectGetAllDomainStats(). It
iterates
over the list of domains and tries to acquire job for each domain
that
it's currently iterating over. This may of course fail (or, if
NOWAIT
flag is specified then user specifically requested to skip domains
"blocked" with a job). Anyway, there are some stats that require
job,
some that don't, and some that are somewhere in the middle (e.g.
qemuDomainGetStatsVcpu), i.e. they can get some basic info and if job
is
acquired they can gather even more info. Therefore, we can't check
for
HAVE_JOB() in qemuDomainGetStats() but rather in each callback
individually.


Aha, I had missed the part where some functions can get a reduced set
of stats despite having .monitor=true. Sorry for that.

It still seems a bit of an odd pattern to me. In some ways, I think it
would be cleaner to change the qemuDomainGetStatsWorker.monitor
variable from a boolean to an enumeration that can be one of
MONITOR_NONE, MONITOR_OPTIONAL, MONITOR_REQUIRED, so we have enough
information to decide whether to call the function or not.


Well, if we had such variable, it wouldn't help really, would it? I 
mean, maybe for MONITOR_REQUIRED we could skip calling the function 
completely, but for the rest, we would still need to call the function 
and check the state inside anyways.




But this patch is consistent with the others, so

Reviewed-by: Jonathon Jongsma 


Thanks, I've pushed both.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 00/20] cleanup current build system

[Pavel Hrdina]

As preparation to switch to Meson there are some things that needs be
cleaned up to make the conversion easier.

The important thing in Meson is that there is a strict separation
between source and build directory and the distributed tarball by
default contains only files tracked by git with a possibility to
write a script which would add some other sources into the tarball.

Regardless of the adoption of Meson these patches improve our current
build system to fully support VPATH builds.

Changes in v2:
- some patches from v1 are pushed now
- added a patch to mandate build dir != src dir
- added a patch to cleanup .gitignore
- added patches to fix sc_po_check
- improved some patches from v1

Changes in v3:
- python-zanata-client is the tool our Makefile uses

Pavel Hrdina (20):
  build: mandate use of a build dir != src dir
  .gitignore: cleanup old and obsolete ignores
  syntax-check.mk: fix sc_po_check rule
  syntax-check.mk: cleanup sc_po_check dependencies
  syntax-check.mk: cleanup generated_files list for sc_po_check
  po: generate files into build directory
  po: rewrite the way how we generate files
  po: README.md: add a note about which Zanata client is required
  remote: unify rpc server dispatch generated files
  src: generate source files into build directory
  src: access: generate source files into build directory
  src: admin: generate source files into build directory
  src: esx: generate source files into build directory
  src: hyperv: generate source files into build directory
  src: locking: generate source files into build directory
  src: logging: generate source files into build directory
  src: lxc: generate source files into build directory
  src: remote: generate source files into build directory
  src: stop distributing generated source files
  tools: stop distributing generated source files

 .gitignore  | 276 ++---
 .travis.yml |   3 +-
 README-hacking  |  11 +-
 README.md   |  11 +-
 bootstrap.conf  |   6 +
 build-aux/syntax-check.mk   |  47 ++--
 configure.ac|   6 +
 docs/compiling.html.in  |  10 +-
 docs/windows.html.in|   3 +-
 libvirt.spec.in |  10 +-
 po/Makefile.am  |  45 ++--
 po/POTFILES | 320 -
 po/POTFILES.in  | 356 
 po/README.md|   3 +
 src/Makefile.am |  13 +-
 src/access/Makefile.inc.am  |  17 +-
 src/admin/Makefile.inc.am   |  24 +-
 src/bhyve/Makefile.inc.am   |   1 +
 src/esx/Makefile.inc.am |   9 +-
 src/esx/esx_vi_generator.py |  11 +-
 src/hyperv/Makefile.inc.am  |   9 +-
 src/hyperv/hyperv_wmi_generator.py  |  11 +-
 src/interface/Makefile.inc.am   |   2 +
 src/libxl/Makefile.inc.am   |   2 +
 src/locking/Makefile.inc.am |  16 +-
 src/logging/Makefile.inc.am |  18 +-
 src/lxc/Makefile.inc.am |  36 ++-
 src/network/Makefile.inc.am |   2 +
 src/node_device/Makefile.inc.am |   2 +
 src/nwfilter/Makefile.inc.am|   2 +
 src/qemu/Makefile.inc.am|   2 +
 src/remote/Makefile.inc.am  |  45 ++--
 src/remote/remote_daemon_dispatch.c |   4 +-
 src/rpc/Makefile.inc.am |   8 +-
 src/secret/Makefile.inc.am  |   2 +
 src/storage/Makefile.inc.am |   2 +
 src/util/Makefile.inc.am|   6 +-
 src/vbox/Makefile.inc.am|   1 +
 src/vz/Makefile.inc.am  |   1 +
 tests/Makefile.am   |   4 +
 tools/Makefile.am   |   1 -
 41 files changed, 636 insertions(+), 722 deletions(-)
 delete mode 100644 po/POTFILES
 create mode 100644 po/POTFILES.in

-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 09/20] [ACKED] remote: unify rpc server dispatch generated files

[Pavel Hrdina]

Our naming was not consistent.  Use the protocol name as prefix for all
generated files.

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- modify generated_files in for sc_po_check as well

 build-aux/syntax-check.mk   |  3 ++-
 src/remote/Makefile.inc.am  | 12 ++--
 src/remote/remote_daemon_dispatch.c |  4 ++--
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 75993ee284..156c72d452 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1976,7 +1976,8 @@ po_file ?= $(srcdir)/po/POTFILES.in
 generated_files = \
   $(builddir)/src/*.[ch] \
   $(builddir)/src/*/*.[ch] \
-  
$(srcdir)/src/*/{remote_daemon,admin_server,log_daemon,lock_daemon}_dispatch_*stubs.h
 \
+  $(srcdir)/src/*/{remote,qemu,lxc,log,lock}_daemon_dispatch_stubs.h \
+  $(srcdir)/src/admin/admin_server_dispatch_stubs.h \
   $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
   $(srcdir)/src/remote/*_client_bodies.h \
   $(srcdir)/src/*/*_protocol.[ch] \
diff --git a/src/remote/Makefile.inc.am b/src/remote/Makefile.inc.am
index 00f2212909..5c5f5f4d2c 100644
--- a/src/remote/Makefile.inc.am
+++ b/src/remote/Makefile.inc.am
@@ -20,8 +20,8 @@ REMOTE_DRIVER_SOURCES = \
 
 REMOTE_DAEMON_GENERATED = \
remote/remote_daemon_dispatch_stubs.h \
-   remote/remote_daemon_dispatch_lxc_stubs.h \
-   remote/remote_daemon_dispatch_qemu_stubs.h \
+   remote/lxc_daemon_dispatch_stubs.h \
+   remote/qemu_daemon_dispatch_stubs.h \
$(NULL)
 
 REMOTE_DAEMON_SOURCES = \
@@ -442,17 +442,17 @@ remote/remote_daemon_dispatch_stubs.h: 
$(srcdir)/rpc/gendispatch.pl \
  --mode=server remote REMOTE $(REMOTE_PROTOCOL) \
  > $(srcdir)/remote/remote_daemon_dispatch_stubs.h
 
-remote/remote_daemon_dispatch_lxc_stubs.h: $(srcdir)/rpc/gendispatch.pl \
+remote/lxc_daemon_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
$(LXC_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
  --mode=server lxc LXC $(LXC_PROTOCOL) \
- > $(srcdir)/remote/remote_daemon_dispatch_lxc_stubs.h
+ > $(srcdir)/remote/lxc_daemon_dispatch_stubs.h
 
-remote/remote_daemon_dispatch_qemu_stubs.h: $(srcdir)/rpc/gendispatch.pl \
+remote/qemu_daemon_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
$(QEMU_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(top_srcdir)/src/rpc/gendispatch.pl \
  --mode=server qemu QEMU $(QEMU_PROTOCOL) \
- > $(srcdir)/remote/remote_daemon_dispatch_qemu_stubs.h
+ > $(srcdir)/remote/qemu_daemon_dispatch_stubs.h
 
 libvirtd.8.in: remote/libvirtd.pod
$(AM_V_GEN)$(POD2MAN) --section=8 $< $@-t1 && \
diff --git a/src/remote/remote_daemon_dispatch.c 
b/src/remote/remote_daemon_dispatch.c
index be20556128..66693ff7ae 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -131,8 +131,8 @@ remoteGetStorageConn(virNetServerClientPtr client);
 
 
 #include "remote_daemon_dispatch_stubs.h"
-#include "remote_daemon_dispatch_qemu_stubs.h"
-#include "remote_daemon_dispatch_lxc_stubs.h"
+#include "qemu_daemon_dispatch_stubs.h"
+#include "lxc_daemon_dispatch_stubs.h"
 
 
 /* Prototypes */
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 01/20] build: mandate use of a build dir != src dir

[Pavel Hrdina]

Historically we've allowed builds in the main src dir, but meson does
not support this. Explicitly force separate build dir in autotools to
align with meson. We must re-enable dependency tracking which the RPM
%configure macro turns off. Without this, the build dir doesn't get
the source directory tree mirrored.

Signed-off-by: Daniel P. Berrangé 
Signed-off-by: Pavel Hrdina 
---

Notes:
New in v2.

Changes in v4:
- Fixed Travis rules and documentation

 .travis.yml|  3 ++-
 README-hacking | 11 ---
 README.md  | 11 +++
 bootstrap.conf |  6 ++
 configure.ac   |  6 ++
 docs/compiling.html.in | 10 ++
 docs/windows.html.in   |  3 ++-
 libvirt.spec.in| 10 +-
 8 files changed, 46 insertions(+), 14 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 478909d3bb..8b70c1c937 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -53,7 +53,8 @@ matrix:
   script:
 # We can't run 'distcheck' or 'syntax-check' because they fail on
 # macOS, but doing 'install' and 'dist' gives us some useful coverage
-- ./autogen.sh --prefix=$(pwd)/install-root && make -j3 && make -j3 
install && make -j3 dist
+- mkdir build && cd build
+- ../autogen.sh --prefix=$(pwd)/install-root && make -j3 && make -j3 
install && make -j3 dist
 
 git:
   submodules: true
diff --git a/README-hacking b/README-hacking
index ec04271c6a..7da940eb13 100644
--- a/README-hacking
+++ b/README-hacking
@@ -11,7 +11,7 @@ We've opted to keep only the highest-level sources in the GIT 
repository.
 This eases our maintenance burden, (fewer merges etc.), but imposes more
 requirements on anyone wishing to build from the just-checked-out sources.
 Note the requirements to build the released archive are much less and
-are just the requirements of the standard ./configure && make procedure.
+are just the requirements of the standard configure && make procedure.
 Specific development tools and versions will be checked for and listed by
 the bootstrap script.
 
@@ -34,10 +34,14 @@ reduce download time and disk space requirements:
 
 $ export GNULIB_SRCDIR=/path/to/gnulib
 
+We require to have the build directory different than the source directory:
+
+$ mkdir build && cd build
+
 The next step is to get all required pieces from gnulib,
-to run autoreconf, and to invoke ./configure:
+to run autoreconf, and to invoke ../autogen.sh:
 
-$ ./autogen.sh
+$ ../autogen.sh
 
 And there you are!  Just
 
@@ -47,6 +51,7 @@ And there you are!  Just
 At this point, there should be no difference between your local copy,
 and the GIT master copy:
 
+$ cd ..
 $ git diff
 
 should output no difference.
diff --git a/README.md b/README.md
index 4d1e86259d..44b0dd87c5 100644
--- a/README.md
+++ b/README.md
@@ -38,11 +38,13 @@ Installation
 
 
 Libvirt uses the GNU Autotools build system, so in general can be built
-and installed with the usual commands. For example, to build in a manner
-that is suitable for installing as root, use:
+and installed with the usual commands, however, we mandate to have the
+build directory different than the source directory. For example, to build
+in a manner that is suitable for installing as root, use:
 
 ```
-$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
+$ mkdir build && cd build
+$ ../configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
 $ make
 $ sudo make install
 ```
@@ -50,7 +52,8 @@ $ sudo make install
 While to build & install as an unprivileged user
 
 ```
-$ ./configure --prefix=$HOME/usr
+$ mkdir build && cd build
+$ ../configure --prefix=$HOME/usr
 $ make
 $ make install
 ```
diff --git a/bootstrap.conf b/bootstrap.conf
index 0c7de2d2aa..4c784487e2 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -164,3 +164,9 @@ bootstrap_post_import_hook()
   sed 's,\.\./\.\./\.\.,../..,g; s/^TESTS /GNULIB_TESTS /' $m > $m-t
   mv -f $m-t $m
 }
+
+bootstrap_epilogue()
+{
+echo "$0: done.  Now you can run 'mkdir build && cd build && 
../configure'."
+exit 0
+}
diff --git a/configure.ac b/configure.ac
index 233fbeaaf3..32b246842e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,12 @@ dnl License along with this library.  If not, see
 dnl .
 
 AC_INIT([libvirt], [5.10.0], [libvir-list@redhat.com], [], 
[https://libvirt.org])
+
+if test $srcdir = "."
+then
+  AC_MSG_ERROR([Build directory must be different from source directory])
+fi
+
 AC_CONFIG_SRCDIR([src/libvirt.c])
 AC_CONFIG_AUX_DIR([build-aux])
 AC_CONFIG_HEADERS([config.h])
diff --git a/docs/compiling.html.in b/docs/compiling.html.in
index 8dcceb3eb9..5869ebb90f 100644
--- a/docs/compiling.html.in
+++ b/docs/compiling.html.in
@@ -9,13 +9,15 @@
 Compiling a release tarball
 
 
-  libvirt uses the standard configure/make/install steps:
+  libvirt uses the standard configure/make/install steps and 

[libvirt] [PATCH v4 14/20] [ACKED] src: hyperv: generate source files into build directory

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore

 .gitignore |  1 -
 src/hyperv/Makefile.inc.am |  5 +++--
 src/hyperv/hyperv_wmi_generator.py | 11 +--
 3 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/.gitignore b/.gitignore
index 46f6f98045..85a417112d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,7 +41,6 @@ Makefile.in
 # libvirt related ignores
 /build/
 /ci/scratch/
-/src/hyperv/*.generated.*
 /src/locking/lock_daemon_dispatch_stubs.h
 /src/logging/log_daemon_dispatch_stubs.h
 /src/lxc/lxc_controller_dispatch.h
diff --git a/src/hyperv/Makefile.inc.am b/src/hyperv/Makefile.inc.am
index 6728b39c90..79e94d09bb 100644
--- a/src/hyperv/Makefile.inc.am
+++ b/src/hyperv/Makefile.inc.am
@@ -41,8 +41,8 @@ $(HYPERV_DRIVER_GENERATED): $(HYPERV_GENERATED_STAMP)
 
 $(HYPERV_GENERATED_STAMP): $(srcdir)/hyperv/hyperv_wmi_generator.input \
 $(srcdir)/hyperv/hyperv_wmi_generator.py
-   $(AM_V_GEN)srcdir=$(srcdir) $(RUNUTF8) $(PYTHON) \
- $(srcdir)/hyperv/hyperv_wmi_generator.py \
+   $(AM_V_GEN) $(RUNUTF8) $(PYTHON) \
+ $(srcdir)/hyperv/hyperv_wmi_generator.py $(srcdir) $(builddir) \
  && touch $@
 
 MAINTAINERCLEANFILES += $(HYPERV_DRIVER_GENERATED) $(HYPERV_GENERATED_STAMP)
@@ -53,6 +53,7 @@ libvirt_la_BUILT_LIBADD += libvirt_driver_hyperv.la
 libvirt_driver_hyperv_la_CFLAGS = \
$(OPENWSMAN_CFLAGS) \
-I$(srcdir)/conf \
+   -I$(builddir)/hyperv \
$(AM_CFLAGS) \
$(NULL)
 libvirt_driver_hyperv_la_LDFLAGS = $(AM_LDFLAGS)
diff --git a/src/hyperv/hyperv_wmi_generator.py 
b/src/hyperv/hyperv_wmi_generator.py
index a9ece0ff00..c3cd39cc76 100755
--- a/src/hyperv/hyperv_wmi_generator.py
+++ b/src/hyperv/hyperv_wmi_generator.py
@@ -454,12 +454,11 @@ def parse_class(block):
 
 
 def main():
-if "srcdir" in os.environ:
-input_filename = os.path.join(os.environ["srcdir"], 
"hyperv/hyperv_wmi_generator.input")
-output_dirname = os.path.join(os.environ["srcdir"], "hyperv")
-else:
-input_filename = os.path.join(os.getcwd(), 
"hyperv_wmi_generator.input")
-output_dirname = os.getcwd()
+if len(sys.argv) != 3:
+report_error("usage: %s srcdir builddir" % sys.argv[0])
+
+input_filename = os.path.join(sys.argv[1], "hyperv", 
"hyperv_wmi_generator.input")
+output_dirname = os.path.join(sys.argv[2], "hyperv")
 
 classes_typedef = open_and_print(os.path.join(output_dirname, 
"hyperv_wmi_classes.generated.typedef"))
 classes_header = open_and_print(os.path.join(output_dirname, 
"hyperv_wmi_classes.generated.h"))
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] s390: change default cpu model to host-model?

[Daniel P . Berrangé]

On Fri, Nov 08, 2019 at 02:29:15PM +0100, Christian Borntraeger wrote:
> 
> 
> On 08.11.19 14:10, Daniel P. Berrangé wrote:
> > On Fri, Nov 08, 2019 at 01:56:47PM +0100, Christian Borntraeger wrote:
> >>
> >>
> >> On 08.11.19 12:52, Daniel P. Berrangé wrote:
> >>> On Fri, Nov 08, 2019 at 12:49:23PM +0100, Christian Borntraeger wrote:
> 
> 
>  On 08.11.19 12:43, Daniel P. Berrangé wrote:
> > On Mon, Nov 04, 2019 at 11:49:01AM +0100, David Hildenbrand wrote:
> >> On 02.11.19 11:32, Daniel P. Berrangé wrote:
> >>> On Fri, Nov 01, 2019 at 06:43:16PM +0100, Christian Borntraeger wrote:
>  On the KVM forum I have discussed the default cpu model mode on s390.
>  Right now if the xml does not specify anything, libvirt defaults to
>  not specifying anything on the qemu command line (no -cpu statement)
>  which is the equivalent of -cpu host for s390 which is equivalent to
>  host-passthrough. While this enables all features it does not provide
>  any migration safety by default.
> 
>  So in fact we are kind of "broken" right now when it comes to safery.
> 
>  So we discussed that it would make sense that an empty xml should 
>  actually
>  be defaulted to host-model, which results in - as of today - the 
>  same guest
>  features but in a migration safe way.
> 
>  There is another change planned right now to actually make the cpu 
>  model
>  present in an xml if none was specified. So we could actually do 
>  this change
>  before, together  or after te other. Jiri and I think it probably 
>  makes most
>  sense to have both changes at the same time (in terms of libvirt 
>  version).
> 
>  Does anyone see an issue with changing the default model mode to 
>  "host-model"
>  if the xml does not specify anything else?
> >>>
> >>> Changing from "host-passthrough" to "host-model" is not a huge 
> >>> difference,
> >>> but it is none the less a guest ABI change. "host-passthrough" doesn't
> >>> provide migration safety in the face of differing hardware, it should 
> >>> still
> >>> be valid for people with homogeneous hardware. So changing the model 
> >>> will
> >>> potentially break some existing usage.
> >>
> >> I guess on s390x this is not the case ("-cpu host", no "-cpu", and 
> >> passing
> >> the expanded "host" model will result in the same guest ABI, in 
> >> contrast to
> >> x86 AFAIK). There is this special case, though, where we have old QEMUs
> >> without CPU model support. Not sure how to deal with that, then.
> >
> > I'm still not sure I understand the s390 CPU ABI rules.
> >
> > Current libvirt, no , and thus no -cpu.
> >
> > IIUC this is functionally identical to using "-cpu host" and/or
> > 
> >
> > If you are using "-cpu host" /  can you
> > live migrate to another host with identical physical CPUs + firmware ?
> >
> >
> > Assuming this is possible, then, can you live migrate a QEMU guest
> > booted with , to a QEMU guest booted
> > with   ?
> 
>  Not sure I understand your question. With "can", do  you mean "the guest
>  has the same guest visible CPU features and types"?
> >>>
> >>> Yes, I mean the migration should succeed from QEMU's POV and additionally
> >>> the guest OS should not see any change in CPU ABI exposed from the host.
> >>
> >> The guest ABI is the same and migration also seems to work. 
> >> I think your concern boils down to the case that source and target
> >> have a different libvirt version (but qemu and kernel and firmware
> >> and hardware are identical). So for that case this change would break
> >> things if host-model and host-passthrough are not identical.
> >> So as of today we have no concern. 
> >>
> >> Now: Would it be a concern if a future QEMU decides to change that
> >> equivalence somehow?
> > 
> > If they're the same guest ABI, then what's the benefit in changing the
> > default to "host-model" instead of just continuing with "host-passthrough".
> > It seems like we're fine to just carry on with "host-passthrough" as
> > the default and insulate ourselves from any future risk of change.
> 
> The benefit is that that todays default is not migration safe and users will
> find that out by random guest crashes if any of the parameters (CPU, kernel,
> qemu, firmware) is different. So really, todays default is just completely
> broken on s390 and thats why I want to change it.
> 
> host-model instead is expanded by libvirt and the migration will be rejected
> if the target is incompatible (qemu will reject to run).

Ok, so both host-model and host-passthrough end up expanding to the same
named CPU model eventually.

The only difference that in host-model case the expansion is done by libvirt
& we can 

[libvirt] [PATCH v4 11/20] [ACKED] src: access: generate source files into build directory

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore

 .gitignore  |  7 ---
 po/POTFILES.in  |  3 +++
 src/access/Makefile.inc.am  | 14 +++---
 src/admin/Makefile.inc.am   |  1 +
 src/interface/Makefile.inc.am   |  1 +
 src/libxl/Makefile.inc.am   |  1 +
 src/lxc/Makefile.inc.am |  1 +
 src/network/Makefile.inc.am |  1 +
 src/node_device/Makefile.inc.am |  1 +
 src/nwfilter/Makefile.inc.am|  1 +
 src/qemu/Makefile.inc.am|  1 +
 src/remote/Makefile.inc.am  |  1 +
 src/secret/Makefile.inc.am  |  1 +
 src/storage/Makefile.inc.am |  1 +
 14 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/.gitignore b/.gitignore
index 6f8d59987e..8c1078c56c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,13 +41,6 @@ Makefile.in
 # libvirt related ignores
 /build/
 /ci/scratch/
-/src/access/org.libvirt.api.policy
-/src/access/viraccessapicheck.c
-/src/access/viraccessapicheck.h
-/src/access/viraccessapichecklxc.c
-/src/access/viraccessapichecklxc.h
-/src/access/viraccessapicheckqemu.c
-/src/access/viraccessapicheckqemu.h
 /src/admin/admin_client.h
 /src/admin/admin_server_dispatch_stubs.h
 /src/esx/*.generated.*
diff --git a/po/POTFILES.in b/po/POTFILES.in
index a422d3659e..6f4bfeeb3d 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,3 +1,6 @@
+@BUILDDIR@/src/access/viraccessapicheck.c
+@BUILDDIR@/src/access/viraccessapichecklxc.c
+@BUILDDIR@/src/access/viraccessapicheckqemu.c
 @SRCDIR@/gnulib/lib/gai_strerror.c
 @SRCDIR@/gnulib/lib/regcomp.c
 @SRCDIR@/src/access/viraccessdriverpolkit.c
diff --git a/src/access/Makefile.inc.am b/src/access/Makefile.inc.am
index ea27adbe0b..2d871ec8aa 100644
--- a/src/access/Makefile.inc.am
+++ b/src/access/Makefile.inc.am
@@ -38,7 +38,7 @@ ACCESS_DRIVER_POLKIT_SOURCES = \
access/viraccessdriverpolkit.c \
$(NULL)
 
-ACCESS_DRIVER_POLKIT_POLICY = $(srcdir)/access/org.libvirt.api.policy
+ACCESS_DRIVER_POLKIT_POLICY = access/org.libvirt.api.policy
 
 GENERATED_SYM_FILES += $(ACCESS_DRIVER_SYM_FILES)
 
@@ -122,31 +122,31 @@ access/viraccessapicheck.h: $(srcdir)/rpc/gendispatch.pl \
$(REMOTE_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=aclheader \
  remote REMOTE $(REMOTE_PROTOCOL) \
- > $(srcdir)/access/viraccessapicheck.h
+ > access/viraccessapicheck.h
 access/viraccessapicheck.c: $(srcdir)/rpc/gendispatch.pl \
$(REMOTE_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=aclbody \
  remote REMOTE $(REMOTE_PROTOCOL) access/viraccessapicheck.h \
- > $(srcdir)/access/viraccessapicheck.c
+ > access/viraccessapicheck.c
 
 access/viraccessapicheckqemu.h: $(srcdir)/rpc/gendispatch.pl \
$(QEMU_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=aclheader \
  qemu QEMU $(QEMU_PROTOCOL) \
- > $(srcdir)/access/viraccessapicheckqemu.h
+ > access/viraccessapicheckqemu.h
 access/viraccessapicheckqemu.c: $(srcdir)/rpc/gendispatch.pl \
$(QEMU_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=aclbody \
  qemu QEMU $(QEMU_PROTOCOL) access/viraccessapicheckqemu.h \
- > $(srcdir)/access/viraccessapicheckqemu.c
+ > access/viraccessapicheckqemu.c
 
 access/viraccessapichecklxc.h: $(srcdir)/rpc/gendispatch.pl \
$(LXC_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=aclheader \
  lxc LXC $(LXC_PROTOCOL) \
- > $(srcdir)/access/viraccessapichecklxc.h
+ > access/viraccessapichecklxc.h
 access/viraccessapichecklxc.c: $(srcdir)/rpc/gendispatch.pl \
$(LXC_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=aclbody \
  lxc LXC $(LXC_PROTOCOL) access/viraccessapichecklxc.h \
- > $(srcdir)/access/viraccessapichecklxc.c
+ > access/viraccessapichecklxc.c
diff --git a/src/admin/Makefile.inc.am b/src/admin/Makefile.inc.am
index bea0967aaf..94cbed9972 100644
--- a/src/admin/Makefile.inc.am
+++ b/src/admin/Makefile.inc.am
@@ -89,6 +89,7 @@ endif WITH_DTRACE_PROBES
 libvirt_admin_la_CFLAGS = \
$(AM_CFLAGS) \
-I$(builddir)/admin \
+   -I$(builddir)/access \
-I$(srcdir)/remote \
-I$(srcdir)/rpc \
-I$(builddir)/rpc \
diff --git a/src/interface/Makefile.inc.am b/src/interface/Makefile.inc.am
index 780b2277ba..30ea98ad15 100644
--- a/src/interface/Makefile.inc.am
+++ b/src/interface/Makefile.inc.am
@@ -21,6 +21,7 @@ if WITH_INTERFACE
 mod_LTLIBRARIES += libvirt_driver_interface.la
 libvirt_driver_interface_la_CFLAGS = \
-I$(srcdir)/access \
+   

[libvirt] [PATCH v4 08/20] [ACKED] po: README.md: add a note about which Zanata client is required

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
New in v3.

 po/README.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/po/README.md b/po/README.md
index 71b5793a2d..2f77c5d48c 100644
--- a/po/README.md
+++ b/po/README.md
@@ -4,6 +4,9 @@ Libvirt Message Translation
 Libvirt translatable messages are maintained using the GNU Gettext tools and
 file formats, in combination with the Zanata web service.
 
+python-zanata-client is required in order to use make to pull/push translations
+from/to Zanata server.
+
 Source repository
 =
 
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 02/20] [ACKED] .gitignore: cleanup old and obsolete ignores

[Pavel Hrdina]

Now that we forbid builds in source directory we can remove a lot of
ignores that are created during build time.  To make the cleanup easier
in the future create a sections in our .gitignore file.

Signed-off-by: Pavel Hrdina 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
New in v2.

 .gitignore | 249 ++---
 1 file changed, 26 insertions(+), 223 deletions(-)

diff --git a/.gitignore b/.gitignore
index c45b8bd098..bd64eb5b1a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,44 +1,17 @@
+# vim related ignores
+*.swp
+.lvimrc
+
+# emacs related ignores
 *#*#
 *.#*#
-*.[187]
-*.[187].in
-*.a
-*.cov
-*.exe
-*.exe.manifest
-*.gcda
-*.gcno
-*.gcov
-*.html
-*.i
-*.la
-*.lo
-*.loT
-*.o
-*.orig
-*.pem
-*.pyc
-*.rej
-*.s
-*.service
-*.socket
-*.swp
-*~
 .#*
-.color_coded
-.deps
-.dirstamp
-.gdb_history
-.git
-.git-module-status
-.libs
-.lvimrc
-.memdump
-.sc-start-sc_*
-.ycm_extra_conf.py
+
+# autotools related ignores
+!/m4/virt-*.m4
+*.cov
 /AUTHORS
 /INSTALL
-/NEWS
 /aclocal.m4
 /autom4te.cache
 /build-aux/.gitignore
@@ -46,70 +19,32 @@
 /build-aux/depcomp
 /build-aux/missing
 /build-aux/test-driver
-/build/
-/ci/scratch/
-/confdefs.h
-/config.cache
-/config.guess
-/config.h
 /config.h.in
 /config.log
-/config.rpath
-/config.status
-/config.sub
 /configure
-/configure.lineno
-/conftest.*
-/docs/aclperms.htmlinc
-/docs/apibuild.py.stamp
-/docs/devhelp/libvirt.devhelp
-/docs/hvsupport.html.in
-/docs/libvirt-admin-*.xml
-/docs/libvirt-api.xml
-/docs/libvirt-lxc-*.xml
-/docs/libvirt-qemu-*.xml
-/docs/libvirt-refs.xml
-/docs/news.html.in
-/docs/todo.html.in
-/examples/c/admin/client_close
-/examples/c/admin/client_info
-/examples/c/admin/client_limits
-/examples/c/admin/list_clients
-/examples/c/admin/list_servers
-/examples/c/admin/logging
-/examples/c/admin/threadpool_params
-/examples/c/domain/dommigrate
-/examples/c/domain/domtop
-/examples/c/domain/info1
-/examples/c/domain/rename
-/examples/c/domain/suspend
-/examples/c/misc/event-test
-/examples/c/misc/hellolibvirt
-/examples/c/misc/openauth
+/m4/*
+Makefile.in
+
+# gnulib related ignores
+!/gnulib/lib/Makefile.am
+!/gnulib/tests/Makefile.am
+*.rej
+*~
 /gnulib/lib/*
 /gnulib/m4/*
 /gnulib/tests/*
-/include/libvirt/libvirt-common.h
-/libtool
-/libvirt-*.tar.xz
-/libvirt-[0-9]*
-/libvirt*.pc
-/libvirt.spec
-/ltconfig
-/ltmain.sh
-/m4/*
-/mingw-libvirt.spec
-/mkinstalldirs
+
+# git related ignores
+*.orig
+.git-module-status
+
+# libvirt related ignores
+!/po/*.mini.po
+/build/
+/ci/scratch/
 /po/*gmo
 /po/*po
-!/po/*.mini.po
 /po/*pot
-/proxy/
-/python/
-/run
-/sc_*
-/src/.*.stamp
-/src/*.pc
 /src/access/org.libvirt.api.policy
 /src/access/viraccessapicheck.c
 /src/access/viraccessapicheck.h
@@ -120,151 +55,19 @@
 /src/admin/admin_client.h
 /src/admin/admin_protocol.[ch]
 /src/admin/admin_server_dispatch_stubs.h
-/src/admin/libvirt_admin.def
-/src/admin/libvirt_admin.syms
-/src/bhyve/test_libvirtd_bhyve.aug
-/src/bhyve/test_virtbhyved.aug
-/src/bhyve/virtbhyved.aug
-/src/bhyve/virtbhyved.conf
 /src/esx/*.generated.*
 /src/hyperv/*.generated.*
-/src/interface/test_virtinterfaced.aug
-/src/interface/virtinterfaced.aug
-/src/interface/virtinterfaced.conf
-/src/libvirt*.def
-/src/libvirt.syms
-/src/libvirt_access.syms
-/src/libvirt_access.xml
-/src/libvirt_access_lxc.syms
-/src/libvirt_access_lxc.xml
-/src/libvirt_access_qemu.syms
-/src/libvirt_access_qemu.xml
-/src/libvirt_*.stp
-/src/libvirt_*helper
-/src/libvirt_*probes.h
-/src/libvirt_lxc
-/src/libvirtd
-/src/libvirtd*.logrotate
-/src/libxl/test_libvirtd_libxl.aug
-/src/libxl/test_virtxend.aug
-/src/libxl/virtxend.aug
-/src/libxl/virtxend.conf
-/src/locking/libxl-lockd.conf
-/src/locking/libxl-sanlock.conf
 /src/locking/lock_daemon_dispatch_stubs.h
 /src/locking/lock_protocol.[ch]
-/src/locking/qemu-lockd.conf
-/src/locking/qemu-sanlock.conf
-/src/locking/test_libvirt_sanlock.aug
-/src/locking/test_libvirt_lockd.aug
-/src/locking/test_virtlockd.aug
 /src/logging/log_daemon_dispatch_stubs.h
 /src/logging/log_protocol.[ch]
-/src/logging/test_virtlogd.aug
 /src/lxc/lxc_controller_dispatch.h
 /src/lxc/lxc_monitor_dispatch.h
 /src/lxc/lxc_monitor_protocol.c
 /src/lxc/lxc_monitor_protocol.h
-/src/lxc/lxc_protocol.[ch]
-/src/lxc/test_libvirtd_lxc.aug
-/src/lxc/test_virtlxcd.aug
-/src/lxc/virtlxcd.aug
-/src/lxc/virtlxcd.conf
-/src/network/test_virtnetworkd.aug
-/src/network/virtnetworkd.aug
-/src/network/virtnetworkd.conf
-/src/node_device/test_virtnodedevd.aug
-/src/node_device/virtnodedevd.aug
-/src/node_device/virtnodedevd.conf
-/src/nwfilter/test_virtnwfilterd.aug
-/src/nwfilter/virtnwfilterd.aug
-/src/nwfilter/virtnwfilterd.conf
-/src/qemu/test_libvirtd_qemu.aug
-/src/qemu/test_virtqemud.aug
-/src/qemu/virtqemud.aug
-/src/qemu/virtqemud.conf
 /src/remote/*_client_bodies.h
 /src/remote/*_protocol.[ch]
 /src/remote/*_stubs.h
-/src/remote/libvirtd.aug
-/src/remote/libvirtd.conf
-/src/remote/test_libvirtd.aug
-/src/remote/test_virtproxyd.aug
-/src/remote/virtproxyd.aug

[libvirt] [PATCH v4 10/20] [ACKED] src: generate source files into build directory

[Pavel Hrdina]

This affects more than src/Makefile.am as the rule to generate source
files for protocols is generic for all sub-directories.

Affected files are:
src/admin/admin_protocol.{h,c}
src/locking/lock_protocol.{h,c}
src/logging/log_protocol.{h,c}
src/lxc/lxc_monitor_protocol.{h,c}
src/remote/{lxc,qemu,remote}_protocol.{h,c}
src/rpc/{virkeepalive,virnet}protocol.{h,c}

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore
- modify generated_files for sc_po_check as well

 .gitignore  | 8 
 build-aux/syntax-check.mk   | 1 -
 src/Makefile.am | 4 ++--
 src/admin/Makefile.inc.am   | 3 +++
 src/locking/Makefile.inc.am | 6 ++
 src/logging/Makefile.inc.am | 4 
 src/lxc/Makefile.inc.am | 4 
 src/remote/Makefile.inc.am  | 4 
 src/rpc/Makefile.inc.am | 3 +++
 tests/Makefile.am   | 1 +
 10 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4c4807019c..6f8d59987e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -49,21 +49,13 @@ Makefile.in
 /src/access/viraccessapicheckqemu.c
 /src/access/viraccessapicheckqemu.h
 /src/admin/admin_client.h
-/src/admin/admin_protocol.[ch]
 /src/admin/admin_server_dispatch_stubs.h
 /src/esx/*.generated.*
 /src/hyperv/*.generated.*
 /src/locking/lock_daemon_dispatch_stubs.h
-/src/locking/lock_protocol.[ch]
 /src/logging/log_daemon_dispatch_stubs.h
-/src/logging/log_protocol.[ch]
 /src/lxc/lxc_controller_dispatch.h
 /src/lxc/lxc_monitor_dispatch.h
-/src/lxc/lxc_monitor_protocol.c
-/src/lxc/lxc_monitor_protocol.h
 /src/remote/*_client_bodies.h
-/src/remote/*_protocol.[ch]
 /src/remote/*_stubs.h
-/src/rpc/virkeepaliveprotocol.[ch]
-/src/rpc/virnetprotocol.[ch]
 tags
diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 156c72d452..b83e98860d 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1980,7 +1980,6 @@ generated_files = \
   $(srcdir)/src/admin/admin_server_dispatch_stubs.h \
   $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
   $(srcdir)/src/remote/*_client_bodies.h \
-  $(srcdir)/src/*/*_protocol.[ch] \
   $(srcdir)/gnulib/lib/*.[ch]
 
 _gl_translatable_string_re ?= \b(N?_|gettext *)\([^)"]*("|$$)
diff --git a/src/Makefile.am b/src/Makefile.am
index e0b917fcdd..da7e2e6c80 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -394,11 +394,11 @@ GENERATED_SYM_FILES += \
 
 %protocol.c: %protocol.x %protocol.h $(srcdir)/rpc/genprotocol.pl
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/genprotocol.pl $(RPCGEN) -c \
-  $< $(srcdir)/$(subst $(srcdir)/,,$@)
+  $< $(subst $(srcdir)/,,$@)
 
 %protocol.h: %protocol.x $(srcdir)/rpc/genprotocol.pl
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/genprotocol.pl $(RPCGEN) -h \
-  $< $(srcdir)/$(subst $(srcdir)/,,$@)
+  $< $(subst $(srcdir)/,,$@)
 
 check-local: check-augeas
 
diff --git a/src/admin/Makefile.inc.am b/src/admin/Makefile.inc.am
index 4fd7878e5c..bea0967aaf 100644
--- a/src/admin/Makefile.inc.am
+++ b/src/admin/Makefile.inc.am
@@ -30,6 +30,7 @@ libvirt_driver_admin_la_CFLAGS = \
$(XDR_CFLAGS) \
-I$(top_srcdir)/src/util \
-I$(top_srcdir)/src/admin \
+   -I$(top_builddir)/src/rpc \
$(NULL)
 libvirt_driver_admin_la_LIBADD = ../gnulib/lib/libgnu.la
 libvirt_driver_admin_la_LDFLAGS = -module -avoid-version $(AM_LDFLAGS)
@@ -87,8 +88,10 @@ endif WITH_DTRACE_PROBES
 
 libvirt_admin_la_CFLAGS = \
$(AM_CFLAGS) \
+   -I$(builddir)/admin \
-I$(srcdir)/remote \
-I$(srcdir)/rpc \
+   -I$(builddir)/rpc \
$(XDR_CFLAGS) \
$(CAPNG_CFLAGS) \
$(YAJL_CFLAGS) \
diff --git a/src/locking/Makefile.inc.am b/src/locking/Makefile.inc.am
index 2b1c030041..ba7a9ea2ea 100644
--- a/src/locking/Makefile.inc.am
+++ b/src/locking/Makefile.inc.am
@@ -109,6 +109,9 @@ lockd_la_SOURCES = \
$(NULL)
 lockd_la_CFLAGS = \
-I$(srcdir)/conf \
+   -I$(srcdir)/locking \
+   -I$(builddir)/locking \
+   -I$(builddir)/rpc \
$(XDR_CFLAGS) \
$(AM_CFLAGS) \
$(NULL)
@@ -146,6 +149,9 @@ virtlockd_SOURCES = \
$(LOCK_DAEMON_GENERATED) \
$(NULL)
 virtlockd_CFLAGS = \
+   -I$(srcdir)/locking \
+   -I$(builddir)/locking \
+   -I$(builddir)/rpc \
$(AM_CFLAGS) \
$(PIE_CFLAGS) \
$(XDR_CFLAGS) \
diff --git a/src/logging/Makefile.inc.am b/src/logging/Makefile.inc.am
index 7d10b646ea..bb7ea7338d 100644
--- a/src/logging/Makefile.inc.am
+++ b/src/logging/Makefile.inc.am
@@ -67,6 +67,8 @@ libvirt_driver_log_la_SOURCES = \
$(LOG_DRIVER_SOURCES) \
$(NULL)
 libvirt_driver_log_la_CFLAGS = \
+   -I$(builddir)/logging \
+   -I$(builddir)/rpc \
$(AM_CFLAGS) \
$(XDR_CFLAGS) \
$(NULL)
@@ -82,6 +84,8 @@ virtlogd_SOURCES = \

[libvirt] [PATCH v4 17/20] [ACKED] src: lxc: generate source files into build directory

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore
- modify generated_files for sc_po_check as well

 .gitignore| 2 --
 build-aux/syntax-check.mk | 1 -
 src/lxc/Makefile.inc.am   | 4 ++--
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index eaad5a1883..38d6637c1c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,8 +41,6 @@ Makefile.in
 # libvirt related ignores
 /build/
 /ci/scratch/
-/src/lxc/lxc_controller_dispatch.h
-/src/lxc/lxc_monitor_dispatch.h
 /src/remote/*_client_bodies.h
 /src/remote/*_stubs.h
 tags
diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index a7e87e7a81..392fc34320 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1977,7 +1977,6 @@ generated_files = \
   $(builddir)/src/*.[ch] \
   $(builddir)/src/*/*.[ch] \
   $(srcdir)/src/*/{remote,qemu,lxc}_daemon_dispatch_stubs.h \
-  $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
   $(srcdir)/src/remote/*_client_bodies.h \
   $(srcdir)/gnulib/lib/*.[ch]
 
diff --git a/src/lxc/Makefile.inc.am b/src/lxc/Makefile.inc.am
index f22a53e58d..cb55dfd1c6 100644
--- a/src/lxc/Makefile.inc.am
+++ b/src/lxc/Makefile.inc.am
@@ -252,13 +252,13 @@ lxc/lxc_monitor_dispatch.h: $(srcdir)/rpc/gendispatch.pl \
$(LXC_MONITOR_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=client \
  virLXCMonitor VIR_LXC_MONITOR $(LXC_MONITOR_PROTOCOL) > \
- $(srcdir)/lxc/lxc_monitor_dispatch.h
+ lxc/lxc_monitor_dispatch.h
 
 lxc/lxc_controller_dispatch.h: $(srcdir)/rpc/gendispatch.pl \
$(REMOTE_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=server \
  virLXCMonitor VIR_LXC_MONITOR $(LXC_MONITOR_PROTOCOL) > \
- $(srcdir)/lxc/lxc_controller_dispatch.h
+ lxc/lxc_controller_dispatch.h
 
 .PHONY: \
install-data-lxc \
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 03/20] [ACKED] syntax-check.mk: fix sc_po_check rule

[Pavel Hrdina]

Commit <22d8e27ccd5faf48ee2bf288a1b9059aa7ffd28b> introduced our
syntax-check.mk file based on gnulib rules. However, the rule was
completely ignored as we don't have POTFILES.in file.

Signed-off-by: Pavel Hrdina 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
New in v2.

 build-aux/syntax-check.mk |  2 +-
 po/POTFILES   | 38 +++---
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 033eaf70c4..5890f4737f 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1974,7 +1974,7 @@ perl_translatable_files_list_ =   
\
 
 # Verify that all source files using _() (more specifically, files that
 # match $(_gl_translatable_string_re)) are listed in po/POTFILES.in.
-po_file ?= $(srcdir)/po/POTFILES.in
+po_file ?= $(srcdir)/po/POTFILES
 generated_files ?= $(srcdir)/lib/*.[ch]
 _gl_translatable_string_re ?= \b(N?_|gettext *)\([^)"]*("|$$)
 sc_po_check:
diff --git a/po/POTFILES b/po/POTFILES
index 04eba73725..217d7e2006 100644
--- a/po/POTFILES
+++ b/po/POTFILES
@@ -29,6 +29,7 @@ src/conf/netdev_vport_profile_conf.c
 src/conf/network_conf.c
 src/conf/networkcommon_conf.c
 src/conf/node_device_conf.c
+src/conf/node_device_util.c
 src/conf/numa_conf.c
 src/conf/nwfilter_conf.c
 src/conf/nwfilter_params.c
@@ -38,9 +39,14 @@ src/conf/snapshot_conf.c
 src/conf/storage_adapter_conf.c
 src/conf/storage_conf.c
 src/conf/virchrdev.c
+src/conf/virdomainmomentobjlist.c
 src/conf/virdomainobjlist.c
 src/conf/virnetworkobj.c
+src/conf/virnetworkportdef.c
 src/conf/virnodedeviceobj.c
+src/conf/virnwfilterbindingdef.c
+src/conf/virnwfilterbindingobj.c
+src/conf/virnwfilterbindingobjlist.c
 src/conf/virnwfilterobj.c
 src/conf/virsavecookie.c
 src/conf/virsecretobj.c
@@ -60,6 +66,7 @@ src/esx/esx_storage_backend_vmfs.c
 src/esx/esx_storage_driver.c
 src/esx/esx_stream.c
 src/esx/esx_util.c
+src/esx/esx_util.h
 src/esx/esx_vi.c
 src/esx/esx_vi_methods.c
 src/esx/esx_vi_types.c
@@ -128,16 +135,22 @@ src/phyp/phyp_driver.c
 src/qemu/qemu_agent.c
 src/qemu/qemu_alias.c
 src/qemu/qemu_block.c
+src/qemu/qemu_blockjob.c
 src/qemu/qemu_capabilities.c
 src/qemu/qemu_cgroup.c
+src/qemu/qemu_checkpoint.c
 src/qemu/qemu_command.c
 src/qemu/qemu_conf.c
+src/qemu/qemu_dbus.c
 src/qemu/qemu_domain.c
 src/qemu/qemu_domain_address.c
 src/qemu/qemu_driver.c
+src/qemu/qemu_extdevice.c
+src/qemu/qemu_firmware.c
 src/qemu/qemu_hostdev.c
 src/qemu/qemu_hotplug.c
 src/qemu/qemu_interface.c
+src/qemu/qemu_interop_config.c
 src/qemu/qemu_migration.c
 src/qemu/qemu_migration_cookie.c
 src/qemu/qemu_migration_params.c
@@ -146,12 +159,15 @@ src/qemu/qemu_monitor_json.c
 src/qemu/qemu_monitor_text.c
 src/qemu/qemu_process.c
 src/qemu/qemu_qapi.c
+src/qemu/qemu_slirp.c
+src/qemu/qemu_tpm.c
+src/qemu/qemu_vhost_user.c
+src/qemu/qemu_vhost_user_gpu.c
 src/remote/remote_client_bodies.h
 src/remote/remote_daemon.c
 src/remote/remote_daemon_config.c
 src/remote/remote_daemon_dispatch.c
 src/remote/remote_daemon_dispatch_stubs.h
-src/remote/remote_daemon_dispatch_qemu_stubs.h
 src/remote/remote_daemon_stream.c
 src/remote/remote_driver.c
 src/rpc/virkeepalive.c
@@ -170,11 +186,13 @@ src/rpc/virnetsocket.c
 src/rpc/virnetsshsession.c
 src/rpc/virnettlscontext.c
 src/secret/secret_driver.c
+src/secret/secret_util.c
 src/security/security_apparmor.c
 src/security/security_dac.c
 src/security/security_driver.c
 src/security/security_manager.c
 src/security/security_selinux.c
+src/security/security_util.c
 src/security/virt-aa-helper.c
 src/storage/parthelper.c
 src/storage/storage_backend.c
@@ -182,6 +200,7 @@ src/storage/storage_backend_disk.c
 src/storage/storage_backend_fs.c
 src/storage/storage_backend_gluster.c
 src/storage/storage_backend_iscsi.c
+src/storage/storage_backend_iscsi_direct.c
 src/storage/storage_backend_logical.c
 src/storage/storage_backend_mpath.c
 src/storage/storage_backend_rbd.c
@@ -190,6 +209,8 @@ src/storage/storage_backend_sheepdog.c
 src/storage/storage_backend_vstorage.c
 src/storage/storage_backend_zfs.c
 src/storage/storage_driver.c
+src/storage/storage_file_fs.c
+src/storage/storage_file_gluster.c
 src/storage/storage_util.c
 src/test/test_driver.c
 src/util/iohelper.c
@@ -199,8 +220,11 @@ src/util/viraudit.c
 src/util/virauth.c
 src/util/virauthconfig.c
 src/util/virbitmap.c
-src/util/virbuffer.c
 src/util/vircgroup.c
+src/util/vircgroupbackend.c
+src/util/vircgroupbackend.h
+src/util/vircgroupv1.c
+src/util/vircgroupv2.c
 src/util/virclosecallbacks.c
 src/util/vircommand.c
 src/util/virconf.c
@@ -215,6 +239,7 @@ src/util/virfdstream.c
 src/util/virfile.c
 src/util/virfilecache.c
 src/util/virfirewall.c
+src/util/virfirewalld.c
 src/util/virfirmware.c
 src/util/virhash.c
 src/util/virhook.c
@@ -232,6 +257,7 @@ src/util/virlockspace.c
 src/util/virlog.c
 src/util/virmacmap.c
 src/util/virmdev.c
+src/util/virmodule.c
 src/util/virnetdev.c
 

[libvirt] [PATCH v4 05/20] [ACKED] syntax-check.mk: cleanup generated_files list for sc_po_check

[Pavel Hrdina]

Move generated_files variable closer to the sc_po_check rule and
remove non-existent gnulib internal path.

Signed-off-by: Pavel Hrdina 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
New in v2.

 build-aux/syntax-check.mk | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index 6acda4eea3..985739b373 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -134,15 +134,6 @@ syntax-check: $(local-check)
 # We use .gnulib, not gnulib.
 gnulib_dir = $(srcdir)/.gnulib
 
-# List of additional files that we want to pick up in our POTFILES.in
-# This is all gnulib files, as well as generated files for RPC code.
-generated_files = \
-  
$(srcdir)/src/*/{remote_daemon,admin_server,log_daemon,lock_daemon}_dispatch_*stubs.h
 \
-  $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
-  $(srcdir)/src/remote/*_client_bodies.h \
-  $(srcdir)/src/*/*_protocol.[ch] \
-  $(srcdir)/gnulib/lib/*.[ch]
-
 # We haven't converted all scripts to using gnulib's init.sh yet.
 _test_script_regex = \<\(init\|test-lib\)\.sh\>
 
@@ -1978,7 +1969,16 @@ perl_translatable_files_list_ =  
\
 # Verify that all source files using _() (more specifically, files that
 # match $(_gl_translatable_string_re)) are listed in po/POTFILES.in.
 po_file ?= $(srcdir)/po/POTFILES
-generated_files ?= $(srcdir)/lib/*.[ch]
+
+# List of additional files that we want to pick up in our POTFILES.in
+# This is all gnulib files, as well as generated files for RPC code.
+generated_files = \
+  
$(srcdir)/src/*/{remote_daemon,admin_server,log_daemon,lock_daemon}_dispatch_*stubs.h
 \
+  $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
+  $(srcdir)/src/remote/*_client_bodies.h \
+  $(srcdir)/src/*/*_protocol.[ch] \
+  $(srcdir)/gnulib/lib/*.[ch]
+
 _gl_translatable_string_re ?= \b(N?_|gettext *)\([^)"]*("|$$)
 
 # sc_po_check can fail if generated files are not built first
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 12/20] [ACKED] src: admin: generate source files into build directory

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore
- modify generated_files for sc_po_check as well

 .gitignore| 2 --
 build-aux/syntax-check.mk | 1 -
 po/POTFILES.in| 3 ++-
 src/admin/Makefile.inc.am | 7 ---
 4 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8c1078c56c..8989b3e3e3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,8 +41,6 @@ Makefile.in
 # libvirt related ignores
 /build/
 /ci/scratch/
-/src/admin/admin_client.h
-/src/admin/admin_server_dispatch_stubs.h
 /src/esx/*.generated.*
 /src/hyperv/*.generated.*
 /src/locking/lock_daemon_dispatch_stubs.h
diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk
index b83e98860d..cf60e890d2 100644
--- a/build-aux/syntax-check.mk
+++ b/build-aux/syntax-check.mk
@@ -1977,7 +1977,6 @@ generated_files = \
   $(builddir)/src/*.[ch] \
   $(builddir)/src/*/*.[ch] \
   $(srcdir)/src/*/{remote,qemu,lxc,log,lock}_daemon_dispatch_stubs.h \
-  $(srcdir)/src/admin/admin_server_dispatch_stubs.h \
   $(srcdir)/src/lxc/{lxc_monitor,lxc_controller}_dispatch.h \
   $(srcdir)/src/remote/*_client_bodies.h \
   $(srcdir)/gnulib/lib/*.[ch]
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 6f4bfeeb3d..ebd86a6cd3 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,13 +1,14 @@
 @BUILDDIR@/src/access/viraccessapicheck.c
 @BUILDDIR@/src/access/viraccessapichecklxc.c
 @BUILDDIR@/src/access/viraccessapicheckqemu.c
+@BUILDDIR@/src/admin/admin_client.h
+@BUILDDIR@/src/admin/admin_server_dispatch_stubs.h
 @SRCDIR@/gnulib/lib/gai_strerror.c
 @SRCDIR@/gnulib/lib/regcomp.c
 @SRCDIR@/src/access/viraccessdriverpolkit.c
 @SRCDIR@/src/access/viraccessmanager.c
 @SRCDIR@/src/admin/admin_server.c
 @SRCDIR@/src/admin/admin_server_dispatch.c
-@SRCDIR@/src/admin/admin_server_dispatch_stubs.h
 @SRCDIR@/src/admin/libvirt-admin.c
 @SRCDIR@/src/bhyve/bhyve_capabilities.c
 @SRCDIR@/src/bhyve/bhyve_command.c
diff --git a/src/admin/Makefile.inc.am b/src/admin/Makefile.inc.am
index 94cbed9972..448f7e1203 100644
--- a/src/admin/Makefile.inc.am
+++ b/src/admin/Makefile.inc.am
@@ -28,8 +28,9 @@ libvirt_driver_admin_la_SOURCES = \
 libvirt_driver_admin_la_CFLAGS = \
$(AM_CFLAGS) \
$(XDR_CFLAGS) \
-   -I$(top_srcdir)/src/util \
-I$(top_srcdir)/src/admin \
+   -I$(top_builddir)/src/admin \
+   -I$(top_srcdir)/src/util \
-I$(top_builddir)/src/rpc \
$(NULL)
 libvirt_driver_admin_la_LIBADD = ../gnulib/lib/libgnu.la
@@ -123,13 +124,13 @@ admin/admin_client.h: $(srcdir)/rpc/gendispatch.pl \
$(ADMIN_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=client \
  admin ADMIN $(ADMIN_PROTOCOL) \
- > $(srcdir)/admin/admin_client.h
+ > admin/admin_client.h
 
 admin/admin_server_dispatch_stubs.h: $(srcdir)/rpc/gendispatch.pl \
$(ADMIN_PROTOCOL) Makefile.am
$(AM_V_GEN)$(PERL) -w $(srcdir)/rpc/gendispatch.pl --mode=server \
  admin ADMIN $(ADMIN_PROTOCOL) \
- > $(srcdir)/admin/admin_server_dispatch_stubs.h
+ > admin/admin_server_dispatch_stubs.h
 
 admin/libvirt_admin.syms: admin/libvirt_admin_public.syms $(ADMIN_SYM_FILES) \
$(top_builddir)/config.status
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 13/20] [ACKED] src: esx: generate source files into build directory

[Pavel Hrdina]

Signed-off-by: Pavel Hrdina 
Reviewed-by: Ján Tomko 
Reviewed-by: Daniel P. Berrangé 
---

Notes:
Changes in v2:
- remove entries from .gitignore

 .gitignore  |  1 -
 src/esx/Makefile.inc.am |  5 +++--
 src/esx/esx_vi_generator.py | 11 ---
 tests/Makefile.am   |  3 +++
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8989b3e3e3..46f6f98045 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,7 +41,6 @@ Makefile.in
 # libvirt related ignores
 /build/
 /ci/scratch/
-/src/esx/*.generated.*
 /src/hyperv/*.generated.*
 /src/locking/lock_daemon_dispatch_stubs.h
 /src/logging/log_daemon_dispatch_stubs.h
diff --git a/src/esx/Makefile.inc.am b/src/esx/Makefile.inc.am
index 3dab05d71c..7ba9fd1758 100644
--- a/src/esx/Makefile.inc.am
+++ b/src/esx/Makefile.inc.am
@@ -63,8 +63,8 @@ $(ESX_DRIVER_GENERATED): $(ESX_GENERATED_STAMP)
 
 $(ESX_GENERATED_STAMP): $(srcdir)/esx/esx_vi_generator.input \
  $(srcdir)/esx/esx_vi_generator.py
-   $(AM_V_GEN)srcdir=$(srcdir) $(RUNUTF8) $(PYTHON) \
-   $(srcdir)/esx/esx_vi_generator.py && touch $@
+   $(AM_V_GEN) $(RUNUTF8) $(PYTHON) \
+   $(srcdir)/esx/esx_vi_generator.py $(srcdir) $(builddir) && 
touch $@
 
 MAINTAINERCLEANFILES += $(ESX_DRIVER_GENERATED) $(ESX_GENERATED_STAMP)
 
@@ -81,6 +81,7 @@ libvirt_la_BUILT_LIBADD += libvirt_driver_esx.la
 libvirt_driver_esx_la_CFLAGS = \
$(CURL_CFLAGS) \
-I$(srcdir)/conf \
+   -I$(builddir)/esx \
-I$(srcdir)/vmx \
$(AM_CFLAGS) \
$(NULL)
diff --git a/src/esx/esx_vi_generator.py b/src/esx/esx_vi_generator.py
index 28d440a6df..c77de6e60c 100755
--- a/src/esx/esx_vi_generator.py
+++ b/src/esx/esx_vi_generator.py
@@ -1379,14 +1379,11 @@ additional_object_features = {
 
 removed_object_features = {}
 
+if len(sys.argv) != 3:
+report_error("usage: %s srcdir builddir" % sys.argv[0])
 
-
-if "srcdir" in os.environ:
-input_filename = os.path.join(os.environ["srcdir"], 
"esx/esx_vi_generator.input")
-output_dirname = os.path.join(os.environ["srcdir"], "esx")
-else:
-input_filename = os.path.join(os.getcwd(), "esx_vi_generator.input")
-output_dirname = os.getcwd()
+input_filename = os.path.join(sys.argv[1], "esx/esx_vi_generator.input")
+output_dirname = os.path.join(sys.argv[2], "esx")
 
 
 
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 014d0ddd39..9d9c582e42 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -756,6 +756,9 @@ esxutilstest_SOURCES = \
esxutilstest.c \
testutils.c testutils.h
 esxutilstest_LDADD = $(LDADDS)
+esxutilstest_CFLAGS = \
+   -I$(top_builddir)/src/esx \
+   $(AM_CFLAGS)
 else ! WITH_ESX
 EXTRA_DIST += esxutilstest.c
 endif ! WITH_ESX
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v4 06/20] po: generate files into build directory

[Pavel Hrdina]

Historically we did not support VPATH builds and everything was
generated into source directory.  The introduction of VPATH builds
did not changed the way how our translation files are handled.

This patch changes the rules to generate everything into build
directory and stops distributing generated files in order to have
properly separated VPATH builds.

Signed-off-by: Pavel Hrdina 
---

Notes:
Changes in v2:
- keep the zanata binary name, this will be fixed by separate patch

Chnages in v3:
- update --transdir and --srcdir options as they are used by
  python-zanata-client

Changes in v4:
- reverted the HAVE_GNU_GETTEXT_TOOLS move

 .gitignore |  4 
 po/Makefile.am | 31 +++
 2 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/.gitignore b/.gitignore
index bd64eb5b1a..4c4807019c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,12 +39,8 @@ Makefile.in
 .git-module-status
 
 # libvirt related ignores
-!/po/*.mini.po
 /build/
 /ci/scratch/
-/po/*gmo
-/po/*po
-/po/*pot
 /src/access/org.libvirt.api.policy
 /src/access/viraccessapicheck.c
 /src/access/viraccessapicheck.h
diff --git a/po/Makefile.am b/po/Makefile.am
index b0e2c15d44..89e831f839 100644
--- a/po/Makefile.am
+++ b/po/Makefile.am
@@ -16,17 +16,16 @@ LANGS := \
 
 
 POTFILE_DEPS := $(shell $(SED) 's,^,$(top_srcdir)/,' $(srcdir)/POTFILES)
-POTFILE := $(srcdir)/$(DOMAIN).pot
-POFILES := $(LANGS:%=$(srcdir)/%.po)
-GMOFILES := $(LANGS:%=$(srcdir)/%.gmo)
+POTFILE := $(DOMAIN).pot
+POMINIFILES := $(LANGS:%=%.mini.po)
+POFILES := $(LANGS:%=%.po)
+GMOFILES := $(LANGS:%=%.gmo)
 
-MAINTAINERCLEANFILES = $(POTFILE) $(POFILES) $(GMOFILES)
+CLEANFILES = $(POTFILE) $(POFILES) $(GMOFILES)
 
 EXTRA_DIST = \
POTFILES \
-   $(POTFILE) \
-   $(POFILES) \
-   $(GMOFILES)
+   $(POMINIFILES)
 
 if HAVE_GNU_GETTEXT_TOOLS
 
@@ -63,10 +62,18 @@ update-mini-po: $(POTFILE)
done
 
 push-pot: $(POTFILE)
-   zanata push --push-type=source
+   zanata push \
+   --project-config $(srcdir)/zanata.xml \
+   --push-type=source \
+   --transdir $(builddir) \
+   --srcdir $(srcdir)
 
 pull-po: $(POTFILE)
-   zanata pull --create-skeletons
+   zanata pull \
+   --project-config $(srcdir)/zanata.xml \
+   --create-skeletons \
+   --transdir $(builddir) \
+   --srcdir $(srcdir)
$(MAKE) update-mini-po
$(MAKE) update-gmo
 
@@ -76,11 +83,11 @@ $(POTFILE): POTFILES $(POTFILE_DEPS)
$(SED) $(SED_PO_FIXUP_ARGS) < $@-t > $@
rm -f $@-t
 
-$(srcdir)/%.po: $(srcdir)/%.mini.po $(POTFILE)
+%.po: %.mini.po $(POTFILE)
$(MSGMERGE) --no-fuzzy-matching $< $(POTFILE) | \
  $(SED) $(SED_PO_FIXUP_ARGS) > $@
 
-$(srcdir)/%.gmo: $(srcdir)/%.po
+%.gmo: %.po
rm -f $@ $@-t
$(MSGFMT) -c -o $@-t $<
mv $@-t $@
@@ -99,7 +106,7 @@ install-data-hook: $(GMOFILES)
for lang in $(LANGS); do \
  d=$(DESTDIR)$(langinstdir)/$$lang/LC_MESSAGES; \
  mkdir -p $$d; \
- install -m 0644 $(srcdir)/$$lang.gmo $$d/$(DOMAIN).mo; \
+ install -m 0644 $$lang.gmo $$d/$(DOMAIN).mo; \
done
 
 uninstall-hook:
-- 
2.23.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list