[libvirt] [PATCH 0/3] network: Add support for local PTR domains
by Jiri Denemark
I run a system dnsmasq to be able to forward specific DNS requests to
specific servers. And I have it configured for both forward and reverse
lookups. Another dnsmasq is started for a virtual network with domain
"virt". The system dnsmasq knows it needs to forward any requests for
the "virt" domain and corresponding PTR domain to the dnsmasq started by
libvirt. The problem is dnsmasq forwards queries for unknown names to
the upstream name server (which is the system instance in my case). One
can get nice endless loops of DNS requests pretty easily. Forward loops
can be avoided by specifying localOnly='yes', but there was no way to
avoid reverse lookup loops. And this is what I'm trying to address in
the following patches.
Jiri Denemark (3):
conf: Make virNetworkIPDefParseXML a little bit saner
util: Introduce virSocketAddrPTRDomain
network: Add support for local PTR domains
docs/formatnetwork.html.in | 37 ++++++--
src/conf/network_conf.c | 108 +++++++++++++++++++-----
src/conf/network_conf.h | 4 +
src/libvirt_private.syms | 1 +
src/network/bridge_driver.c | 47 +++++++++++
src/util/virsocketaddr.c | 85 +++++++++++++++++++
src/util/virsocketaddr.h | 9 ++
tests/networkxml2confdata/ptr-domains-auto.conf | 20 +++++
tests/networkxml2confdata/ptr-domains-auto.xml | 21 +++++
tests/networkxml2confdata/ptr-domains.conf | 24 ++++++
tests/networkxml2confdata/ptr-domains.xml | 24 ++++++
tests/networkxml2conftest.c | 2 +
12 files changed, 353 insertions(+), 29 deletions(-)
create mode 100644 tests/networkxml2confdata/ptr-domains-auto.conf
create mode 100644 tests/networkxml2confdata/ptr-domains-auto.xml
create mode 100644 tests/networkxml2confdata/ptr-domains.conf
create mode 100644 tests/networkxml2confdata/ptr-domains.xml
--
2.11.0
7 years, 10 months
[libvirt] [libvirt-ci][PATCH] Remove builders for Centos 6
by Michal Privoznik
These builds often fails with false positives due to ancient
compiler found on this system. For instance it fails to see when
symbol is used as a variable and when it is used as a function
producing the following warnings:
../../src/qemu/qemu_monitor_text.c: In function 'parseMemoryStat':
../../src/qemu/qemu_monitor_text.c:604: error: declaration of 'stat' shadows a global declaration [-Wshadow]
/usr/include/sys/stat.h:455: error: shadowed declaration is here [-Wshadow]
Users trying to use libvirt from git on stable system are doomed
to fix it themselves.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
projects/libvirt-cim.yaml | 1 -
projects/libvirt-python.yaml | 1 -
projects/libvirt.yaml | 3 ---
3 files changed, 5 deletions(-)
diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml
index d1705af..dd40eb1 100644
--- a/projects/libvirt-cim.yaml
+++ b/projects/libvirt-cim.yaml
@@ -2,7 +2,6 @@
- project:
name: libvirt-cim
machines:
- - libvirt-centos-6
- libvirt-centos-7
- libvirt-fedora-23
- libvirt-fedora-24
diff --git a/projects/libvirt-python.yaml b/projects/libvirt-python.yaml
index baca308..adf22f4 100644
--- a/projects/libvirt-python.yaml
+++ b/projects/libvirt-python.yaml
@@ -2,7 +2,6 @@
- project:
name: libvirt-python
machines:
- - libvirt-centos-6
- libvirt-centos-7
- libvirt-fedora-23
- libvirt-fedora-24
diff --git a/projects/libvirt.yaml b/projects/libvirt.yaml
index 20de27c..2b4e5d3 100644
--- a/projects/libvirt.yaml
+++ b/projects/libvirt.yaml
@@ -2,7 +2,6 @@
- project:
name: libvirt
machines:
- - libvirt-centos-6
- libvirt-centos-7
- libvirt-fedora-23
- libvirt-fedora-24
@@ -13,7 +12,6 @@
- autotools-build-job:
parent_jobs:
machines:
- - libvirt-centos-6
- libvirt-centos-7
- libvirt-debian
- libvirt-fedora-23
@@ -23,7 +21,6 @@
- autotools-syntax-check-job:
parent_jobs: 'libvirt-master-build'
machines:
- - libvirt-centos-6
- libvirt-centos-7
- libvirt-debian
- libvirt-fedora-23
--
2.11.0
7 years, 10 months
[libvirt] [libvirt-perl][PATCH] Add PERF_PARAM_BRANCH_MISSES constant
by Michal Privoznik
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Changes | 1 +
Virt.xs | 1 +
lib/Sys/Virt/Domain.pm | 7 +++++++
3 files changed, 9 insertions(+)
diff --git a/Changes b/Changes
index b1248c9..ffb1911 100644
--- a/Changes
+++ b/Changes
@@ -4,6 +4,7 @@ Revision history for perl module Sys::Virt
- Add group_name for block iotune
- Add new branch instructions perf event
+ - Add PERF_PARAM_BRANCH_MISSES constant
2.5.0 2016-12-05
diff --git a/Virt.xs b/Virt.xs
index b081793..65f4975 100644
--- a/Virt.xs
+++ b/Virt.xs
@@ -8302,6 +8302,7 @@ BOOT:
REGISTER_CONSTANT_STR(VIR_PERF_PARAM_CPU_CYCLES, PERF_PARAM_CPU_CYCLES);
REGISTER_CONSTANT_STR(VIR_PERF_PARAM_INSTRUCTIONS, PERF_PARAM_INSTRUCTIONS);
REGISTER_CONSTANT_STR(VIR_PERF_PARAM_BRANCH_INSTRUCTIONS, PERF_PARAM_BRANCH_INSTRUCTIONS);
+ REGISTER_CONSTANT_STR(VIR_PERF_PARAM_BRANCH_MISSES, PERF_PARAM_BRANCH_MISSES);
REGISTER_CONSTANT_STR(VIR_DOMAIN_BANDWIDTH_IN_AVERAGE, BANDWIDTH_IN_AVERAGE);
REGISTER_CONSTANT_STR(VIR_DOMAIN_BANDWIDTH_IN_PEAK, BANDWIDTH_IN_PEAK);
diff --git a/lib/Sys/Virt/Domain.pm b/lib/Sys/Virt/Domain.pm
index faacc0a..3d9b106 100644
--- a/lib/Sys/Virt/Domain.pm
+++ b/lib/Sys/Virt/Domain.pm
@@ -2776,6 +2776,13 @@ the count of instructions by applications running on the
platform. It corresponds to the "perf.branch_instructions" field in the
*Stats APIs.
+=item Sys::Virt::Domain::PERF_PARAM_BRANCH_MISSES
+
+The branch_misses perf event which can be used to measure the
+count of branch misses by applications running on the platform.
+It corresponds to the "perf.branch_misses" field in the *Stats
+APIs.
+
=back
=head2 VCPU FLAGS
--
2.11.0
7 years, 10 months
[libvirt] [PATCH] formatnetwork: Cleanup /network/ip documentation
by Jiri Denemark
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
docs/formatnetwork.html.in | 125 ++++++++++++++++++++++-----------------------
1 file changed, 60 insertions(+), 65 deletions(-)
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index cc7d7c7e7..9cf940052 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -968,49 +968,44 @@
</dd>
<dt><code>ip</code></dt>
<dd>The <code>address</code> attribute defines an IPv4 address in
- dotted-decimal format, or an IPv6 address in standard
- colon-separated hexadecimal format, that will be configured on
- the bridge
- device associated with the virtual network. To the guests this IPv4
- address will be their IPv4 default route. For IPv6, the default route is
- established via Router Advertisement.
- For IPv4 addresses, the <code>netmask</code>
- attribute defines the significant bits of the network address,
- again specified in dotted-decimal format. For IPv6 addresses,
- and as an alternate method for IPv4 addresses, you can specify
- the significant bits of the network address with the <code>prefix</code>
- attribute, which is an integer (for example, <code>netmask='255.255.255.0'</code>
- could also be given as <code>prefix='24'</code>. The <code>family</code>
- attribute is used to specify the type of address - 'ipv4' or 'ipv6'; if no
- <code>family</code> is given, 'ipv4' is assumed. A network can have more than
- one of each family of address defined, but only a single IPv4 address can have a
- <code>dhcp</code> or <code>tftp</code> element. <span class="since">Since 0.3.0 </span>
- IPv6, multiple addresses on a single network, <code>family</code>, and
- <code>prefix</code> are support <span class="since">Since 0.8.7</span>.
- Similar to IPv4, one IPv6 address per network can also have
- a <code>dhcp</code> definition. <span class="since">Since 1.0.1</span>
+ dotted-decimal format, or an IPv6 address in standard colon-separated
+ hexadecimal format, that will be configured on the bridge device
+ associated with the virtual network. To the guests this IPv4 address
+ will be their IPv4 default route. For IPv6, the default route is
+ established via Router Advertisement. For IPv4 addresses, the
+ <code>netmask</code> attribute defines the significant bits of the
+ network address, again specified in dotted-decimal format. For IPv6
+ addresses, and as an alternate method for IPv4 addresses, the
+ significant bits of the network address can be specified with the
+ <code>prefix</code> attribute, which is an integer (for example,
+ <code>netmask='255.255.255.0'</code> could also be given as
+ <code>prefix='24'</code>). The <code>family</code> attribute is used
+ to specify the type of address — <code>ipv4</code> or
+ <code>ipv6</code>; if no <code>family</code> is given,
+ <code>ipv4</code> is assumed. More than one address of each family can
+ be defined for a network. The <code>ip</code> element is supported
+ <span class="since">since 0.3.0</span>. IPv6, multiple addresses on a
+ single network, <code>family</code>, and <code>prefix</code> are
+ supported <span class="since">since 0.8.7</span>. The <code>ip</code>
+ element may contain the following elements:
<dl>
<dt><code>tftp</code></dt>
- <dd>Immediately within
- the <code>ip</code> element there is an optional <code>tftp</code>
- element. The presence of this element and of its attribute
- <code>root</code> enables TFTP services. The attribute specifies
- the path to the root directory served via TFTP. <code>tftp</code> is not
- supported for IPv6 addresses, and can only be specified on a single IPv4 address
- per network.
+ <dd>The optional <code>tftp</code> element and its mandatory
+ <code>root</code> attribute enable TFTP services. The attribute
+ specifies the path to the root directory served via TFTP. The
+ <code>tftp</code> element is not supported for IPv6 addresses,
+ and can only be specified on a single IPv4 address per network.
<span class="since">Since 0.7.1</span>
</dd>
<dt><code>dhcp</code></dt>
- <dd>Also within the <code>ip</code> element there is an
- optional <code>dhcp</code> element. The presence of this element
- enables DHCP services on the virtual network. It will further
- contain one or more <code>range</code> elements. The
- <code>dhcp</code> element supported for both
- IPv4 <span class="since">Since 0.3.0</span>
- and IPv6 <span class="since">Since 1.0.1</span>, but
- only for one IP address of each type per network.
+ <dd>The presence of this element enables DHCP services on the
+ virtual network. The <code>dhcp</code> element is supported for
+ both IPv4 (<span class="since">since 0.3.0</span>) and IPv6
+ (<span class="since">since 1.0.1</span>), but only for one IP
+ address of each type per network. The following sub-elements are
+ supported:
<dl>
<dt><code>range</code></dt>
<dd>The <code>start</code> and <code>end</code> attributes on the
@@ -1020,39 +1015,39 @@
<code>ip</code> element. There may be zero or more
<code>range</code> elements specified.
<span class="since">Since 0.3.0</span>
- <code>range</code> can be specified for one IPv4 address,
- one IPv6 address, or both. <span class="since">Since 1.0.1</span>
</dd>
<dt><code>host</code></dt>
- <dd>Within the <code>dhcp</code> element there may be zero or more
- <code>host</code> elements. These specify hosts which will be given
- names and predefined IP addresses by the built-in DHCP server. Any
- IPv4 <code>host</code> element must specify the MAC address of the host to be assigned
- a given name (via the <code>mac</code> attribute), the IP to be
- assigned to that host (via the <code>ip</code> attribute), and the
- name to be given that host by the DHCP server (via the
- <code>name</code> attribute). <span class="since">Since 0.4.5</span>
- An IPv6 <code>host</code> element differs slightly from that for IPv4:
- there is no <code>mac</code> attribute since a MAC address has no
- defined meaning in IPv6. Instead, the <code>name</code> attribute is
- used to identify the host to be assigned the IPv6 address. For DHCPv6,
- the name is the plain name of the client host sent by the
- client to the server. Note that this method of assigning a
- specific IP address can also be used instead of the <code>mac</code>
- attribute for IPv4. <span class="since">Since 1.0.1</span>
+ <dd>Within the <code>dhcp</code> element there may be zero or
+ more <code>host</code> elements. These specify hosts which will
+ be given names and predefined IP addresses by the built-in DHCP
+ server. Any IPv4 <code>host</code> element must specify the MAC
+ address of the host to be assigned a given name (via the
+ <code>mac</code> attribute), the IP to be assigned to that host
+ (via the <code>ip</code> attribute), and the name itself (the
+ <code>name</code> attribute). The IPv6 <code>host</code>
+ element differs slightly from that for IPv4: there is no
+ <code>mac</code> attribute since a MAC address has no defined
+ meaning in IPv6. Instead, the <code>name</code> attribute is
+ used to identify the host to be assigned the IPv6 address. For
+ DHCPv6, the name is the plain name of the client host sent by the
+ client to the server. Note that this method of assigning a
+ specific IP address can also be used for IPv4 instead of the
+ <code>mac</code> attribute.
+ <span class="since">Since 0.4.5</span>
</dd>
<dt><code>bootp</code></dt>
- <dd>The optional <code>bootp</code>
- element specifies BOOTP options to be provided by the DHCP
- server for IPv4 only.
- Two attributes are supported: <code>file</code> is mandatory and
- gives the file to be used for the boot image; <code>server</code> is
- optional and gives the address of the TFTP server from which the boot
- image will be fetched. <code>server</code> defaults to the same host
- that runs the DHCP server, as is the case when the <code>tftp</code>
- element is used. The BOOTP options currently have to be the same
- for all address ranges and statically assigned addresses.<span
- class="since">Since 0.7.1 (<code>server</code> since 0.7.3).</span>
+ <dd>The optional <code>bootp</code> element specifies BOOTP
+ options to be provided by the DHCP server for IPv4 only. Two
+ attributes are supported: <code>file</code> is mandatory and
+ gives the file to be used for the boot image;
+ <code>server</code> is optional and gives the address of the
+ TFTP server from which the boot image will be fetched.
+ <code>server</code> defaults to the same host that runs the
+ DHCP server, as is the case when the <code>tftp</code> element
+ is used. The BOOTP options currently have to be the same for
+ all address ranges and statically assigned addresses. <span
+ class="since">Since 0.7.1</span> (<code>server</code>
+ <span class="since">since 0.7.3</span>)
</dd>
</dl>
</dd>
--
2.11.0
7 years, 10 months
[libvirt] [PATCH v2 0/3] qemu: fix racy paths in agent related code
by Nikolay Shirokovskiy
Changes from v1:
1. patch 2: make vm def copy instead of making qemuAgentGetFSInfo independent of domain conf.
2. patch 3: provide more relevant commit message
Nikolay Shirokovskiy (3):
qemu: agent: fix uninitialized var case in qemuAgentGetFSInfo
qemu: don't use vm when lock is dropped in qemuDomainGetFSInfo
qemu: agent: take monitor lock in qemuAgentNotifyEvent
src/qemu/qemu_agent.c | 5 +++++
src/qemu/qemu_driver.c | 12 +++++++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
--
1.8.3.1
7 years, 10 months
[libvirt] [PATCH] perf: add branch_misses perf event support
by Nitesh Konkar
This patch adds support and documentation
for the branch_misses perf event.
Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com>
---
docs/formatdomain.html.in | 6 ++++++
docs/schemas/domaincommon.rng | 1 +
include/libvirt/libvirt-domain.h | 10 ++++++++++
src/libvirt-domain.c | 4 ++++
src/qemu/qemu_driver.c | 1 +
src/util/virperf.c | 5 ++++-
src/util/virperf.h | 1 +
tests/genericxml2xmlindata/generic-perf.xml | 1 +
tools/virsh.pod | 5 ++++-
9 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 9218eec..086af55 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1928,6 +1928,7 @@
<event name='cache_references' enabled='no'/>
<event name='cache_misses' enabled='no'/>
<event name='branch_instructions' enabled='no'/>
+ <event name='branch_misses' enabled='no'/>
</perf>
...
</pre>
@@ -1978,6 +1979,11 @@
<td>the count of branch instructions by applications running on the platform</td>
<td><code>perf.branch_instructions</code></td>
</tr>
+ <tr>
+ <td><code>branch_misses</code></td>
+ <td>the count of branch misses by applications running on the platform</td>
+ <td><code>perf.branch_misses</code></td>
+ </tr>
</table>
<h3><a name="elementsDevices">Devices</a></h3>
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index c004233..bf8818d 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -428,6 +428,7 @@
<value>cache_references</value>
<value>cache_misses</value>
<value>branch_instructions</value>
+ <value>branch_misses</value>
</choice>
</attribute>
<attribute name="enabled">
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index f43c976..3290b10 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -2135,6 +2135,16 @@ void virDomainStatsRecordListFree(virDomainStatsRecordPtr *stats);
*/
# define VIR_PERF_PARAM_BRANCH_INSTRUCTIONS "branch_instructions"
+/**
+ * VIR_PERF_PARAM_BRANCH_MISSES:
+ *
+ * Macro for typed parameter name that represents branch_misses
+ * perf event which can be used to measure the count of branch misses
+ * by applications running on the platform. It corresponds to the
+ * "perf.branch_misses" field in the *Stats APIs.
+ */
+# define VIR_PERF_PARAM_BRANCH_MISSES "branch_misses"
+
int virDomainGetPerfEvents(virDomainPtr dom,
virTypedParameterPtr *params,
int *nparams,
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 6481abf..a91f432 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -11229,6 +11229,10 @@ virConnectGetDomainCapabilities(virConnectPtr conn,
* "perf.branch_instructions" - The count of branch instructions as
* unsigned long long. It is produced by
* branch_instructions perf event.
+ * "perf.branch_misses" - The count of branch misses as
+ * unsigned long long. It is produced by
+ * branch_misses perf event.
+ *
*
* 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
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 842de0a..0f3a283 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -9853,6 +9853,7 @@ qemuDomainSetPerfEvents(virDomainPtr dom,
VIR_PERF_PARAM_CACHE_REFERENCES, VIR_TYPED_PARAM_BOOLEAN,
VIR_PERF_PARAM_CACHE_MISSES, VIR_TYPED_PARAM_BOOLEAN,
VIR_PERF_PARAM_BRANCH_INSTRUCTIONS, VIR_TYPED_PARAM_BOOLEAN,
+ VIR_PERF_PARAM_BRANCH_MISSES, VIR_TYPED_PARAM_BOOLEAN,
NULL) < 0)
return -1;
diff --git a/src/util/virperf.c b/src/util/virperf.c
index 635faf1..7f630da 100644
--- a/src/util/virperf.c
+++ b/src/util/virperf.c
@@ -41,7 +41,7 @@ VIR_ENUM_IMPL(virPerfEvent, VIR_PERF_EVENT_LAST,
"cmt", "mbmt", "mbml",
"cpu_cycles", "instructions",
"cache_references", "cache_misses",
- "branch_instructions");
+ "branch_instructions", "branch_misses");
struct virPerfEvent {
int type;
@@ -89,6 +89,9 @@ static struct virPerfEventAttr attrs[] = {
{.type = VIR_PERF_EVENT_BRANCH_INSTRUCTIONS,
.attrType = PERF_TYPE_HARDWARE,
.attrConfig = PERF_COUNT_HW_BRANCH_INSTRUCTIONS},
+ {.type = VIR_PERF_EVENT_BRANCH_MISSES,
+ .attrType = PERF_TYPE_HARDWARE,
+ .attrConfig = PERF_COUNT_HW_BRANCH_MISSES},
};
typedef struct virPerfEventAttr *virPerfEventAttrPtr;
diff --git a/src/util/virperf.h b/src/util/virperf.h
index 8ebc03c..7049a5b 100644
--- a/src/util/virperf.h
+++ b/src/util/virperf.h
@@ -38,6 +38,7 @@ typedef enum {
VIR_PERF_EVENT_CACHE_MISSES, /* Cache misses by applications */
VIR_PERF_EVENT_BRANCH_INSTRUCTIONS, /* Count of branch instructions
for applications */
+ VIR_PERF_EVENT_BRANCH_MISSES, /* Count of branch misses for applications */
VIR_PERF_EVENT_LAST
} virPerfEventType;
diff --git a/tests/genericxml2xmlindata/generic-perf.xml b/tests/genericxml2xmlindata/generic-perf.xml
index 92e5847..a1e4e1c 100644
--- a/tests/genericxml2xmlindata/generic-perf.xml
+++ b/tests/genericxml2xmlindata/generic-perf.xml
@@ -21,6 +21,7 @@
<event name='cache_references' enabled='no'/>
<event name='cache_misses' enabled='no'/>
<event name='branch_instructions' enabled='yes'/>
+ <event name='branch_misses' enabled='yes'/>
</perf>
<devices>
</devices>
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 869062a..74c05c9 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -946,7 +946,8 @@ I<--perf> returns the statistics of all enabled perf events:
"perf.instructions" - the count of instructions,
"perf.cache_references" - the count of cache hits,
"perf.cache_misses" - the count of caches misses,
-"perf.branch_instructions" - the count of application branch instructions
+"perf.branch_instructions" - the count of branch instructions,
+"perf.branch_misses" - the count of branch misses
See the B<perf> command for more details about each event.
@@ -2296,6 +2297,8 @@ B<Valid perf event names>
branch_instructions - Provides the count of branch instructions
executed by applications running on the
platform.
+ branch_misses - Provides the count of branch misses executed
+ by applications running on the platform.
B<Note>: The statistics can be retrieved using the B<domstats> command using
the I<--perf> flag.
--
1.9.3
7 years, 10 months
[libvirt] [PATCH] AppArmor policy: support merged-/usr.
by intrigeri
From: intrigeri <intrigeri(a)debian.org>
---
examples/apparmor/libvirt-qemu | 8 ++++----
examples/apparmor/usr.lib.libvirt.virt-aa-helper | 2 +-
examples/apparmor/usr.sbin.libvirtd | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu
index 11381d4..133c2eb 100644
--- a/examples/apparmor/libvirt-qemu
+++ b/examples/apparmor/libvirt-qemu
@@ -136,12 +136,12 @@
/usr/{lib,lib64}/qemu/block-rbd.so mr,
# for save and resume
- /bin/dash rmix,
- /bin/dd rmix,
- /bin/cat rmix,
+ /{usr/,}bin/dash rmix,
+ /{usr/,}bin/dd rmix,
+ /{usr/,}bin/cat rmix,
# for restore
- /bin/bash rmix,
+ /{usr/,}bin/bash rmix,
# for usb access
/dev/bus/usb/ r,
diff --git a/examples/apparmor/usr.lib.libvirt.virt-aa-helper b/examples/apparmor/usr.lib.libvirt.virt-aa-helper
index b34fb35..4a8f197 100644
--- a/examples/apparmor/usr.lib.libvirt.virt-aa-helper
+++ b/examples/apparmor/usr.lib.libvirt.virt-aa-helper
@@ -21,7 +21,7 @@ profile virt-aa-helper /usr/{lib,lib64}/libvirt/virt-aa-helper {
/sys/devices/** r,
/usr/{lib,lib64}/libvirt/virt-aa-helper mr,
- /sbin/apparmor_parser Ux,
+ /{usr/,}sbin/apparmor_parser Ux,
/etc/apparmor.d/libvirt/* r,
/etc/apparmor.d/libvirt/libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]* rw,
diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
index 48651b2..934124b 100644
--- a/examples/apparmor/usr.sbin.libvirtd
+++ b/examples/apparmor/usr.sbin.libvirtd
@@ -47,12 +47,12 @@
/usr/bin/* PUx,
/usr/sbin/virtlogd pix,
/usr/sbin/* PUx,
- /lib/udev/scsi_id PUx,
+ /{usr/,}lib/udev/scsi_id PUx,
/usr/{lib,lib64}/xen-common/bin/xen-toolstack PUx,
/usr/{lib,lib64}/xen/bin/* Ux,
# force the use of virt-aa-helper
- audit deny /sbin/apparmor_parser rwxl,
+ audit deny /{usr/,}sbin/apparmor_parser rwxl,
audit deny /etc/apparmor.d/libvirt/** wxl,
audit deny /sys/kernel/security/apparmor/features rwxl,
audit deny /sys/kernel/security/apparmor/matching rwxl,
--
2.10.2
7 years, 10 months
[libvirt] [PATCH 0/3] qemu: fix racy paths in agent related code
by Nikolay Shirokovskiy
Patch 1 is a nitpick I found when working on Patch 2.
Patch 2 and 3 fix a couple of race conditions in code.
A lot of changes is inherent refactorings in Patch 2 actually.
Nikolay Shirokovskiy (3):
qemu: agent: fix uninitialized var case in qemuAgentGetFSInfo
qemu: don't use vmdef without domain lock
qemu: agent: take monitor lock in qemuAgentNotifyEvent
src/qemu/qemu_agent.c | 57 +++++++++++++--------
src/qemu/qemu_agent.h | 25 ++++++++-
src/qemu/qemu_driver.c | 88 +++++++++++++++++++++++++++++++-
tests/Makefile.am | 1 -
tests/qemuagentdata/qemuagent-fsinfo.xml | 39 --------------
tests/qemuagenttest.c | 47 +++++++----------
6 files changed, 164 insertions(+), 93 deletions(-)
delete mode 100644 tests/qemuagentdata/qemuagent-fsinfo.xml
--
1.8.3.1
7 years, 10 months
[libvirt] [PATCH] docs: Replace missing description for perf.cpu_cycles
by John Ferlan
Lost during merge of commit id '8546adf80' and '585ad00b5'
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
Pushed as trivial
src/libvirt-domain.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 6481abf..8b4e814 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -11226,6 +11226,9 @@ virConnectGetDomainCapabilities(virConnectPtr conn,
* It is produced by cache_references perf event.
* "perf.instructions" - The count of instructions as unsigned long long.
* It is produced by instructions perf event.
+ * "perf.cpu_cycles" - The count of cpu cycles (total/elapsed) as an
+ * unsigned long long. It is produced by cpu_cycles
+ * perf event.
* "perf.branch_instructions" - The count of branch instructions as
* unsigned long long. It is produced by
* branch_instructions perf event.
--
2.7.4
7 years, 10 months
[libvirt] dpdk/vpp and cross-version migration for vhost
by Michael S. Tsirkin
Hi!
So it looks like we face a problem with cross-version
migration when using vhost. It's not new but became more
acute with the advent of vhost user.
For users to be able to migrate between different versions
of the hypervisor the interface exposed to guests
by hypervisor must stay unchanged.
The problem is that a qemu device is connected
to a backend in another process, so the interface
exposed to guests depends on the capabilities of that
process.
Specifically, for vhost user interface based on virtio, this includes
the "host features" bitmap that defines the interface, as well as more
host values such as the max ring size. Adding new features/changing
values to this interface is required to make progress, but on the other
hand we need ability to get the old host features to be compatible.
To solve this problem within qemu, qemu has a versioning system based on
a machine type concept which fundamentally is a version string, by
specifying that string one can get hardware compatible with a previous
qemu version. QEMU also reports the latest version and list of versions
supported so libvirt records the version at VM creation and then is
careful to use this machine version whenever it migrates a VM.
One might wonder how is this solved with a kernel vhost backend. The
answer is that it mostly isn't - instead an assumption is made, that
qemu versions are deployed together with the kernel - this is generally
true for downstreams. Thus whenever qemu gains a new feature, it is
already supported by the kernel as well. However, if one attempts
migration with a new qemu from a system with a new to old kernel, one
would get a failure.
In the world where we have multiple userspace backends, with some of
these supplied by ISVs, this seems non-realistic.
IMO we need to support vhost backend versioning, ideally
in a way that will also work for vhost kernel backends.
So I'd like to get some input from both backend and management
developers on what a good solution would look like.
If we want to emulate the qemu solution, this involves adding the
concept of interface versions to dpdk. For example, dpdk could supply a
file (or utility printing?) with list of versions: latest and versions
supported. libvirt could read that and
- store latest version at vm creation
- pass it around with the vm
- pass it to qemu
>From here, qemu could pass this over the vhost-user channel,
thus making sure it's initialized with the correct
compatible interface.
As version here is an opaque string for libvirt and qemu,
anything can be used - but I suggest either a list
of values defining the interface, e.g.
any_layout=on,max_ring=256
or a version including the name and vendor of the backend,
e.g. "org.dpdk.v4.5.6".
Note that typically the list of supported versions can only be
extended, not shrunk. Also, if the host/guest interface
does not change, don't change the current version as
this just creates work for everyone.
Thoughts? Would this work well for management? dpdk? vpp?
Thanks!
--
MST
7 years, 10 months