[libvirt] snapshot: support rbd disk

Hello, Qemu support create snapshot for rbd disk. But Libvirt have not yet supported this feature now, is there any roadmap? Thanks. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v6 4/9] libxl: do not enable nested HVM unless global nested_hvm option enabled

On Wed, Mar 21, 2018 at 06:12:39PM -0600, Jim Fehlig wrote: > Ok. No need to send the whole series again. Just a followup to this patch > will do. Thanks! Just sent, but I've failed to connect it to this thread... It's marked as v6.1. -- Best Regards, Marek Marczykowski-Górecki Invisible Things

[libvirt] [PATCH v6.1 4/9] libxl: do not enable nested HVM unless global nested_hvm option enabled

Introduce global libxl option for enabling nested HVM feature, similar to kvm module parameter. This will prevent enabling experimental feature by mere presence of element in domain config, unless explicitly enabled. element may be used to configure other features, like NUMA, or CPUID.

Re: [libvirt] [PATCH v6 4/9] libxl: do not enable nested HVM unless global nested_hvm option enabled

On 03/21/2018 06:05 PM, Marek Marczykowski-Górecki wrote: On Wed, Mar 21, 2018 at 05:55:28PM -0600, Jim Fehlig wrote: On 03/21/2018 10:32 AM, Marek Marczykowski-Górecki wrote: Introduce global libxl option for enabling nested HVM feature, similar to kvm module parameter. This will prevent

Re: [libvirt] [PATCH v6 4/9] libxl: do not enable nested HVM unless global nested_hvm option enabled

On Wed, Mar 21, 2018 at 05:55:28PM -0600, Jim Fehlig wrote: > On 03/21/2018 10:32 AM, Marek Marczykowski-Górecki wrote: > > Introduce global libxl option for enabling nested HVM feature, similar > > to kvm module parameter. This will prevent enabling experimental feature > > by mere presence of

Re: [libvirt] [PATCH v6 4/9] libxl: do not enable nested HVM unless global nested_hvm option enabled

On 03/21/2018 10:32 AM, Marek Marczykowski-Górecki wrote: Introduce global libxl option for enabling nested HVM feature, similar to kvm module parameter. This will prevent enabling experimental feature by mere presence of element in domain config, unless explicitly enabled. element may be used

Re: [libvirt] [RFC PATCH 2/2] conf: Add VM Generation ID device

On 03/21/2018 03:19 AM, Peter Krempa wrote: > On Tue, Mar 20, 2018 at 18:55:44 -0400, John Ferlan wrote: >> Add VM Generation ID device XML schema, parse, format, and documentation. >> >> Signed-off-by: John Ferlan >> --- >> docs/formatdomain.html.in | 54

Re: [libvirt] [PATCH] news: Xen: announce removal of hard-code scheduler weight

On 03/21/2018 05:44 PM, Jim Fehlig wrote: > Also describe a possible side-affect due to changes in the default > (unspecified) value from 1000 to 256. > > Signed-off-by: Jim Fehlig > --- > docs/news.xml | 16 > 1 file changed, 16 insertions(+) >

Re: [libvirt] [PATCH] libxl: don't hardcode scheduler weight

On 03/02/2018 02:38 PM, John Ferlan wrote: On 02/22/2018 05:20 PM, Jim Fehlig wrote: Long ago in commit dfa1e1dd53 the scheduler weight was accidentally hardcoded to 1000. Weight is a setting with no unit since it is relative to the weight of other domains. If no weight is specified, libxl

[libvirt] [PATCH] news: Xen: announce removal of hard-code scheduler weight

Also describe a possible side-affect due to changes in the default (unspecified) value from 1000 to 256. Signed-off-by: Jim Fehlig --- docs/news.xml | 16 1 file changed, 16 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index 75a054308..93ab59cf4

[libvirt] [PATCH v4 1/5] security, apparmor: add (Set|Restore)MemoryLabel

Recent changes have made implementing this mandatory to hot add any memory. Implementing this in apparmor fixes this as well as allows hot-add of nvdimm tpye memory with an nvdimmPath set generating a AppArmor rule for that path. Example hot adding: /tmp/nvdimm-test

[libvirt] [PATCH v4 2/5] security, apparmor: add (Set|Restore)InputLabel

d8116b5a "security: Introduce functions for input device hot(un)plug" implemented the code (Set|Restore)InputLabel for several security modules, this patch adds an AppArmor implementation for it as well. That fixes hot-plugging event input devices by generating a rule for the path that needs to

[libvirt] [PATCH v4 0/5] Apparmor support for less common devices

So far users added manual rules for most of these uncommon devices, but recent changes made some of the callbacks mandatory for hotplug so we should take shot at implementing them as those callbacks as well as for the initial start of a guest via virt-aa-helper. *Updates since v1* -

[libvirt] [PATCH v4 5/5] virt-aa-helper: test: check for expected profile content

So far the virt-aa-helper tests only checked the return code and thereby catched aborts like issues failing to parse the XML. But there is one category of virt-aa-helper issues so far untested - not generating the expected rule. This adds a basic grep based checks after each test to match against

[libvirt] [PATCH v4 3/5] virt-aa-helper: generate rules for passthrough input devices

Input devices can passthrough an event device. This currently works only via hotplug where the AppArmor label is created via the domain label callbacks. This adds the virt-aa-helper support for passthrough input devices to generate rules for the needed paths from the initial guest definition as

[libvirt] [PATCH v4 4/5] virt-aa-helper: generate rules for nvdimm memory

nvdimm memory is backed by a path on the host. This currently works only via hotplug where the AppArmor label is created via the domain label callbacks. This adds the virt-aa-helper support for nvdimm memory devices to generate rules for the needed paths from the initial guest definition as well.

Re: [libvirt] [PATCH v3 5/5] virt-aa-helper: test: check for expected profile content

On Wed, Mar 21, 2018 at 7:59 PM, Jamie Strandboge wrote: > On Wed, 2018-03-21 at 15:53 +0100, Christian Ehrhardt wrote: > > So far the virt-aa-helper tests only checked the return code and > > thereby > > catched aborts like issues failing to parse the XML. But there is one

Re: [libvirt] [virt-tools-list] Project for profiles and defaults for libvirt domains

On Wed, Mar 21, 2018 at 06:39:52PM +, Daniel P. Berrangé wrote: > On Wed, Mar 21, 2018 at 03:00:41PM -0300, Eduardo Habkost wrote: > > On Tue, Mar 20, 2018 at 03:10:12PM +, Daniel P. Berrangé wrote: > > > On Tue, Mar 20, 2018 at 03:20:31PM +0100, Martin Kletzander wrote: > > > > 1) Default

Re: [libvirt] [PATCH v3 5/5] virt-aa-helper: test: check for expected profile content

On Wed, 2018-03-21 at 15:53 +0100, Christian Ehrhardt wrote: > So far the virt-aa-helper tests only checked the return code and > thereby > catched aborts like issues failing to parse the XML. But there is one > category of virt-aa-helper issues so far untested - not generating > the > expected

Re: [libvirt] [virt-tools-list] Project for profiles and defaults for libvirt domains

On Wed, Mar 21, 2018 at 03:00:41PM -0300, Eduardo Habkost wrote: > On Tue, Mar 20, 2018 at 03:10:12PM +, Daniel P. Berrangé wrote: > > On Tue, Mar 20, 2018 at 03:20:31PM +0100, Martin Kletzander wrote: > > > 1) Default devices/values > > > > > > Libvirt itself must default to whatever values

Re: [libvirt] [virt-tools-list] Project for profiles and defaults for libvirt domains

On Tue, Mar 20, 2018 at 03:10:12PM +, Daniel P. Berrangé wrote: > On Tue, Mar 20, 2018 at 03:20:31PM +0100, Martin Kletzander wrote: > > 1) Default devices/values > > > > Libvirt itself must default to whatever values there were before any > > particular element was introduced due to the fact

Re: [libvirt] [PATCH 0/2] virCommand: Two trivial fixes

On 03/21/2018 12:28 PM, Michal Privoznik wrote: > Although not pushed, so review appreciated. > > Michal Privoznik (2): > virCommandPassFD: Give name to flags > virCommandFDIsSet: Update documentation > > src/util/vircommand.c | 13 ++--- > src/util/vircommand.h | 4 ++-- > 2 files

Re: [libvirt] PCI passthrough/SR-IOV on Cavium cn889x

On 03/21/2018 11:46 AM, Ciprian Barbu wrote: > Hello, > > In the context of running Openstack on a cluster of Cavium ThunderX cn8890 > aarch64 servers, we are trying to attach virtual functions to a VM. > > First some introduction. This Cavium SoC has a different approach to Virtual > Functions

Re: [libvirt] [PATCH v3 4/5] virt-aa-helper: generate rules for nvdimm memory

On Wed, 2018-03-21 at 15:53 +0100, Christian Ehrhardt wrote: > nvdimm memory is backed by a path on the host. This currently works > only via > hotplug where the AppArmor label is created via the domain label > callbacks. > > This adds the virt-aa-helper support for nvdimm memory devices to >

Re: [libvirt] [PATCH v3 3/5] virt-aa-helper: generate rules for passthrough input devices

On Wed, 2018-03-21 at 15:53 +0100, Christian Ehrhardt wrote: > Input devices can passthrough an event device. This currently works > only via > hotplug where the AppArmor label is created via the domain label > callbacks. > > This adds the virt-aa-helper support for passthrough input devices to >

Re: [libvirt] [PATCH v3 2/5] security, apparmor: add (Set|Restore)InputLabel

On Wed, 2018-03-21 at 15:53 +0100, Christian Ehrhardt wrote: > d8116b5a "security: Introduce functions for input device hot(un)plug" > implemented the code (Set|Restore)InputLabel for several security > modules, > this patch adds an AppArmor implementation for it as well. > > That fixes

Re: [libvirt] [PATCH v3 1/5] security, apparmor: add (Set|Restore)MemoryLabel

On Wed, 2018-03-21 at 15:53 +0100, Christian Ehrhardt wrote: > Recent changes have made implementing this mandatory to hot add any > memory. > Implementing this in apparmor fixes this as well as allows hot-add of > nvdimm > tpye memory with an nvdimmPath set generating a AppArmor rule for > that >

Re: [libvirt] PCI passthrough/SR-IOV on Cavium cn889x

On Wed, 21 Mar 2018 15:46:01 + Ciprian Barbu wrote: > Hello, > > In the context of running Openstack on a cluster of Cavium ThunderX cn8890 > aarch64 servers, we are trying to attach virtual functions to a VM. > > First some introduction. This Cavium SoC has a

Re: [libvirt] [PATCH] travis: skip builds on -maint branches

On Wed, Mar 21, 2018 at 02:06:36PM +, Daniel P. Berrangé wrote: > For patches pushed upstream we want builds run on master branch, but > don't want them run on the -maint branches, as we are not keeping the > .travis.yml file on stable branches updated wrt latest needs of travis > CI

Re: [libvirt] [snmp PATCH 1/2] Replace U64 with struct counter64 to fix build

On 03/20/2018 09:41 AM, Michael Corcoran wrote: > Upstream net-snmp removed the U64 typedef in 2016 as it clashed with a > name in Perl, thus all usages of U64 must be replaced by struct counter64 to > compile against recent versions of net-snmp. > > The replacements were made by hand, while

Re: [libvirt] [snmp PATCH 2/2] Replace placeholder org OID with libvirt OID

On 03/20/2018 09:41 AM, Michael Corcoran wrote: > An OID of 36957 was assigned to libvirt by IANA, but the placeholder OID > of 12345 was never replaced. > > IANA lists the libvirt registration as: > 36957 > libvirt > Daniel Veillard > daniel > >

Re: [libvirt] [dbus PATCH v3 5/5] docs: rewrite HACKING and README into markdown format and improve it

On Wed, Mar 21, 2018 at 02:29:00PM +, Daniel P. Berrangé wrote: > On Wed, Mar 21, 2018 at 11:02:47AM +0100, Pavel Hrdina wrote: > > Signed-off-by: Pavel Hrdina > > --- > > HACKING | 199 > > > > HACKING.md

[libvirt] [PATCH v6 8/9] xenconfig: add CPUID handling to domXML <-> xl.cfg conversion

Only "libxl" format supported for now. Special care needed around vmx/svm, because those two are translated into "nestedhvm" setting. Signed-off-by: Marek Marczykowski-Górecki --- Changes since v5: - adjust for ignoring mode=custom instead of rejecting it

[libvirt] [PATCH v6 4/9] libxl: do not enable nested HVM unless global nested_hvm option enabled

Introduce global libxl option for enabling nested HVM feature, similar to kvm module parameter. This will prevent enabling experimental feature by mere presence of element in domain config, unless explicitly enabled. element may be used to configure other features, like NUMA, or CPUID.

[libvirt] [PATCH v6 0/9] Add setting CPU features (CPUID) with libxenlight driver.

Add support for CPUID setting based on element. Since libxl format support only adjusting specific bits over host CPU, only mode='host-passthrough' is supported - other values are rejected (including default 'custom'). This will break some configurations working before (bare element with for

[libvirt] [PATCH v6 6/9] libxl: add support for CPUID features policy

Convert CPU features policy into libxl cpuid policy settings. Use new ("libxl") syntax, which allow to enable/disable specific bits, using host CPU as a base. For this reason, only "host-passthrough" mode is accepted. Libxl do not have distinction between "force" and "required" policy (there is

[libvirt] [PATCH v6 1/9] libxl: fix libxlDriverConfigDispose for partially constructed object

libxlDriverConfigNew() use libxlDriverConfigDispose() for cleanup in case of errors. Do not call libxlLoggerFree() on not allocated logger (NULL). Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Jim Fehlig Reviewed-by: Daniel P. Berrangé

[libvirt] [PATCH v6 3/9] libxl: warn about ignored CPU mode=custom

When support for mode=custom will be added in the future, semantics of current config will change. Reduce the surprise by emitting a warning. Signed-off-by: Marek Marczykowski-Górecki --- Changes since v5: - new patch, instead of "libxl: error out on not

[libvirt] [PATCH v6 2/9] libxl: pass driver config to libxlMakeDomBuildInfo

Preparation for global nestedhvm configuration - libxlMakeDomBuildInfo needs access to libxlDriverConfig. No functional change. Adjusting tests require slightly more mockup functions, because of libxlDriverConfigNew() call. Signed-off-by: Marek Marczykowski-Górecki

[libvirt] [PATCH v6 5/9] xenconfig: do not override def->cpu if already set elsewhere

This will help with adding cpuid support. Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Daniel P. Berrangé --- Changes since v4: - patch separated from "libxl: do not enable nested HVM unless global nested_hvm option enabled"

[libvirt] [PATCH v6 7/9] tests: check CPU features handling in libxl driver

Test enabling/disabling individual CPU features and also setting nested HVM support, which is also controlled by CPU features node. Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Jim Fehlig --- Changes since v3: - adjust for modified

[libvirt] [PATCH v6 9/9] tests: add test case for CPUID in xenconfig driver

Check conversion of "cpuid" setting, check all supported policy settings ("1", "0", "x"). Also, check interaction with "nestedhvm" - should not be included as "vmx=1" in "cpuid" setting. Signed-off-by: Marek Marczykowski-Górecki Reviewed-by: Jim Fehlig

[libvirt] [PATCH 2/2] virCommandFDIsSet: Update documentation

The set of arguments was changed a long time ago (040d9963420 which dates back to July 2013) but the corresponding documentation was not updated. Signed-off-by: Michal Privoznik --- src/util/vircommand.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff

[libvirt] [PATCH 0/2] virCommand: Two trivial fixes

Although not pushed, so review appreciated. Michal Privoznik (2): virCommandPassFD: Give name to flags virCommandFDIsSet: Update documentation src/util/vircommand.c | 13 ++--- src/util/vircommand.h | 4 ++-- 2 files changed, 8 insertions(+), 9 deletions(-) -- 2.16.1 --

[libvirt] [PATCH 1/2] virCommandPassFD: Give name to flags

The flags passed to virCommandPassFD() are unnamed and documentation to this function doesn't list them either. Give them name and mention it in documentation to functions using them. Signed-off-by: Michal Privoznik --- src/util/vircommand.c | 8

Re: [libvirt] [dbus PATCH v3 1/5] introduce support for GDBus implementation

On Wed, Mar 21, 2018 at 02:21:05PM +, Daniel P. Berrangé wrote: > On Wed, Mar 21, 2018 at 11:02:43AM +0100, Pavel Hrdina wrote: > > We will switch to GDBus implementation of D-Bus protocol because > > sd-bus implementation is not thread safe. > > > > Processing messages in threads is

[libvirt] [PATCH 0/4] Be consistent with vir*Obj*Remove* APIs

Using comments from recent changes/reviews w/ libxl and usage of the virDomainObjListRemove which note that it's "a problem" that the Remove API expects a locked @obj on input, but then returns the @obj unlocked. Although adjusting domainobjlist is a "future" task, we can at least modify the

[libvirt] [PATCH 4/4] storagepool: Return with locked obj from virStoragePoolObjRemove

Rather than unlock the object that was expected to be locked on input, let the caller perform the unlock or more succinctly a virStoragePoolObjEndAPI on the object which will perform the Unref and Unlock and clear the @obj. Also add comments for virStoragePoolObjRemove. Signed-off-by: John

[libvirt] [PATCH 3/4] nodedev: Return with locked obj from virNodeDeviceObjListRemove

Rather than unlock the object that was expected to be locked on input, let the caller perform the unlock or more succinctly a virNodeDeviceObjEndAPI on the object which will perform the Unref and Unlock and clear the @obj. Also add comments for virNodeDeviceObjListRemove. Signed-off-by: John

[libvirt] [PATCH 2/4] interface: Return with locked obj from virInterfaceObjListRemove

Rather than unlock the object that was expected to be locked on input, let the caller perform the unlock or more succinctly a virInterfaceObjEndAPI on the object which will perform the Unref and Unlock and clear the @obj. Also add comments to the virInterfaceObjListRemove. Signed-off-by: John

[libvirt] [PATCH 1/4] secret: Return with locked obj from virSecretObjListRemove

Rather than unlock the object that was expected to be locked on input, let the caller perform the unlock or more succinctly a virSecretObjEndAPI on the object which will perform the Unref and Unlock and clear the @obj. Also clean up the virSecretObjListRemove function comments. Signed-off-by:

[libvirt] PCI passthrough/SR-IOV on Cavium cn889x

Hello, In the context of running Openstack on a cluster of Cavium ThunderX cn8890 aarch64 servers, we are trying to attach virtual functions to a VM. First some introduction. This Cavium SoC has a different approach to Virtual Functions than on x86 NICs, in which VFs are always enabled and

Re: [libvirt] [jenkins-ci PATCH 4/3] guests: Remove ad-hoc package installation

On Wed, Mar 21, 2018 at 04:17:48PM +0100, Andrea Bolognani wrote: > On Wed, 2018-03-21 at 16:03 +0100, Pavel Hrdina wrote: > > > -# Prepare the base environment > > > +# Prepare environment. None of the actions performed here might > > > +# depend on packages being installed > > >

Re: [libvirt] [jenkins-ci PATCH 2/3] guests: Don't expose 'jenkins' pseudo-package

On Wed, Mar 21, 2018 at 04:12:09PM +0100, Andrea Bolognani wrote: > On Wed, 2018-03-21 at 15:56 +0100, Pavel Hrdina wrote: > > > +# Install packages needed for the Jenkins agent > > > +- include: tasks/packages.yml > > > + vars: > > > +project: jenkins > > > + when: > > >

Re: [libvirt] [jenkins-ci PATCH 7/3] guests: Only enable jessie-backports for 'jenkins' flavor

On Wed, Mar 21, 2018 at 01:20:00PM +0100, Andrea Bolognani wrote: > We only need jessie-backports for the JDK, and we only need the > JDK for the Jenkins agent. > > Signed-off-by: Andrea Bolognani > --- > guests/tasks/base.yml | 2 ++ > 1 file changed, 2 insertions(+)

Re: [libvirt] [jenkins-ci PATCH 4/3] guests: Remove ad-hoc package installation

On Wed, 2018-03-21 at 16:03 +0100, Pavel Hrdina wrote: > > -# Prepare the base environment > > +# Prepare environment. None of the actions performed here might > > +# depend on packages being installed > > - include: tasks/base.yml > > - include: tasks/compat.yml > > --

Re: [libvirt] [jenkins-ci PATCH 6/3] guests: Implement package blacklist

On Wed, Mar 21, 2018 at 01:19:59PM +0100, Andrea Bolognani wrote: > As with ad-hoc installation, we want to get rid of ad-hoc package > removal. Add a 'blacklist' pseudo-project which can be used for > the purpose. > > In the future, we might use this facility to keep long-lived > guests clean by

Re: [libvirt] [jenkins-ci PATCH 9/3] guests: Move bootloader configuration to its own task

On Wed, Mar 21, 2018 at 01:20:02PM +0100, Andrea Bolognani wrote: > There are enough bootloader tweaks that splitting them off to > a separate task makes sense. > > Signed-off-by: Andrea Bolognani > --- > guests/site.yml | 1 + > guests/tasks/base.yml |

Re: [libvirt] [jenkins-ci PATCH 8/3] guests: Centralize user creation and configuration

On Wed, Mar 21, 2018 at 01:20:01PM +0100, Andrea Bolognani wrote: > We already have a separate task for creating the non-root user, > so it makes sense to move everything related to the root user to > that taks as well. > > Signed-off-by: Andrea Bolognani > --- >

Re: [libvirt] [jenkins-ci PATCH 2/3] guests: Don't expose 'jenkins' pseudo-package

On Wed, 2018-03-21 at 15:56 +0100, Pavel Hrdina wrote: > > +# Install packages needed for the Jenkins agent > > +- include: tasks/packages.yml > > + vars: > > +project: jenkins > > + when: > > +- flavor == "jenkins" > > + > > # Configure the Jenkins agent > >

Re: [libvirt] persistence of pcihole64 over live migration

On Tue, Mar 20, 2018 at 20:34:37 +, Richard, Joseph wrote: > Hello all, > > In order to reserve 64-bit address space for hotplugging, we are using the > pcihole64 attribute on the root pci-controller. > When doing a live-migration using libvirt/qemu, the pci-root controller is > dropped and

Re: [libvirt] [jenkins-ci PATCH 1/3] guests: Configure Jenkins agent based on secret availability

On Wed, Mar 21, 2018 at 04:08:26PM +0100, Andrea Bolognani wrote: > On Wed, 2018-03-21 at 15:52 +0100, Pavel Hrdina wrote: > > > - name: Enable Jenkins agent > > > @@ -39,4 +45,5 @@ > > > enabled: yes > > > daemon_reload: yes > > >when: > > > +- jenkins_secret is defined > > >

Re: [libvirt] [jenkins-ci PATCH 1/3] guests: Configure Jenkins agent based on secret availability

On Wed, 2018-03-21 at 15:52 +0100, Pavel Hrdina wrote: > > - name: Enable Jenkins agent > > @@ -39,4 +45,5 @@ > > enabled: yes > > daemon_reload: yes > >when: > > +- jenkins_secret is defined > > - ansible_service_mgr == 'systemd' > > Would it be possible to create a group

Re: [libvirt] [jenkins-ci PATCH 5/3] guests: Add support for removing packages

On Wed, Mar 21, 2018 at 01:19:58PM +0100, Andrea Bolognani wrote: > Signed-off-by: Andrea Bolognani > --- > guests/tasks/packages.yml | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Reviewed-by: Pavel Hrdina signature.asc

Re: [libvirt] [jenkins-ci PATCH 4/3] guests: Remove ad-hoc package installation

On Wed, Mar 21, 2018 at 01:19:57PM +0100, Andrea Bolognani wrote: > There is a small number of packages that we install as part of > the 'base' task with an ad-hoc call to the package module. > > Since we have generic facilities for installing packages and a > generic 'base' pseudo-project that

Re: [libvirt] [jenkins-ci PATCH 3/3] guests: Don't expose 'base' pseudo-package

On Tue, Mar 20, 2018 at 05:24:00PM +0100, Andrea Bolognani wrote: > The 'base' pseudo-package is an implementation detail, and as > such is better not exposed. > > Signed-off-by: Andrea Bolognani > --- > guests/host_vars/libvirt-centos-6/main.yml| 1 - >

Re: [libvirt] [jenkins-ci PATCH 2/3] guests: Don't expose 'jenkins' pseudo-package

On Tue, Mar 20, 2018 at 05:23:59PM +0100, Andrea Bolognani wrote: > The 'jenkins' pseudo-package is an implementation detail, and > as such is better not exposed. > > Moreover, with this change the JDK will only be installed when > the 'jenkins' flavor is used, which means developers will have >

[libvirt] [PATCH v3 0/5] Apparmor support for less common devices

So far users added manual rules for most of these uncommon devices, but recent changes made some of the callbacks mandatory for hotplug so we should take shot at implementing them as those callbacks as well as for the initial start of a guest via virt-aa-helper. *Updates since v1* -

[libvirt] [PATCH v3 3/5] virt-aa-helper: generate rules for passthrough input devices

Input devices can passthrough an event device. This currently works only via hotplug where the AppArmor label is created via the domain label callbacks. This adds the virt-aa-helper support for passthrough input devices to generate rules for the needed paths from the initial guest definition as

[libvirt] [PATCH v3 5/5] virt-aa-helper: test: check for expected profile content

So far the virt-aa-helper tests only checked the return code and thereby catched aborts like issues failing to parse the XML. But there is one category of virt-aa-helper issues so far untested - not generating the expected rule. This adds a basic grep based checks after each test to match against

[libvirt] [PATCH v3 1/5] security, apparmor: add (Set|Restore)MemoryLabel

Recent changes have made implementing this mandatory to hot add any memory. Implementing this in apparmor fixes this as well as allows hot-add of nvdimm tpye memory with an nvdimmPath set generating a AppArmor rule for that path. Example hot adding: /tmp/nvdimm-test

[libvirt] [PATCH v3 4/5] virt-aa-helper: generate rules for nvdimm memory

nvdimm memory is backed by a path on the host. This currently works only via hotplug where the AppArmor label is created via the domain label callbacks. This adds the virt-aa-helper support for nvdimm memory devices to generate rules for the needed paths from the initial guest definition as well.

[libvirt] [PATCH v3 2/5] security, apparmor: add (Set|Restore)InputLabel

d8116b5a "security: Introduce functions for input device hot(un)plug" implemented the code (Set|Restore)InputLabel for several security modules, this patch adds an AppArmor implementation for it as well. That fixes hot-plugging event input devices by generating a rule for the path that needs to

[libvirt] persistence of pcihole64 over live migration

Hello all, In order to reserve 64-bit address space for hotplugging, we are using the pcihole64 attribute on the root pci-controller. When doing a live-migration using libvirt/qemu, the pci-root controller is dropped and re-added on the destination side[1], which results in the pci

Re: [libvirt] [jenkins-ci PATCH 1/3] guests: Configure Jenkins agent based on secret availability

On Tue, Mar 20, 2018 at 05:23:58PM +0100, Andrea Bolognani wrote: > We're going to remove the 'jenkins' pseudo-project from the list > of per-guest projects soon, so we need another way of deciding > whether to install and configure the Jenkins agent. > > The availability of the Jenkins secret in

Re: [libvirt] [dbus PATCH v3 5/5] docs: rewrite HACKING and README into markdown format and improve it

On Wed, Mar 21, 2018 at 11:02:47AM +0100, Pavel Hrdina wrote: > Signed-off-by: Pavel Hrdina > --- > HACKING | 199 > > HACKING.md | 191 + > Makefile.am

Re: [libvirt] [PATCH v2 2/5] security, apparmor: add (Set|Restore)InputLabel

On Wed, Mar 21, 2018 at 3:23 PM, Christian Ehrhardt < christian.ehrha...@canonical.com> wrote: > > > On Wed, Mar 21, 2018 at 3:03 PM, Jamie Strandboge > wrote: > >> On Wed, 2018-03-21 at 13:10 +0100, Christian Ehrhardt wrote: >> > d8116b5a "security: Introduce functions for

Re: [libvirt] [PATCH v2 2/5] security, apparmor: add (Set|Restore)InputLabel

On Wed, Mar 21, 2018 at 3:03 PM, Jamie Strandboge wrote: > On Wed, 2018-03-21 at 13:10 +0100, Christian Ehrhardt wrote: > > d8116b5a "security: Introduce functions for input device hot(un)plug" > > implemented the code (Set|Restore)InputLabel for several security > >

Re: [libvirt] [dbus PATCH v3 4/5] main: introduce thread pool to process D-Bus messages

On Wed, Mar 21, 2018 at 11:02:46AM +0100, Pavel Hrdina wrote: > The default thread count is currently 4 and it is also configurable > via --threads/-t paramter for the libvirt-dbus daemon. > > Signed-off-by: Pavel Hrdina > --- > src/connect.c | 4 +++ > src/connect.h | 1 +

Re: [libvirt] [dbus PATCH v3 3/5] switch from sd-bus to GDBus implementation

On Wed, Mar 21, 2018 at 11:02:45AM +0100, Pavel Hrdina wrote: > This removes all the sd-bus code and uses GDBus instead. > > Signed-off-by: Pavel Hrdina > --- > > Changes in v3: > - domain property Id is handled correctly for offline domains > > README

Re: [libvirt] [dbus PATCH v3 2/5] introduce run script to execute libvirt-dbus daemon

On Wed, Mar 21, 2018 at 11:02:44AM +0100, Pavel Hrdina wrote: > The GDBus implementation requires XML files with interface description > and libvirt-dbus daemon needs to load them. > > In order to run the daemon without installing it you can use the run > script to configure the environment

Re: [libvirt] [PATCH 3/3] util: introduce virSocketAddrParseQuiet

On 03/19/2018 07:28 PM, Jim Fehlig wrote: > When preparing for migration, the libxl driver creates a new TCP listen > socket for the incoming migration by calling virNetSocketNewListenTCP, > passing the destination host name. virNetSocketNewListenTCP calls > virSocketAddrParse to check if the

Re: [libvirt] [dbus PATCH v3 1/5] introduce support for GDBus implementation

On Wed, Mar 21, 2018 at 11:02:43AM +0100, Pavel Hrdina wrote: > We will switch to GDBus implementation of D-Bus protocol because > sd-bus implementation is not thread safe. > > Processing messages in threads is essential since Libvirt API can > take some significant amount of time to return and

Re: [libvirt] [PATCH v2 1/5] security, apparmor: add (Set|Restore)MemoryLabel

On Wed, Mar 21, 2018 at 3:02 PM, Jamie Strandboge wrote: > On Wed, 2018-03-21 at 13:10 +0100, Christian Ehrhardt wrote: > > Recent changes have made implementing this mandatory to hot add any > > memory. > > Implementing this in apparmor fixes this as well as allows hot-add

Re: [libvirt] [PATCH v2 4/5] virt-aa-helper: generate rules for nvdimm memory

On Wed, 2018-03-21 at 13:10 +0100, Christian Ehrhardt wrote: > nvdimm memory is backed by a path on the host. This currently works > only via > hotplug where the AppArmor label is created via the domain label > callbacks. > > This adds the virt-aa-helper support for nvdimm memory devices to >

Re: [libvirt] [PATCH v2 3/5] virt-aa-helper: generate rules for passthrough input devices

On Wed, 2018-03-21 at 13:10 +0100, Christian Ehrhardt wrote: > Input devices can passthrough an event device. This currently works > only via > hotplug where the AppArmor label is created via the domain label > callbacks. > > This adds the virt-aa-helper support for passthrough input devices to >

[libvirt] [PATCH] travis: skip builds on -maint branches

For patches pushed upstream we want builds run on master branch, but don't want them run on the -maint branches, as we are not keeping the .travis.yml file on stable branches updated wrt latest needs of travis CI platforms. We can't just whitelist 'master' though, because that will prevent

Re: [libvirt] [PATCH v2 2/5] security, apparmor: add (Set|Restore)InputLabel

On Wed, 2018-03-21 at 13:10 +0100, Christian Ehrhardt wrote: > d8116b5a "security: Introduce functions for input device hot(un)plug" > implemented the code (Set|Restore)InputLabel for several security > modules, > this patch adds an AppArmor implementation for it as well. > > That fixes

Re: [libvirt] [PATCH v2 1/5] security, apparmor: add (Set|Restore)MemoryLabel

On Wed, 2018-03-21 at 13:10 +0100, Christian Ehrhardt wrote: > Recent changes have made implementing this mandatory to hot add any > memory. > Implementing this in apparmor fixes this as well as allows hot-add of > nvdimm > tpye memory with an nvdimmPath set generating a AppArmor rule for > that >

Re: [libvirt] [PATCH 2/3] libxl: remove needless 'else' in libxlDomainMigrationPrepare

On 03/19/2018 07:28 PM, Jim Fehlig wrote: > Signed-off-by: Jim Fehlig > --- > src/libxl/libxl_migration.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: John Ferlan John -- libvir-list mailing list libvir-list@redhat.com

Re: [libvirt] [PATCH 1/3] libxl: dont dereference NULL libxlDomainObjPrivatePtr

On 03/19/2018 07:28 PM, Jim Fehlig wrote: > In libxlDomainMigrationPrepare it is possible to dereference a NULL > libxlDomainObjPrivatePtr in early error paths. Check for a valid > 'priv' before using it. > > Signed-off-by: Jim Fehlig > --- > src/libxl/libxl_migration.c | 7

Re: [libvirt] [PATCH 2/8] tests: Add capabilities data for QEMU 2.12

On Wed, Mar 21, 2018 at 02:03:18PM +0100, Andrea Bolognani wrote: > On Wed, 2018-03-21 at 07:34 -0400, John Ferlan wrote: > > > > > create mode 100644 > > > > > tests/qemucapabilitiesdata/caps_2.12.0-gicv2.aarch64.replies > > > > > create mode 100644 > > > > >

Re: [libvirt] [PATCH 2/8] tests: Add capabilities data for QEMU 2.12

On 03/21/2018 09:03 AM, Andrea Bolognani wrote: > On Wed, 2018-03-21 at 07:34 -0400, John Ferlan wrote: > create mode 100644 > tests/qemucapabilitiesdata/caps_2.12.0-gicv2.aarch64.replies > create mode 100644 > tests/qemucapabilitiesdata/caps_2.12.0-gicv3.aarch64.replies

Re: [libvirt] [PATCH] rpm: fix incorrect expansion of %systemd_preun macro

On 03/21/2018 05:55 AM, Daniel P. Berrangé wrote: > On Tue, Mar 20, 2018 at 01:54:49PM -0400, Laine Stump wrote: >> On 03/20/2018 01:00 PM, Daniel P. Berrangé wrote: >>> Macros in RPMs are expanded before line continuations, so when we write >>> >>>%systemd_preun foo \ >>>

Re: [libvirt] [PATCH 2/8] tests: Add capabilities data for QEMU 2.12

On Wed, 2018-03-21 at 07:34 -0400, John Ferlan wrote: > > > > create mode 100644 > > > > tests/qemucapabilitiesdata/caps_2.12.0-gicv2.aarch64.replies > > > > create mode 100644 > > > > tests/qemucapabilitiesdata/caps_2.12.0-gicv3.aarch64.replies > > > > create mode 100644

[libvirt] Libvirt-4.1.0 build fails at the 'make install' linking stage with 4.0.0 installed

Hi. When I try to build Libvirt-4.1.0 on a system that has 4.0.0 installed, the build fails at the 'make install' linking stage with the error below. Same thing happened with git master I tried (commit 43523d7421, haven't tried with the latest one yet) and rebuilding 4.0.0 works fine. 4.1.0

[libvirt] [jenkins-ci PATCH 7/3] guests: Only enable jessie-backports for 'jenkins' flavor

We only need jessie-backports for the JDK, and we only need the JDK for the Jenkins agent. Signed-off-by: Andrea Bolognani --- guests/tasks/base.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/guests/tasks/base.yml b/guests/tasks/base.yml index 0c82b58..debf6e4

[libvirt] [jenkins-ci PATCH 4/3] guests: Remove ad-hoc package installation

There is a small number of packages that we install as part of the 'base' task with an ad-hoc call to the package module. Since we have generic facilities for installing packages and a generic 'base' pseudo-project that we use for all packages that are not related to any specific project, we can

[libvirt] [jenkins-ci PATCH 8/3] guests: Centralize user creation and configuration

We already have a separate task for creating the non-root user, so it makes sense to move everything related to the root user to that taks as well. Signed-off-by: Andrea Bolognani --- guests/site.yml | 2 +- guests/tasks/base.yml| 20

[libvirt] [jenkins-ci PATCH 6/3] guests: Implement package blacklist

As with ad-hoc installation, we want to get rid of ad-hoc package removal. Add a 'blacklist' pseudo-project which can be used for the purpose. In the future, we might use this facility to keep long-lived guests clean by blacklisting packages as they get dropped from the respective project.

  1   2   >