- Devel - libvirt List Archives

[libvirt] [PATCH v2] docs: add a page describing support guarantees for libvirt features
by Daniel P. Berrange 17 Nov '17

17 Nov '17

While we have collective knowledge about the support status of various parts of libvirt, this has never been formally documented, leaving our users to guess. Note, this document makes one change to our previous policy. It explicitly declares the RPC protocol of libvirtd as being a supported interface. THis accepts the reality that we can a) never change it without breaking compat with old libvirt.so, b) there are both rust + go impls that are written against the RPC protocol alrady. Reviewed-by: Jim Fehlig <jfehlig(a)suse.com> Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- Changed in v2: - Spelling fixes (Jim) - Call out new RPC policy in commit msg docs/docs.html.in | 3 + docs/support.html.in | 257 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 260 insertions(+) create mode 100644 docs/support.html.in diff --git a/docs/docs.html.in b/docs/docs.html.in index 931da85424..a8d544f83f 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -110,6 +110,9 @@ <dt><a href="drivers.html">Drivers</a></dt> <dd>Hypervisor specific driver information</dd> + <dt><a href="support.html">Support guarantees</a></dt> + <dd>Details of support status for various interfaces</dd> + <dt><a href="hvsupport.html">Driver support</a></dt> <dd>matrix of API support per hypervisor per release</dd> diff --git a/docs/support.html.in b/docs/support.html.in new file mode 100644 index 0000000000..7a377e6152 --- /dev/null +++ b/docs/support.html.in @@ -0,0 +1,257 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Support guarantees</h1> + + <ul id="toc"></ul> + + <p> + This document will outline the support status / guarantees around the + very interfaces that libvirt exposes to applications and/or system + administrators. The intent is to help users understand what features they + can rely upon in particular scenarios, and whether they are likely to + suffer disruption during upgrades + </p> + + <h2><a id="publicAPI">Primary public API</a></h2> + + <p> + The main public API provided by <code>libvirt.so</code> and described + in <code>libvirt/libvirt.h</code> exposes the primary hypervisor + agnostic management interface of libvirt. This API has the strongest + guarantee of any part of libvirt with a promise to keep backwards + compatibility forever. Specific details are as follows: + </p> + + <dl> + <dt>Functions</dt> + <dd>Functions will never be removed from the public API, and will + never have parameters added, removed or changed in their signature. + IOW they will be ABI compatible forever. The semantics implied by + a specific set of parameters passed to the function will remain + unchanged. Where a parameter accepts a bitset of feature flags, or + an enumerated value, further flags / enum values may be supported + in the future. Where a parameter accepts one of a set of related + constants, further constants may be supported in the future. + </dd> + <dt>Struct types</dt> + <dd>Once defined in a release, struct definitions will never have any + fields add, removed or changed in any way. Their size and layout is + fixed forever. If a struct name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the struct name. + </dd> + <dt>Union types</dt> + <dd>Once defined in a release, union definitions will never have any + existing fields removed or changed. New union choices may be added, + provided that they don't change the size of the existing union + definition. If a struct name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the struct name. + </dd> + <dt>Type definitions</dt> + <dd>Most custom data types used in the APIs have corresponding typedefs + provided for their stable names. The typedefs should always be used + in preference to the underlying data type name, as the latter are not + guaranteed to be stable. + </dd> + <dt>Enumerations</dt> + <dd>Once defined in a release, existing enumeration values will never + be removed or renamed. New enumeration values may be introduced at + any time. Every enumeration will have a '_LAST' value which indicates + the current highest enumeration value, which may increase with new + releases. If an enumeration name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the enum name. + </dd> + <dt>Constants</dt> + <dd>Once defined in a release, existing constants will never be removed + or have their value changed. Most constants are grouped into related + sets, and within each set, new constants may be introduced. APIs which + use the constants may thus accept or return new constant values over + time. + </dd> + <dt>Symbol versions</dt> + <dd>Where the platform library format permits, APIs defined in libvirt.so + library will have version information associated. Each API will be + tagged with the version in which it was introduced, and this won't + be changed thereafter. + </dd> + </dl> + + <h2><a id="hvAPI">Hypervisor specific APIs</a></h2> + + <p> + A number of hypervisor drivers provide additional libraries with hypervisor + specific APIs, extending the core libvirt API. These add-on libraries follow + the same general principles described above, however, they are <strong>not</strong> + guaranteed to be preserved forever. The project reserves the right to remove + hypervisor specific APIs in any new release, or to change their semantics. + That said the project will endeavour to maintain API compatibility for as long + as is practical. + </p> + + <p> + Use of some hypervisor specific APIs may result in the running guest being + marked as "tainted" if the API is at risk of having unexpected interactions + with normal libvirt operations. An application which chooses to make use of + hypervisor specific APIs should validate their operation with each new release + of libvirt and each new release of the underlying hypervisor. The semantics + may change in unexpected ways, or have unforeseen interactions with libvirt's + operation. + </p> + + <h2><a id="apierrors">Error reporting</a></h2> + + <p> + Most API calls are subject to failure and so will report error codes and + messages. Libvirt defines error codes for a wide variety of scenarios, some + represent very specific problems, while others are general purpose for + broad classes of problem. Over time the error codes reported are liable + to change, usually changing from a generic error to a more specific error. + Thus applications should be careful about checking for & taking action + upon specific error codes, as their behaviour may change across releases. + </p> + + <h2><a id="xmlschema">XML schemas</a></h2> + + <p> + The main objects exposed via the primary libvirt public API are usually + configured via XML documents following specific schemas. The XML schemas + are considered to be stable formats, whose compatibility will be maintained + forever. Specific details are as follows: + </p> + + <dl> + <dt>Attributes</dt> + <dd>Attributes defined on an XML element will never be removed or + renamed. New attributes may be defined. If the set of valid values + for an attribute are determined by an enumeration, the permitted + values will never be removed or renamed, only new values defined. + None the less, specific hypervisors may reject usage of certain + values according to their feature set.</dd> + <dt>Elements</dt> + <dd>Elements defined will never be removed or renamed. New child + elements may be defined at any time. In places where only a + single instance of a named XML element is used, future versions + may be extended to permit multiple instances of the named XML + element to be used. An element which currently has no content + may later gain child elements. + </dd> + </dl> + + <p> + Some hypervisor drivers may choose to allow use of hypervisor specific + extensions to the XML documents. These extensions will always be + contained within a hypervisor specific XML namespace. There is generally + no guarantee of long term support for the hypervisor specific extensions + across releases, though the project will endeavour to preserve them as + long as is possible. Applications choosing to use hypervisor specific + extensions should validate their operation against new libvirt or + hypervisor releases. + </p> + + <h2><a id="configfiles">Configuration files</a></h2> + + <p> + A number of programs / daemons provided libvirt rely on host filesystem + configuration files. These configuration files are accompanied by augeas + lens for easy manipulation by applications. There is in general no + guarantee that parameters available in the configuration file will be + preserved across releases, though the project will endeavour to preserve + them as long as is possible. If a configuration option is dropped from + the file, the augeas lens will retain the ability to read that configuration + parameter, so that it is able to read & update historically modified + files. + + The default configuration files ship with all parameters commented out + such that a deployment relies on the built-in defaults of the application + in question. There is no guarantee that the defaults will remain the same + across releases. A deployment that expects a particular value for a + configuration parameter should consider defining it explicitly, instead + of relying on the defaults. + </p> + + <h2><a id="hvdrivers">Hypervisor drivers</a></h2> + + <p> + The libvirt project provides support for a wide variety of hypervisor + drivers. These drivers target certain versions of the hypervisor's + underlying management APIs. In general libvirt aims to work with any + hypervisor version that is still broadly supported by its vendor. + When a vendor discontinues support for a particular hypervisor + version it will be dropped by libvirt. Libvirt may choose to drop + support for a particular hypervisor version prior to the vendor + ending support, if it deems that the likely usage is too small to + justify the ongoing maintenance cost. + </p> + <p> + Each hypervisor release will implement a distinct subset of features + that can be expressed in the libvirt APIs and XML formats. While the + XML schema syntax will be stable across releases, libvirt is unable + to promise that it will always be able to support usage of the same + features across hypervisor releases. Where a hypervisor changes the + way a feature is implemented, the project will endeavour to adapt + to the new implementation to provide the same semantics. In cases + where the feature is discontinued by the hypervisor, libvirt will + return an error indicating it is not supported. Likewise libvirt will + make reasonable efforts to keep API calls working across hypervisor + releases even if the underlying implementation changes. In cases where + this is impossible, an suitable error will be reported. The list of + APIs which have implementations <a href="hvsupport.html">is detailed separately</a>. + </p> + + <h2><a id="rpcproto">RPC protocol</a></h2> + + <p> + For some hypervisor drivers, the libvirt.so library communicates with + separate libvirt daemons to perform work. This communication takes + place over a binary RPC protocol defined by libvirt. The protocol uses + the XDR format for data encoding, and the message packet format is + defined in libvirt source code. + </p> + <p> + Applications are encouraged to use the primary libvirt.so library which + transparently talks to the daemons, so that they are not exposed to the + hypervisor driver specific details. None the less, the RPC protocol + associated with the libvirtd is considered to be a long term stable ABI. + It will only ever have new messages added to it, existing messages will + not be removed, nor have their contents changed. Thus if an application + does wish to provide its own client side implementation of the RPC + protocol this is supported, with the caveat that the application will + loose the ability to work with certain hypervisors libvirt supports. + The project reserves the right to define new authentication and encryption + options for the protocol, and the defaults used in this area may change + over time. This is particularly true of the TLS ciphers permitted. Thus + applications choosing to implement the RPC protocol must be prepared to + track support for new security options. If defaults are changed, however, + it will generally be possible to reconfigure the daemon to use the old + defaults, albeit with possible implications for system security. + </p> + + <p> + Other daemons besides, libvirtd, also use the same RPC protocol, but + with different message types defined. These RPC protocols are all + considered to be private implementations that are liable to change + at any time. Applications must not attempt to talk to these other + daemons directly. + </p> + + <h2><a id="virsh">virsh client</a></h2> + + <p> + The virsh program provides a simple client to interact with an arbitrary libvirt + hypevisor connection. Since it uses the primary public API of libvirt, it should + generally inherit the guarantees associated with that API, and with the hypervisor + driver. The commands that virsh exposes, and the arguments they accept are all + considered to be long term stable. Existing commands and arguments will not be + removed or renamed. New commands and arguments may be added in new releases. + The text output format produced by virsh commands is not generally guaranteed to + be stable if it contains compound data (eg formatted tables or lists). Commands + which output single data items (ie an object name, or an XML document), can be + treated as having stable format. + </p> + + </body> +</html> -- 2.14.3

2 2

[libvirt] [PATCH] docs: add a page describing support guarantees for libvirt features
by Daniel P. Berrange 16 Nov '17

16 Nov '17

While we have collective knowledge about the support status of various parts of libvirt, this has never been formally documented, leaving our users to guess. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/docs.html.in | 3 + docs/support.html.in | 257 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 260 insertions(+) create mode 100644 docs/support.html.in diff --git a/docs/docs.html.in b/docs/docs.html.in index 931da85424..a8d544f83f 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -110,6 +110,9 @@ <dt><a href="drivers.html">Drivers</a></dt> <dd>Hypervisor specific driver information</dd> + <dt><a href="support.html">Support guarantees</a></dt> + <dd>Details of support status for various interfaces</dd> + <dt><a href="hvsupport.html">Driver support</a></dt> <dd>matrix of API support per hypervisor per release</dd> diff --git a/docs/support.html.in b/docs/support.html.in new file mode 100644 index 0000000000..6f34a35eb7 --- /dev/null +++ b/docs/support.html.in @@ -0,0 +1,257 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Support guarantees</h1> + + <ul id="toc"></ul> + + <p> + This document will outline the support status / guarantees around the + very interfaces that libvirt exposes to applications and/or system + adminstrators. The intent is to help users understand what features they + can rely upon in particular scenarios, and whether they are likely to + suffer disruption during upgrades + </p> + + <h2><a id="publicAPI">Primary public API</a></h2> + + <p> + The main public API provided by <code>libvirt.so</code> and described + in <code>libvirt/libvirt.h</code> exposes the primary hypervisor + agnostic management interface of libvirt. This API has the strongest + guarantee of any part of libvirt with a promise to keep backwards + compatibility forever. Specific details are as follows: + </p> + + <dl> + <dt>Functions</dt> + <dd>Functions will never be removed from the public API, and will + never have parameters added, removed or changed in their signature. + IOW they will be ABI compatible forever. The semantics implied by + a specific set of parameters passed to the function will remain + unchanged. Where a parameter accepts a bitset of feature flags, or + an enumerated value, further flags / enum values may be supported + in the future. Where a parameter accepts one of a set of related + constants, further constants may be supported in the future. + </dd> + <dt>Struct types</dt> + <dd>Once defined in a release, struct definitions will never have any + fields add, removed or changed in any way. Their size and layout is + fixed forever. If a struct name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the struct name. + </dd> + <dt>Union types</dt> + <dd>Once defined in a release, union definitions will never have any + existing fields removed or changed. New union choices may be added, + provided that they don't change the size of the existing union + definition. If a struct name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the struct name. + </dd> + <dt>Type definitions</dt> + <dd>Most custom data types used in the APIs have corresponding typedefs + provided for their stable names. The typedefs should always be used + in preference to the underlying data type name, as the latter are not + guaranteed to be stable. + </dd> + <dt>Enumerations</dt> + <dd>Once defined in a release, existing enumeration values will never + be removed or renamed. New enumeration values may be introduced at + any time. Every enumeration will have a '_LAST' value which indicates + the current highest enumeration value, which may increase with new + releases. If an enumeration name starts with an underscore, it is + considered acceptable to rename it. Applications should thus always + use the corresponding typedef in preference to the enum name. + </dd> + <dt>Constants</dt> + <dd>Once defined in a release, existing constants will never be removed + or have their value changed. Most constants are grouped into related + sets, and within each set, new constants may be introduced. APIs which + use the constants may thus accept or return new constant values over + time. + </dd> + <dt>Symbol versions</dt> + <dd>Where the platform library format permits, APIs defined in libvirt.so + library will have version information associated. Each API will be + tagged with the version in which it was introduced, and this won't + be changed thereafter. + </dd> + </dl> + + <h2><a id="hvAPI">Hypervisor specific APIs</a></h2> + + <p> + A number of hypervisor drivers provide additional libraries with hypervisor + specific APIs, extending the core libvirt API. These add-on libraries follow + the same general principles described above, however, they are <strong>not</strong> + not guranteed to be preserved forever. The project reserves the right to remove + hypervisor specific APIs in any new release, or to change their semantics. + That said the project will endeavour to maintain API compatibility for as long + as is practical. + </p> + + <p> + Use of some hypervisor specific APIs may result in the running guest being + marked as "tainted" if the API is at risk of having unexpected interactions + with normal libvirt operations. An application which chooses to make use of + hypervisor specific APIs should validate their operation with each new release + of libvirt and each new release of the underlying hypervisor. The semantics + may change in unexpected ways, or have unforseen interactions with libvirt's + operation. + </p> + + <h2><a id="apierrors">Error reporting</a></h2> + + <p> + Almost API calls are subject to failure and so will report error codes and + messages. Libvirt defines error codes for a wide variety of scenarios, some + are very targetted to specific problems, while others are general purpose + for broad classes of problem. Over time the error codes reported are liable + to, usually changing from a generic error to a more specific error. Thus + applications should be careful about checking for & taking action upon + specific error codes, as the behaviour is liable to change across releases. + </p> + + <h2><a id="xmlschema">XML schemas</a></h2> + + <p> + The main objects exposed via the primary libvirt public API are usually + configured via XML documents following specific schemas. The XML schemas + are considered to be stable formats, whose compatibility will be maintained + forever. Specific details are as follows: + </p> + + <dl> + <dt>Attributes</dt> + <dd>Attributes defined on an XML element will never be removed or + renamed. New attributes may be defined. If the set of valid values + for an attribute are determined by an enumeration, the permitted + values will never be removed or renamed, only new values defined. + None the less, specific hypervisors may reject usage of certain + values according to their feature set.</dd> + <dt>Elements</dt> + <dd>Elements defined will never be removed or renamed. New child + elements may be defined at any time. In places where only a + single instance of a named XML element is used, future versions + may be extended to permit multiple instances of the named XML + element to be used. An element which currently has no content + may later gain child elements. + </dd> + </dl> + + <p> + Some hypervisor drivers may choose to allow use of hypervisor specific + extensions to the XML documents. These extensions will always be + contained within a hypervisor specific XML namespace. There is generally + no guarantee of long term support for the hypervisor specific extensions + across releases, though the project will endeavour to preserve them as + long as is possible. Applications choosing to use hypervisor specific + extensions should validate their operation against new libvirt or + hypervisor releases. + </p> + + <h2><a id="configfiles">Configuration files</a></h2> + + <p> + A number of programs / daemons provided libvirt rely on host filesystem + configuration files. These configuration files are accompanied by augeas + lens for easy manipulation by applications. There is in general no + guarantee that parameters available in the configuration file will be + preserved across releases, though the project will endeavour to preserve + them as long as is possible. If a configuration option is dropped from + the file, the augeas lens will retain the ability to read that configuration + parameter, so that it is able to read & update historically modified + files. + + The default configuration files ship with all parameters commented out + such that a deployment relies on the built-in defaults of the application + in question. There is no guarantee that the defaults will remain the same + across releases. An deployments that expects a particular value for a + configuration parameter should consider defining it explicitly, instead + of relying on the defaults. + </p> + + <h2><a id="hvdrivers">Hypervisor drivers</a></h2> + + <p> + The libvirt project provides support for a wide variety of hypervisor + drivers. These drivers target certain versions of the hypervisor's + underlying management APIs. In general libvirt aims to work with any + hypervisor version that is still broadly supported by its vendor. + When a vendor discontinues support for a particular hypervisor + version it will be dropped by libvirt. Libvirt may choose to drop + support for a particular hypervisor version prior to the vendor + ending support, if it deems that the likely usage is too small to + justify the ongoing maintenance cost. + </p> + <p> + Each hypervisor release will implement a distinct subset of features + that can be expressed in the libvirt APIs and XML formats. While the + XML schema syntax will be stable across releases, libvirt is unable + to promise that it will always be able to support usage of the same + features across hypervisor releases. Where a hypervisor changes the + way a feature is implemented, the project will endeavour to adapt + to the new implementation to provide the same semantics. In cases + where the feature is discontinued by the hypervisor, libvirt will + return an error indicating it is no supported. Likewise libvirt will + make reasonable efforts to keep API calls working across hypervisor + releases even if the underlying implementation changes. In cases where + this is impossible, an suitable error will be reported. The list of + APIs which have implementations <a href="hvsupport.html">is detailed separately</a>. + </p> + + <h2><a id="rpcproto">RPC protocol</a></h2> + + <p> + For some hypervisor drivers, the libvirt.so library communicates with + separate libvirt daemons to perform work. This communication takes + place over a binary RPC protocol defined by libvirt. The protocol uses + the XDR format for data encoding, and the message packet format is + defined in libvirt source code. + </p> + <p> + Applications are encouraged to use the primary libvirt.so library which + transparently talks to the daemons, so that they are not exposed to the + hypervisor driver specific details. None the less, the RPC protocol + associated with the libvirtd is considered to be a long term stable ABI. + It will only ever have new messages added to it, existing messages will + not be removed, nor have their contents changed. Thus if an application + does wish to provide its own client side implementation of the RPC + protocol this is supported, with the caveat that the application will + loose the ability to work with certain hypervisors libvirt supports. + The project reserves the right to define new authentication and encryption + options for the protocol, and the defaults used in this area may change + over time. This is particularly true of the TLS ciphers permitted. Thus + applications choosing to implement the RPC protocol must be prepared to + track support for new security options. If defaults are changed, however, + it will generally be possible to reconfigure the daemon to use the old + defaults, albeit with possible implications for system security. + </p> + + <p> + Other daemons besides, libvirtd, also use the same RPC protocol, but + with different message types defined. These RPC protocols are all + considered to be private implementation that are liable to change + at any time. Applications must not attempt to talk to these other + daemons directly. + </p> + + <h2><a id="virsh">virsh client</a></h2> + + <p> + The virsh program provides a simple client to interact with an arbitrary libvirt + hypevisor connection. Since it uses the primary public API of libvirt, it should + generally inherit the guarantees associated with that API, and with the hypervisor + driver. The commands that virsh exposes, and the arguments they accept are all + considered to be long term stable. Existing commands and arguments will not be + removed or renamed. New commands and arguments may be added in new releases. + The text output format produced by virsh commands is not generally guaranteed to + be stable if it contains compound data (eg formatted tables or lists). Commands + which output single data items (ie an object name, or an XML document), can be + treated as having stable format. + </p> + + </body> +</html> -- 2.14.3

2 1

[libvirt] [PATCH] virt-viewer.spec.in: fix build after spice-xpi-client removal
by marcandre.lureau＠redhat.com 16 Nov '17

16 Nov '17

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> This fixes commit 140cb84c2538bf0eab7dea2035dfecc4db74c784, where we removed the spice-xpi-client-remote-viewer. Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com> --- virt-viewer.spec.in | 8 -------- 1 file changed, 8 deletions(-) diff --git a/virt-viewer.spec.in b/virt-viewer.spec.in index 44ef92e..54e2121 100644 --- a/virt-viewer.spec.in +++ b/virt-viewer.spec.in @@ -89,9 +89,6 @@ autoreconf -if %install rm -rf $RPM_BUILD_ROOT %__make install DESTDIR=$RPM_BUILD_ROOT -mkdir -p %{buildroot}%{_libexecdir} -touch %{buildroot}%{_libexecdir}/spice-xpi-client -install -m 0755 data/spice-xpi-client-remote-viewer %{buildroot}%{_libexecdir}/ %find_lang %{name} %clean @@ -100,8 +97,6 @@ rm -rf $RPM_BUILD_ROOT %post /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null || : /bin/touch --no-create %{_datadir}/mime/packages &> /dev/null || : -%{_sbindir}/update-alternatives --install %{_libexecdir}/spice-xpi-client \ - spice-xpi-client %{_libexecdir}/spice-xpi-client-remote-viewer 25 /usr/bin/update-desktop-database -q %{_datadir}/applications %postun @@ -109,7 +104,6 @@ if [ $1 -eq 0 ] ; then /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null /usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : /usr/bin/update-mime-database %{_datadir}/mime &> /dev/null || : - %{_sbindir}/update-alternatives --remove spice-xpi-client %{_libexecdir}/spice-xpi-client-remote-viewer fi /usr/bin/update-desktop-database -q %{_datadir}/applications @@ -127,8 +121,6 @@ fi %{_datadir}/applications/remote-viewer.desktop %{_datadir}/appdata/remote-viewer.appdata.xml %{_datadir}/mime/packages/virt-viewer-mime.xml -%ghost %{_libexecdir}/spice-xpi-client -%{_libexecdir}/spice-xpi-client-remote-viewer %{_mandir}/man1/virt-viewer.1* %{_mandir}/man1/remote-viewer.1* -- 2.15.0.125.g8f49766d64

2 1

[libvirt] [jenkins-ci PATCH 0/2] Small fixes
by Andrea Bolognani 16 Nov '17

16 Nov '17

Andrea Bolognani (2): jobs: Use $MAKE in autotools-mingw-job projects: Use {smp} in osinfo-db-master-build jobs/autotools.yaml | 8 ++++---- projects/osinfo-db.yaml | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) -- 2.14.3

2 4

[libvirt] [jenkins-ci PATCH] projects: Port libvirt-cim to autotools-*-job
by Andrea Bolognani 16 Nov '17

16 Nov '17

Now that libvirt-cim's autogen.sh script has been changed to be compatible with the ones used by other libvirt-related project, we can drop the ad-hoc rules used to build it and adopt the standard autotools-*-job rules instead. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Not to be pushed until https://www.redhat.com/archives/libvir-list/2017-November/msg00675.html has been merged into libvirt-cim. projects/libvirt-cim.yaml | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/projects/libvirt-cim.yaml b/projects/libvirt-cim.yaml index b5405f3..d09db86 100644 --- a/projects/libvirt-cim.yaml +++ b/projects/libvirt-cim.yaml @@ -9,17 +9,7 @@ - libvirt-fedora-rawhide title: libvirt CIM jobs: - - generic-build-job: + - autotools-build-job: parent_jobs: 'libvirt-master-build' - command: | - {make_env} - ./autogen.sh - ./configure --prefix=$VIRT_PREFIX - $MAKE -j{smp} - $MAKE -j{smp} install - - generic-rpm-job: + - autotools-rpm-job: parent_jobs: 'libvirt-cim-master-build' - command: | - {make_env} - sed -i -e "s/.*libvirt-devel.*//" libvirt-cim.spec.in - $MAKE -j{smp} rpm -- 2.14.3

2 1

[libvirt] [cim PATCH 0/3] autogen.sh improvements
by Andrea Bolognani 16 Nov '17

16 Nov '17

These changes are a requirement for porting the libvirt-cim CI jobs to autotools-*-job. Andrea Bolognani (3): autogen: Better error handling autogen: Run configure automatically autogen: Support running out-of-tree autogen.sh | 48 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 37 insertions(+), 11 deletions(-) -- 2.14.3

2 4

[libvirt] [PATCH v2 0/3] Fix user provided aliases for some devices
by Michal Privoznik 16 Nov '17

16 Nov '17

In case user provides an alias for a device that is implicit (e.g. IDE controller for 440fx, SATA for Q35, etc.) we don't put the device onto qemu command line. Therefore we can't set its alias. diff to v1: - more controllers covered Michal Privoznik (3): virQEMUCapsHasPCIMultiBus: Fix @def type qemuBuildDriveDevStr: Prefer default alias for SATA bus qemuBuildDeviceAddressStr: Prefer default alias for PCI bus src/qemu/qemu_capabilities.c | 2 +- src/qemu/qemu_capabilities.h | 2 +- src/qemu/qemu_command.c | 45 ++++++++++++++++------ .../qemuxml2argvdata/qemuxml2argv-user-aliases.xml | 4 +- .../qemuxml2argv-user-aliases2.args | 1 + .../qemuxml2argv-user-aliases2.xml | 34 ++++++++++++++++ tests/qemuxml2argvtest.c | 1 + 7 files changed, 75 insertions(+), 14 deletions(-) create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-user-aliases2.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-user-aliases2.xml -- 2.13.6

2 5

[libvirt] [PATCH] RFC: qemu: add vmcoreinfo support
by marcandre.lureau＠redhat.com 16 Nov '17

16 Nov '17

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Starting from qemu 2.11, the `-device vmcoreinfo` will create a fw_cfg entry for a guest to store dump details, necessary to process kernel dump with KASLR enabled and providing additional kernel details. Since the device is a singleton and shouldn't use additional hardware resources, I decided to map this to a <feature> element in the libvirt domain XML. Feel free to argue and decide if it is better to have it under <devices> instead. The device is arm/x86 only for now (targets that support fw_cfg+dma). Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1395248 Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com> --- docs/formatdomain.html.in | 4 +++ docs/schemas/domaincommon.rng | 5 +++ src/conf/domain_conf.c | 5 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 26 +++++++++++++++ .../qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args | 25 ++++++++++++++ tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml | 28 ++++++++++++++++ tests/qemuxml2argvtest.c | 1 + .../qemuxml2xmlout-vmcoreinfo.xml | 38 ++++++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 12 files changed, 136 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 92e14a919..d87a32a89 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1878,6 +1878,10 @@ which is also known as a split I/O APIC mode. <span class="since">Since 3.4.0</span> (QEMU/KVM only) </dd> + <dt><code>vmcoreinfo</code></dt> + <dd>Enable QEMU vmcoreinfo device to let the guest kernel save debug + details. <span class="since">Since 3.10.0</span> (QEMU only) + </dd> </dl> <h3><a id="elementsTime">Time keeping</a></h3> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 9cec1a063..86cbe2c8c 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -4736,6 +4736,11 @@ <optional> <ref name="ioapic"/> </optional> + <optional> + <element name="vmcoreinfo"> + <empty/> + </element> + </optional> </interleave> </element> </optional> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 400e90032..3a9b56cd2 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -148,7 +148,8 @@ VIR_ENUM_IMPL(virDomainFeature, VIR_DOMAIN_FEATURE_LAST, "vmport", "gic", "smm", - "ioapic") + "ioapic", + "vmcoreinfo") VIR_ENUM_IMPL(virDomainCapabilitiesPolicy, VIR_DOMAIN_CAPABILITIES_POLICY_LAST, "default", @@ -18710,6 +18711,7 @@ virDomainDefParseXML(xmlDocPtr xml, case VIR_DOMAIN_FEATURE_VIRIDIAN: case VIR_DOMAIN_FEATURE_PRIVNET: case VIR_DOMAIN_FEATURE_HYPERV: + case VIR_DOMAIN_FEATURE_VMCOREINFO: case VIR_DOMAIN_FEATURE_KVM: def->features[val] = VIR_TRISTATE_SWITCH_ON; break; @@ -26052,6 +26054,7 @@ virDomainDefFormatInternal(virDomainDefPtr def, case VIR_DOMAIN_FEATURE_ACPI: case VIR_DOMAIN_FEATURE_PAE: case VIR_DOMAIN_FEATURE_VIRIDIAN: + case VIR_DOMAIN_FEATURE_VMCOREINFO: case VIR_DOMAIN_FEATURE_PRIVNET: switch ((virTristateSwitch) def->features[i]) { case VIR_TRISTATE_SWITCH_ABSENT: diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index be38792c6..add668025 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1723,6 +1723,7 @@ typedef enum { VIR_DOMAIN_FEATURE_GIC, VIR_DOMAIN_FEATURE_SMM, VIR_DOMAIN_FEATURE_IOAPIC, + VIR_DOMAIN_FEATURE_VMCOREINFO, VIR_DOMAIN_FEATURE_LAST } virDomainFeature; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 7cb091056..44a2833a7 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -443,6 +443,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, /* 270 */ "vxhs", "virtio-blk.num-queues", + "vmcoreinfo", ); @@ -1670,6 +1671,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = { { "pcie-root-port", QEMU_CAPS_DEVICE_PCIE_ROOT_PORT }, { "qemu-xhci", QEMU_CAPS_DEVICE_QEMU_XHCI }, { "spapr-pci-host-bridge", QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE }, + { "vmcoreinfo", QEMU_CAPS_DEVICE_VMCOREINFO }, }; static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsVirtioBalloon[] = { diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index cacc2b77e..0cd9755a8 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -429,6 +429,7 @@ typedef enum { /* 270 */ QEMU_CAPS_VXHS, /* -drive file.driver=vxhs via query-qmp-schema */ QEMU_CAPS_VIRTIO_BLK_NUM_QUEUES, /* virtio-blk-*.num-queues */ + QEMU_CAPS_DEVICE_VMCOREINFO, /* -device vmcoreinfo */ QEMU_CAPS_LAST /* this must always be the last item */ } virQEMUCapsFlags; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 8708b79ed..b903b27b9 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -9727,6 +9727,29 @@ qemuBuildTPMCommandLine(virCommandPtr cmd, } +static int +qemuBuildVMCoreInfoCommandLine(virCommandPtr cmd, + const virDomainDef *def, + virQEMUCapsPtr qemuCaps) +{ + virTristateSwitch vmci = def->features[VIR_DOMAIN_FEATURE_VMCOREINFO]; + + if (vmci != VIR_TRISTATE_SWITCH_ON) { + return 0; + } + + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VMCOREINFO)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("vmcoreinfo is not available " + "with this QEMU binary")); + return -1; + } + + virCommandAddArgList(cmd, "-device", "vmcoreinfo", NULL); + return 0; +} + + static int qemuBuildPanicCommandLine(virCommandPtr cmd, const virDomainDef *def, @@ -10146,6 +10169,9 @@ qemuBuildCommandLine(virQEMUDriverPtr driver, if (qemuBuildNVRAMCommandLine(cmd, def, qemuCaps) < 0) goto error; + if (qemuBuildVMCoreInfoCommandLine(cmd, def, qemuCaps) < 0) + goto error; + if (snapshot) virCommandAddArgList(cmd, "-loadvm", snapshot->def->name, NULL); diff --git a/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args b/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args new file mode 100644 index 000000000..772e5a071 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.args @@ -0,0 +1,25 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/home/test \ +USER=test \ +LOGNAME=test \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-i686 \ +-name QEMUGuest1 \ +-S \ +-M pc \ +-m 214 \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-nographic \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/tmp/lib/domain--1-QEMUGuest1/monitor.sock,\ +server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=readline \ +-no-acpi \ +-boot c \ +-usb \ +-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-ide0-0-0 \ +-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 \ +-device vmcoreinfo diff --git a/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml b/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml new file mode 100644 index 000000000..f8e586531 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-vmcoreinfo.xml @@ -0,0 +1,28 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <vmcoreinfo/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-i686</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 2e07b85aa..7b9b846ef 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -2810,6 +2810,7 @@ mymain(void) DO_TEST_PARSE_ERROR("cpu-cache-emulate-l2", QEMU_CAPS_KVM); DO_TEST_PARSE_ERROR("cpu-cache-passthrough3", QEMU_CAPS_KVM); DO_TEST_PARSE_ERROR("cpu-cache-passthrough-l3", QEMU_CAPS_KVM); + DO_TEST("vmcoreinfo", QEMU_CAPS_DEVICE_VMCOREINFO); DO_TEST("user-aliases", QEMU_CAPS_KVM, QEMU_CAPS_DEVICE_CIRRUS_VGA, QEMU_CAPS_OBJECT_MEMORY_FILE, QEMU_CAPS_PIIX_DISABLE_S3, diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml new file mode 100644 index 000000000..a3922d630 --- /dev/null +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-vmcoreinfo.xml @@ -0,0 +1,38 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <vmcoreinfo/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-i686</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </memballoon> + </devices> +</domain> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index 5a282e5ff..9a7d460e5 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -1260,6 +1260,7 @@ mymain(void) DO_TEST("cpu-check-default-none2", NONE); DO_TEST("cpu-check-default-partial", NONE); DO_TEST("cpu-check-default-partial2", NONE); + DO_TEST("vmcoreinfo", NONE); DO_TEST("smartcard-host", NONE); DO_TEST("smartcard-host-certificates", NONE); -- 2.15.0.rc0.40.gaefcc5f6f

4 4

[libvirt] [PATCH 0/3] qemu: handle connect hangs in virDomainOpenChannel
by Nikolay Shirokovskiy 16 Nov '17

16 Nov '17

The problem is described in [1] in more details. From libvirt perspective we have whole driver became unresponsive if connect to channel unix socket hangs during virDomainOpenChannel. This series address this by first using job for the API call and second by introducing connect timeout so that domain itself don't became unresponsive indefinetily. [1] http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg03013.html Nikolay Shirokovskiy (3): util: virFDStreamConnectUNIX: add missing error report util: add 30s connection timeout to virFDStreamConnectUNIX qemu: use job to keep driver responsive on qemuDomainOpenChannel src/qemu/qemu_driver.c | 11 ++++++++++ src/util/virfdstream.c | 18 +++++++++++++++ src/util/virutil.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++ src/util/virutil.h | 2 ++ 4 files changed, 90 insertions(+) -- 1.8.3.1

1 3

[libvirt] [PATCH v2] storage: Resolve storage driver crash
by John Ferlan 16 Nov '17

16 Nov '17

Resolve a storage driver crash as a result of a long running storageVolCreateXML when the virStorageVolPoolRefreshThread is run as a result of when a storageVolUpload completed and ran the virStoragePoolObjClearVols without checking if the creation code was currently processing a buildVol after incrementing the driver->asyncjob count. The refreshThread will now check the pool asyncjob count before attempting to pursue the pool refresh. Adjust the documentation to describe the condition. Crash from valgrind is as follows (with a bit of editing): ==21309== Invalid read of size 8 ==21309== at 0x153E47AF: storageBackendUpdateVolTargetInfo ==21309== by 0x153E4C30: virStorageBackendUpdateVolInfo ==21309== by 0x153E52DE: virStorageBackendVolRefreshLocal ==21309== by 0x153DE29E: storageVolCreateXML ==21309== by 0x562035B: virStorageVolCreateXML ==21309== by 0x147366: remoteDispatchStorageVolCreateXML ... ==21309== Address 0x2590a720 is 64 bytes inside a block of size 336 free'd ==21309== at 0x4C2F2BB: free ==21309== by 0x54CB9FA: virFree ==21309== by 0x55BC800: virStorageVolDefFree ==21309== by 0x55BF1D8: virStoragePoolObjClearVols ==21309== by 0x153D967E: virStorageVolPoolRefreshThread ... ==21309== Block was alloc'd at ==21309== at 0x4C300A5: calloc ==21309== by 0x54CB483: virAlloc ==21309== by 0x55BDC1F: virStorageVolDefParseXML ==21309== by 0x55BDC1F: virStorageVolDefParseNode ==21309== by 0x55BE5A4: virStorageVolDefParse ==21309== by 0x153DDFF1: storageVolCreateXML ==21309== by 0x562035B: virStorageVolCreateXML ==21309== by 0x147366: remoteDispatchStorageVolCreateXML ... Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- v1: https://www.redhat.com/archives/libvir-list/2017-November/msg00198.html Changes since v1: - From review, remove the retry if Asyncjobs > 0 logic and replace with a VIR_DEBUG indicating not doing refresh due to Asyncjob running and just goto cleanup. - Adjust the virStorageVolUpload docs to note that an attempt will be made to refresh the pool. - Drop patch 2 which added the Asyncjobs > 0 check to the SCSI pool refresh thread. Since a SCSI pool doesn't support buildVol, the asyncjob count cannot be anything other than zero, so it's pointless. src/libvirt-storage.c | 3 ++- src/storage/storage_driver.c | 7 +++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 9ab0fe28ea..e4646cb80f 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -1632,7 +1632,8 @@ virStorageVolDownload(virStorageVolPtr vol, * another active stream is writing to the storage volume. * * When the data stream is closed whether the upload is successful - * or not the target storage pool will be refreshed to reflect pool + * or not an attempt will be made to refresh the target storage pool + * if an asynchronous build is not running in order to reflect pool * and volume changes as a result of the upload. Depending on * the target volume storage backend and the source stream type * for a successful upload, the target volume may take on the diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 2b7a299706..d209f5afb8 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2267,6 +2267,13 @@ virStorageVolPoolRefreshThread(void *opaque) goto cleanup; def = virStoragePoolObjGetDef(obj); + /* If some thread is building a new volume in the pool, then we cannot + * clear out all vols and refresh the pool. So we'll just pass. */ + if (virStoragePoolObjGetAsyncjobs(obj) > 0) { + VIR_DEBUG("Asyncjob in process, cannot refresh storage pool"); + goto cleanup; + } + if (!(backend = virStorageBackendForType(def->type))) goto cleanup; -- 2.13.6

2 1

[libvirt] [PATCH 0/2] Fix build with glibc-2.26 and clean up
by Martin Kletzander 16 Nov '17

16 Nov '17

Not pushed as build fix as glibc-2.26 is not that spread and the second patch is not a build fix. Review should be trivial, so hopefully almost no review bandwidth goes to waste ;) Martin Kletzander (2): build: Use XDR_CFLAGS in more places tests: Remove pointless _CFLAGS variables tests/Makefile.am | 28 +--------------------------- tools/Makefile.am | 2 +- 2 files changed, 2 insertions(+), 28 deletions(-) -- 2.15.0

2 3

[libvirt] [PATCH] qemu: taint domain if virDomainQemuAgentCommand API is used
by Pavel Hrdina 16 Nov '17

16 Nov '17

This is similar to the virDomainQemuMonitorCommand API, it can change the domain state in a way that libvirt may not understand. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/conf/domain_conf.c | 3 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_driver.c | 2 ++ 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index fffcc8e9da..55b3cb2430 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -100,7 +100,8 @@ VIR_ENUM_IMPL(virDomainTaint, VIR_DOMAIN_TAINT_LAST, "host-cpu", "hook-script", "cdrom-passthrough", - "custom-dtb"); + "custom-dtb", + "custom-ga-command"); VIR_ENUM_IMPL(virDomainVirt, VIR_DOMAIN_VIRT_LAST, "none", diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index e3f060b122..af5e379468 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -2444,6 +2444,7 @@ typedef enum { VIR_DOMAIN_TAINT_HOOK, /* Domain (possibly) changed via hook script */ VIR_DOMAIN_TAINT_CDROM_PASSTHROUGH,/* CDROM passthrough */ VIR_DOMAIN_TAINT_CUSTOM_DTB, /* Custom device tree blob was specified */ + VIR_DOMAIN_TAINT_CUSTOM_GA_COMMAND, /* Custom guest agent command */ VIR_DOMAIN_TAINT_LAST } virDomainTaintFlags; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 6132bc4a9a..3a0e3b6cec 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -18737,6 +18737,8 @@ qemuDomainQemuAgentCommand(virDomainPtr domain, if (!qemuDomainAgentAvailable(vm, true)) goto endjob; + qemuDomainObjTaint(driver, vm, VIR_DOMAIN_TAINT_CUSTOM_GA_COMMAND, NULL); + agent = qemuDomainObjEnterAgent(vm); ret = qemuAgentArbitraryCommand(agent, cmd, &result, timeout); qemuDomainObjExitAgent(vm, agent); -- 2.13.6

2 1

[libvirt] [PATCH 0/5] libvirtd: Adjustments to startup and cleanup processing
by John Ferlan 16 Nov '17

16 Nov '17

Essentially a followup from the review of: daemon: fix termination/reload issues https://www.redhat.com/archives/libvir-list/2017-October/msg01347.html and in particular patch 3/3, a review which has exteneded into Nov.: https://www.redhat.com/archives/libvir-list/2017-November/msg00066.html Make a few adjustments as noted in the patches as an alternative to patch 3/3 from above. The cleanup path is essentially reordered in inverse order of startup. Other adjustments include virObjectUnref after attempts to place object into domain or server hash tables or linked lists. John Ferlan (5): libvirtd: Move pid_file_fd setup to before run_dir libvirtd: Alter order of virNetDaemonNew libvirtd: Alter refcnt processing for domain server objects libvirtd: Alter refcnt processing for server program objects libvirtd: Fix order of cleanup processing daemon/libvirtd.c | 95 +++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 65 insertions(+), 30 deletions(-) -- 2.13.6

2 19

[libvirt] [PATCH 0/2] Fix storage driver crash
by John Ferlan 16 Nov '17

16 Nov '17

As described recently on list: https://www.redhat.com/archives/libvir-list/2017-November/msg00043.html and then discussed more in depth recently on OFTC #virt IRC, the thread run after a storageVolUpload is completed to refresh the volume and pool statistics could cause a crash if there was a storageVolCreateXML being run in a different thread that was taking a long time to build the volume. In the create/build case, the storage pool is unlocked while the build occurs, but before doing so "asyncjobs" is incremented to avoid certain other destructive operations such as PoolUndefine, PoolDestroy, PoolDelete, and PoolRefresh. The poolRefresh will clear and repopulate the pool volume list which is a bad thing to do since the create logic will have added to that list and be keeping track of what was added just in case the volume would need to be removed in the event of a build failure. The patches here will fix the case found and then alter the logic for another possible miscreant that would clear the volumes in a thread that needs to be run "later" than the normal processing for SCSI Fibre Channel volume recognition. John Ferlan (2): storage: Resolve storage driver crash scsi: Check for long running create in FCRefreshThread src/storage/storage_backend_scsi.c | 1 + src/storage/storage_driver.c | 9 +++++++++ 2 files changed, 10 insertions(+) -- 2.13.6

3 10

[libvirt] [PATCH go-xml] Add support for panic device
by zhenwei.pi 16 Nov '17

16 Nov '17

Add DomainAddressISA for panic device address. Add DomainPanic. Add test code. Signed-off-by: zhenwei.pi <zhenwei.pi(a)youruncloud.com> --- domain.go | 38 ++++++++++++++++++++++++++++++++++++++ domain_test.go | 28 +++++++++++++++++++++++++--- 2 files changed, 63 insertions(+), 3 deletions(-) diff --git a/domain.go b/domain.go index f4ef35c..8086e28 100644 --- a/domain.go +++ b/domain.go @@ -312,11 +312,16 @@ type DomainAddressDIMM struct { Base *uint64 `xml:"base,attr"` } +type DomainAddressISA struct { + Iobase *uint `xml:"iobase,attr"` +} + type DomainAddress struct { USB *DomainAddressUSB PCI *DomainAddressPCI Drive *DomainAddressDrive DIMM *DomainAddressDIMM + ISA *DomainAddressISA } type DomainConsole struct { @@ -403,6 +408,12 @@ type DomainMemBalloon struct { Address *DomainAddress `xml:"address"` } +type DomainPanic struct { + XMLName xml.Name `xml:"panic"` + Model string `xml:"model,attr"` + Address *DomainAddress `xml:"address"` +} + type DomainSoundCodec struct { Type string `xml:"type,attr"` } @@ -486,6 +497,7 @@ type DomainDeviceList struct { Videos []DomainVideo `xml:"video"` Channels []DomainChannel `xml:"channel"` MemBalloon *DomainMemBalloon `xml:"memballoon"` + Panics []DomainPanic `xml:"panic"` Sounds []DomainSound `xml:"sound"` RNGs []DomainRNG `xml:"rng"` Hostdevs []DomainHostdev `xml:"hostdev"` @@ -1058,6 +1070,16 @@ func (a *DomainAddressDIMM) MarshalXML(e *xml.Encoder, start xml.StartElement) e return nil } +func (a *DomainAddressISA) MarshalXML(e *xml.Encoder, start xml.StartElement) error { + start.Attr = append(start.Attr, xml.Attr{ + xml.Name{Local: "type"}, "isa", + }) + marshallUintAttr(&start, "iobase", a.Iobase, 16) + e.EncodeToken(start) + e.EncodeToken(start.End()) + return nil +} + func (a *DomainAddress) MarshalXML(e *xml.Encoder, start xml.StartElement) error { if a.USB != nil { return a.USB.MarshalXML(e, start) @@ -1067,6 +1089,8 @@ func (a *DomainAddress) MarshalXML(e *xml.Encoder, start xml.StartElement) error return a.Drive.MarshalXML(e, start) } else if a.DIMM != nil { return a.DIMM.MarshalXML(e, start) + } else if a.ISA != nil { + return a.ISA.MarshalXML(e, start) } else { return nil } @@ -1173,6 +1197,17 @@ func (a *DomainAddressDIMM) UnmarshalXML(d *xml.Decoder, start xml.StartElement) return nil } +func (a *DomainAddressISA) UnmarshalXML(d *xml.Decoder, start xml.StartElement) error { + for _, attr := range start.Attr { + if attr.Name.Local == "iobase" { + if err := unmarshallUintAttr(attr.Value, &a.Iobase, 16); err != nil { + return err + } + } + } + return nil +} + func (a *DomainAddress) UnmarshalXML(d *xml.Decoder, start xml.StartElement) error { var typ string d.Skip() @@ -1198,6 +1233,9 @@ func (a *DomainAddress) UnmarshalXML(d *xml.Decoder, start xml.StartElement) err } else if typ == "dimm" { a.DIMM = &DomainAddressDIMM{} return a.DIMM.UnmarshalXML(d, start) + } else if typ == "isa" { + a.ISA = &DomainAddressISA{} + return a.ISA.UnmarshalXML(d, start) } return nil diff --git a/domain_test.go b/domain_test.go index 1ad5125..31787a5 100644 --- a/domain_test.go +++ b/domain_test.go @@ -45,6 +45,10 @@ type DriveAddress struct { Unit uint } +type ISAAddress struct { + Iobase uint +} + var uhciIndex uint = 0 var uhciAddr = PCIAddress{0, 0, 1, 2} @@ -53,6 +57,7 @@ var ifaceAddr = PCIAddress{0, 0, 4, 0} var videoAddr = PCIAddress{0, 0, 5, 0} var fsAddr = PCIAddress{0, 0, 6, 0} var balloonAddr = PCIAddress{0, 0, 7, 0} +var panicAddr = ISAAddress{0x505} var duplexAddr = PCIAddress{0, 0, 8, 0} var hostdevSCSI = DriveAddress{0, 0, 3, 0} @@ -303,6 +308,19 @@ var domainTestData = []struct { }, }, }, + Panics: []DomainPanic{ + DomainPanic{ + Model: "hyperv", + }, + DomainPanic{ + Model: "isa", + Address: &DomainAddress{ + ISA: &DomainAddressISA{ + Iobase: &panicAddr.Iobase, + }, + }, + }, + }, Consoles: []DomainConsole{ DomainConsole{ Type: "pty", @@ -433,6 +451,10 @@ var domainTestData = []struct { ` <memballoon model="virtio">`, ` <address type="pci" domain="0x0" bus="0x0" slot="0x7" function="0x0"></address>`, ` </memballoon>`, + ` <panic model="hyperv"></panic>`, + ` <panic model="isa">`, + ` <address type="isa" iobase="0x505"></address>`, + ` </panic>`, ` <sound model="ich6">`, ` <codec type="duplex"></codec>`, ` <address type="pci" domain="0x0" bus="0x0" slot="0x8" function="0x0"></address>`, @@ -1725,9 +1747,9 @@ var domainTestData = []struct { /* Host Bootloader -- bhyve, Xen */ { Object: &Domain{ - Type: "bhyve", - Name: "test", - Bootloader: "/usr/local/sbin/grub-bhyve", + Type: "bhyve", + Name: "test", + Bootloader: "/usr/local/sbin/grub-bhyve", BootloaderArgs: "-r cd0 -m /tmp/test-device.map -M 1024M linuxguest", }, Expected: []string{ -- 2.7.4

2 1

[libvirt] PATCH go-xml : add virtualport support
by Karol Czeryna 16 Nov '17

16 Nov '17

Hi guys! Working with terraform libvirt plugin I discovered lack of openvswitch support - but in libvirt-go there is no support for virtualport entry.. this patch adds virtualport support. diff --git a/network.go b/network.go index 10c4dfc..0f072ec 100644 --- a/network.go +++ b/network.go @@ -36,6 +36,16 @@ type NetworkBridge struct { MACTableManager string `xml:"macTableManager,attr,omitempty"` } +type VirtualPortParameters struct { + InterfaceID string `xml:"interfaceid,attr,omitempty"` + ProfileID string `xml:"profileid,attr,omitempty"` +} + +type VirtualPort struct { + Type string `xml:"type,attr,omitempty"` + Parameters []VirtualPortParameters `xml:"parameters,omitempty"` +} + type NetworkDomain struct { Name string `xml:"name,attr,omitempty"` LocalOnly string `xml:"localOnly,attr,omitempty"` @@ -152,6 +162,7 @@ type Network struct { UUID string `xml:"uuid,omitempty"` MAC *NetworkMAC `xml:"mac"` Bridge *NetworkBridge `xml:"bridge"` + VirtualPort *VirtualPort `xml:"virtualport"` Forward *NetworkForward `xml:"forward"` Domain *NetworkDomain `xml:"domain"` IPs []NetworkIP `xml:"ip"` diff --git a/network_test.go b/network_test.go index 3efb278..10cce66 100644 --- a/network_test.go +++ b/network_test.go @@ -65,6 +65,14 @@ var networkTestData = []struct { Bridge: &NetworkBridge{ Name: "virbr0", }, + VirtualPort: &VirtualPort{ + Type: "openvswitch", + Parameters: []VirtualPortParameters{ + VirtualPortParameters{ + InterfaceID: "09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f", + }, + }, + }, Forward: &NetworkForward{ Mode: "nat", NAT: &NetworkForwardNAT{ @@ -175,6 +183,9 @@ var networkTestData = []struct { `<network>`, ` <name>test</name>`, ` <bridge name="virbr0"></bridge>`, + ` <virtualport type="openvswitch">`, + ` <parameters interfaceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"></parameters>`, + ` </virtualport>`, ` <forward mode="nat">`, ` <nat>`, ` <address start="1.2.3.4" end="1.2.3.10"></address>`, Best, Karol

2 1

[libvirt] [PATCH go-xml] Support network backed serial interfaces
by Jeroen Simonetti 16 Nov '17

16 Nov '17

Adds network backing for a DomainChardevSource and protocol selection for serial device of type tcp. Signed-off-by: Jeroen Simonetti <jeroen(a)simonetti.nl> --- domain.go | 26 +++++++++++++++++--------- domain_test.go | 26 +++++++++++++++++++++++--- 2 files changed, 40 insertions(+), 12 deletions(-) diff --git a/domain.go b/domain.go index f4ef35c..47e9dc6 100644 --- a/domain.go +++ b/domain.go @@ -256,9 +256,12 @@ type DomainInterface struct { } type DomainChardevSource struct { - Mode string `xml:"mode,attr,omitempty"` - Path string `xml:"path,attr"` - Append string `xml:"append,attr,omitempty"` + Mode string `xml:"mode,attr,omitempty"` + Path string `xml:"path,attr,omitempty"` + Append string `xml:"append,attr,omitempty"` + Host string `xml:"host,attr,omitempty"` + Service string `xml:"service,attr,omitempty"` + TLS string `xml:"tls,attr,omitempty"` } type DomainChardevTarget struct { @@ -329,12 +332,17 @@ type DomainConsole struct { } type DomainSerial struct { - XMLName xml.Name `xml:"serial"` - Type string `xml:"type,attr"` - Source *DomainChardevSource `xml:"source"` - Target *DomainSerialTarget `xml:"target"` - Alias *DomainAlias `xml:"alias"` - Address *DomainAddress `xml:"address"` + XMLName xml.Name `xml:"serial"` + Type string `xml:"type,attr"` + Source *DomainChardevSource `xml:"source"` + Protocol *DomainSerialProtocol `xml:"protocol"` + Target *DomainSerialTarget `xml:"target"` + Alias *DomainAlias `xml:"alias"` + Address *DomainAddress `xml:"address"` +} + +type DomainSerialProtocol struct { + Type string `xml:"type,attr"` } type DomainChannel struct { diff --git a/domain_test.go b/domain_test.go index 1ad5125..99d5022 100644 --- a/domain_test.go +++ b/domain_test.go @@ -330,6 +330,21 @@ var domainTestData = []struct { Port: &serialPort, }, }, + DomainSerial{ + Type: "tcp", + Source: &DomainChardevSource{ + Mode: "bind", + Host: "127.0.0.1", + Service: "1234", + TLS: "yes", + }, + Protocol: &DomainSerialProtocol{ + Type: "telnet", + }, + Target: &DomainSerialTarget{ + Port: &serialPort, + }, + }, }, Channels: []DomainChannel{ DomainChannel{ @@ -415,6 +430,11 @@ var domainTestData = []struct { ` <source path="/tmp/serial.log" append="off"></source>`, ` <target port="0"></target>`, ` </serial>`, + ` <serial type="tcp">`, + ` <source mode="bind" host="127.0.0.1" service="1234" tls="yes"></source>`, + ` <protocol type="telnet"></protocol>`, + ` <target port="0"></target>`, + ` </serial>`, ` <console type="pty">`, ` <target type="virtio" port="0"></target>`, ` </console>`, @@ -1725,9 +1745,9 @@ var domainTestData = []struct { /* Host Bootloader -- bhyve, Xen */ { Object: &Domain{ - Type: "bhyve", - Name: "test", - Bootloader: "/usr/local/sbin/grub-bhyve", + Type: "bhyve", + Name: "test", + Bootloader: "/usr/local/sbin/grub-bhyve", BootloaderArgs: "-r cd0 -m /tmp/test-device.map -M 1024M linuxguest", }, Expected: []string{ -- 2.15.0

2 1

[libvirt] [PATCH] virsh: fixing wrong datatype of 'set-lifcycle-action' command options.
by Julio Faracco 16 Nov '17

16 Nov '17

The 'set-lifcycle-action' is throwing a weird error after executing it with the '--help' option. The command output is showing the options 'type' and 'action' are as optional, but they aren't. Both are required. virsh # set-lifecycle-action --help ... SYNOPSIS set-lifecycle-action <domain> [--type <string>] [--action <string>] ... ... OPTIONS [--domain] <string> domain name, id or uuid error: internal error: bad options in command: 'set-lifecycle-action' After applying this patch, both arguments are required now. virsh # set-lifecycle-action --help ... SYNOPSIS set-lifecycle-action <domain> <type> <action> [--config] ... Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1509870 Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com> --- tools/virsh-domain.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 42d5526..bf96f2e 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -5532,12 +5532,12 @@ static const vshCmdInfo info_setLifecycleAction[] = { static const vshCmdOptDef opts_setLifecycleAction[] = { VIRSH_COMMON_OPT_DOMAIN_FULL, {.name = "type", - .type = VSH_OT_STRING, + .type = VSH_OT_DATA, .flags = VSH_OFLAG_REQ, .help = N_("lifecycle type to modify") }, {.name = "action", - .type = VSH_OT_STRING, + .type = VSH_OT_DATA, .flags = VSH_OFLAG_REQ, .help = N_("lifecycle action to set") }, -- 2.7.4

2 1

[libvirt] [PATCH] qemu: don't goto cleanup when qemuDomainRemoveDevice failed at function qemuProcessUpdateDevices
by xinhua.Cao 16 Nov '17

16 Nov '17

Function qemuProcessUpdateDevices was called at qemuProcessReconnect when we detach net device lively and killed libvirtd service at middle. qemu detached the device but libvirtd don't save it at runDir. when libvirtd restart, libvirtd will detach net device but qemu will return fail because device was not found. then libvirtd qemuProcessReconnect failed and goto error. libvirtd kill qemu. To avoid qemu is killed by libvirtd, qemuDomainRemoveDevice will not return failed. --- src/qemu/qemu_process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 6d242b1..9f9393b 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3234,7 +3234,7 @@ qemuProcessUpdateDevices(virQEMUDriverPtr driver, if (!virStringListHasString(qemuDevices, *tmp) && virDomainDefFindDevice(vm->def, *tmp, &dev, false) == 0 && qemuDomainRemoveDevice(driver, vm, &dev) < 0) { - goto cleanup; + VIR_WARN("failed to remove device %s at reconnect process", *tmp); } tmp++; } -- 2.8.3

1 0

[libvirt] [PATCH 0/2] Add 'l2-cache-size' property to specify maximum size of the L2 table cache for qcow2 image
by Lin Ma 16 Nov '17

16 Nov '17

Lin Ma (2): caps: Add capability for maximum size of the qcow2 L2 table cache qemu: Add support for 'l2-cache-size' property of qcow2 docs/formatdomain.html.in | 11 +++++++ docs/schemas/domaincommon.rng | 5 ++++ src/conf/domain_conf.c | 11 +++++++ src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 5 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 18 ++++++++++++ .../caps_2.10.0-gicv2.aarch64.xml | 1 + .../caps_2.10.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + .../qemuxml2argv-disk-drive-l2-cache-size.args | 24 +++++++++++++++ .../qemuxml2argv-disk-drive-l2-cache-size.xml | 34 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 2 ++ .../qemuxml2xmlout-disk-drive-l2-cache-size.xml | 34 ++++++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 29 files changed, 164 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-l2-cache-size.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-l2-cache-size.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-l2-cache-size.xml -- 2.9.2

4 7

[libvirt] [PATCH] qemuBuildDeviceAddressStr: Prefer default alias for PCI bus
by Michal Privoznik 15 Nov '17

15 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=1434451 Just like in 9324f67a572f9b32 we need to put default pci-root alias onto the command line instead of the one provided by user. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_command.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index eb72db33b..affad43e1 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -318,16 +318,25 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_PCI && cont->idx == info->addr.pci.bus) { - contAlias = cont->info.alias; contIsPHB = virDomainControllerIsPSeriesPHB(cont); contTargetIndex = cont->opts.pciopts.targetIndex; - if (!contAlias) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Device alias was not set for PCI " - "controller with index %u required " - "for device at address %s"), - info->addr.pci.bus, devStr); - goto cleanup; + + /* When domain has builtin pci-root controller we don't put it + * onto cmd line. Therefore we can't set its alias. In that + * case, use the default one. */ + if (!qemuDomainIsPSeries(domainDef) && + cont->model == VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT) { + contAlias = "pci.0"; + } else { + contAlias = cont->info.alias; + if (!contAlias) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Device alias was not set for PCI " + "controller with index %u required " + "for device at address %s"), + info->addr.pci.bus, devStr); + goto cleanup; + } } break; } -- 2.13.6

2 1

[libvirt] [PATCH 0/2] virtlo(ck|g)d: Two simple improvements
by Erik Skultety 15 Nov '17

15 Nov '17

Erik Skultety (2): daemon: virtlogd: Drop the server shortcut ref pointer daemon: virtlockd: Call virNetDaemonGetServer regardless of post exec src/locking/lock_daemon.c | 5 +++-- src/logging/log_daemon.c | 54 ++++++++++++++++++++++++++++------------------- 2 files changed, 35 insertions(+), 24 deletions(-) -- 2.13.6

2 3

[libvirt] [PATCH] hooks: Fix a wrong description
by Chen Hanxiao 15 Nov '17

15 Nov '17

From: Chen Hanxiao <chenhanxiao(a)gmail.com> In the definition of virHookQemuOpType and virHookNetworkOpType, we should use 'stopped' rather than 'shutdown'. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- docs/hooks.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/hooks.html.in b/docs/hooks.html.in index 05156c30c..2c4c39b77 100644 --- a/docs/hooks.html.in +++ b/docs/hooks.html.in @@ -316,7 +316,7 @@ executes <b>prior</b> to the object (guest or network) being created. This allows the object start operation to be aborted if the script returns indicating failure.<br/><br/></li> - <li>The "shutdown" operation for the guest and network hook scripts, + <li>The "stopped" operation for the guest and network hook scripts, executes <b>after</b> the object (guest or network) has stopped. If the hook script indicates failure in its return, the shut down of the object cannot be aborted because it has already been performed. -- 2.13.6

2 1

[libvirt] [PATCH] qemuBuildDriveDevStr: Prefer default aliases for IDE bus
by Michal Privoznik 14 Nov '17

14 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=1434451 When testing user aliases it was discovered that for 440fx machine type which has default IDE bus builtin, domain cannot start if IDE controller has the user provided alias. This is because for 440fx we don't put the IDE controller onto the command line (since it is builtin) and therefore any device that is plugged onto the bus must use the default alias. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_command.c | 14 +++++++++++--- tests/qemuxml2argvdata/qemuxml2argv-user-aliases.args | 4 ++-- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 364196783..6cc77df2e 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1886,9 +1886,17 @@ qemuBuildDriveDevStr(const virDomainDef *def, virBufferAddLit(&opt, "ide-drive"); } - if (!(contAlias = virDomainControllerAliasFind(def, VIR_DOMAIN_CONTROLLER_TYPE_IDE, - disk->info.addr.drive.controller))) - goto error; + /* When domain has builtin IDE controller we don't put it onto cmd + * line. Therefore we can't set its alias. In that case, use the + * default one. */ + if (qemuDomainHasBuiltinIDE(def)) { + contAlias = "ide"; + } else { + if (!(contAlias = virDomainControllerAliasFind(def, + VIR_DOMAIN_CONTROLLER_TYPE_IDE, + disk->info.addr.drive.controller))) + goto error; + } virBufferAsprintf(&opt, ",bus=%s.%d,unit=%d", contAlias, disk->info.addr.drive.bus, diff --git a/tests/qemuxml2argvdata/qemuxml2argv-user-aliases.args b/tests/qemuxml2argvdata/qemuxml2argv-user-aliases.args index 62fbd567b..1719c1bc8 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-user-aliases.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-user-aliases.args @@ -44,8 +44,8 @@ id=drive-ua-myEncryptedDisk1 \ id=ua-myEncryptedDisk1 \ -drive file=/home/zippy/tmp/install-amd64-minimal-20140619.iso,format=raw,\ if=none,media=cdrom,id=drive-ua-WhatAnAwesomeCDROM,readonly=on,cache=none \ --device ide-drive,bus=ua-DoesAnybodyStillUseIDE.1,unit=0,\ -drive=drive-ua-WhatAnAwesomeCDROM,id=ua-WhatAnAwesomeCDROM \ +-device ide-drive,bus=ide.1,unit=0,drive=drive-ua-WhatAnAwesomeCDROM,\ +id=ua-WhatAnAwesomeCDROM \ -device virtio-net-pci,vlan=0,id=ua-CheckoutThisNIC,mac=52:54:00:d6:c0:0b,\ bus=pci.0,addr=0x3 \ -net tap,fd=3,vlan=0,name=hostua-CheckoutThisNIC \ -- 2.13.6

3 4

[libvirt] [PATCH 0/4] qemu: Enable configuration of HPT resizing for pSeries guests
by Andrea Bolognani 14 Nov '17

14 Nov '17

Applies on top of https://www.redhat.com/archives/libvir-list/2017-November/msg00176.html Andrea Bolognani (4): qemu: Enable configuration of HPT resizing for pSeries guests tests: Add tests for configuration of HPT resizing docs: Document configuration of HPT resizing news: Update for configuration of HPT resizing docs/formatdomain.html.in | 13 +++++- docs/news.xml | 10 +++++ docs/schemas/domaincommon.rng | 15 +++++++ src/conf/domain_conf.c | 46 +++++++++++++++++++++- src/conf/domain_conf.h | 12 ++++++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 8 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 20 ++++++++++ src/qemu/qemu_domain.c | 8 ++++ tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + ...qemuxml2argv-pseries-hpt-resizing-disabled.args | 20 ++++++++++ .../qemuxml2argv-pseries-hpt-resizing-disabled.xml | 19 +++++++++ .../qemuxml2argv-pseries-hpt-resizing-enabled.args | 20 ++++++++++ .../qemuxml2argv-pseries-hpt-resizing-enabled.xml | 19 +++++++++ ...l2argv-pseries-hpt-resizing-invalid-machine.xml | 18 +++++++++ ...qemuxml2argv-pseries-hpt-resizing-required.args | 20 ++++++++++ .../qemuxml2argv-pseries-hpt-resizing-required.xml | 19 +++++++++ tests/qemuxml2argvtest.c | 20 ++++++++++ ...emuxml2xmlout-pseries-hpt-resizing-disabled.xml | 28 +++++++++++++ ...qemuxml2xmlout-pseries-hpt-resizing-enabled.xml | 28 +++++++++++++ ...emuxml2xmlout-pseries-hpt-resizing-required.xml | 28 +++++++++++++ tests/qemuxml2xmltest.c | 13 ++++++ 23 files changed, 385 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hpt-resizing-disabled.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hpt-resizing-disabled.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hpt-resizing-enabled.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hpt-resizing-enabled.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hpt-resizing-invalid-machine.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hpt-resizing-required.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hpt-resizing-required.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-hpt-resizing-disabled.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-hpt-resizing-enabled.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-hpt-resizing-required.xml -- 2.13.6

2 10

[libvirt] [PATCH] vircapstest: Avoid (im)possible strcmp call with NULL argument
by Jiri Denemark 14 Nov '17

14 Nov '17

Some compiler may get confused and decide we are calling strcmp with NULL argument from test_virCapsDomainDataLookupLXC. Although this does not really happen since the call is guarded with (data->machinetype != expect_machinetype), using STRNEQ_NULLABLE is easier to understand, less fragile, and doing so makes sure strcmp is never called with NULL argument. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- tests/vircapstest.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tests/vircapstest.c b/tests/vircapstest.c index 95829133d0..05ec802f35 100644 --- a/tests/vircapstest.c +++ b/tests/vircapstest.c @@ -188,11 +188,10 @@ doCapsCompare(virCapsPtr caps, goto error; } - if (data->machinetype != expect_machinetype && - STRNEQ(data->machinetype, expect_machinetype)) { + if (STRNEQ_NULLABLE(data->machinetype, expect_machinetype)) { fprintf(stderr, "data->machinetype=%s doesn't match " "expect_machinetype=%s\n", - data->machinetype, expect_machinetype); + NULLSTR(data->machinetype), NULLSTR(expect_machinetype)); goto error; } -- 2.15.0

2 1

[libvirt] [PATCH go-xml] Add support for panic device
by zhenwei.pi 14 Nov '17

14 Nov '17

Add DomainAddressISA for panic device address. Add DomainPanic. Add test code. Signed-off-by: zhenwei.pi <zhenwei.pi(a)youruncloud.com> --- domain.go | 38 ++++++++++++++++++++++++++++++++++++++ domain_test.go | 28 +++++++++++++++++++++++++--- 2 files changed, 63 insertions(+), 3 deletions(-) diff --git a/domain.go b/domain.go index f4ef35c..8086e28 100644 --- a/domain.go +++ b/domain.go @@ -312,11 +312,16 @@ type DomainAddressDIMM struct { Base *uint64 `xml:"base,attr"` } +type DomainAddressISA struct { + Iobase *uint `xml:"iobase,attr"` +} + type DomainAddress struct { USB *DomainAddressUSB PCI *DomainAddressPCI Drive *DomainAddressDrive DIMM *DomainAddressDIMM + ISA *DomainAddressISA } type DomainConsole struct { @@ -403,6 +408,12 @@ type DomainMemBalloon struct { Address *DomainAddress `xml:"address"` } +type DomainPanic struct { + XMLName xml.Name `xml:"panic"` + Model string `xml:"model,attr"` + Address *DomainAddress `xml:"address"` +} + type DomainSoundCodec struct { Type string `xml:"type,attr"` } @@ -486,6 +497,7 @@ type DomainDeviceList struct { Videos []DomainVideo `xml:"video"` Channels []DomainChannel `xml:"channel"` MemBalloon *DomainMemBalloon `xml:"memballoon"` + Panics []DomainPanic `xml:"panic"` Sounds []DomainSound `xml:"sound"` RNGs []DomainRNG `xml:"rng"` Hostdevs []DomainHostdev `xml:"hostdev"` @@ -1058,6 +1070,16 @@ func (a *DomainAddressDIMM) MarshalXML(e *xml.Encoder, start xml.StartElement) e return nil } +func (a *DomainAddressISA) MarshalXML(e *xml.Encoder, start xml.StartElement) error { + start.Attr = append(start.Attr, xml.Attr{ + xml.Name{Local: "type"}, "isa", + }) + marshallUintAttr(&start, "iobase", a.Iobase, 16) + e.EncodeToken(start) + e.EncodeToken(start.End()) + return nil +} + func (a *DomainAddress) MarshalXML(e *xml.Encoder, start xml.StartElement) error { if a.USB != nil { return a.USB.MarshalXML(e, start) @@ -1067,6 +1089,8 @@ func (a *DomainAddress) MarshalXML(e *xml.Encoder, start xml.StartElement) error return a.Drive.MarshalXML(e, start) } else if a.DIMM != nil { return a.DIMM.MarshalXML(e, start) + } else if a.ISA != nil { + return a.ISA.MarshalXML(e, start) } else { return nil } @@ -1173,6 +1197,17 @@ func (a *DomainAddressDIMM) UnmarshalXML(d *xml.Decoder, start xml.StartElement) return nil } +func (a *DomainAddressISA) UnmarshalXML(d *xml.Decoder, start xml.StartElement) error { + for _, attr := range start.Attr { + if attr.Name.Local == "iobase" { + if err := unmarshallUintAttr(attr.Value, &a.Iobase, 16); err != nil { + return err + } + } + } + return nil +} + func (a *DomainAddress) UnmarshalXML(d *xml.Decoder, start xml.StartElement) error { var typ string d.Skip() @@ -1198,6 +1233,9 @@ func (a *DomainAddress) UnmarshalXML(d *xml.Decoder, start xml.StartElement) err } else if typ == "dimm" { a.DIMM = &DomainAddressDIMM{} return a.DIMM.UnmarshalXML(d, start) + } else if typ == "isa" { + a.ISA = &DomainAddressISA{} + return a.ISA.UnmarshalXML(d, start) } return nil diff --git a/domain_test.go b/domain_test.go index 1ad5125..31787a5 100644 --- a/domain_test.go +++ b/domain_test.go @@ -45,6 +45,10 @@ type DriveAddress struct { Unit uint } +type ISAAddress struct { + Iobase uint +} + var uhciIndex uint = 0 var uhciAddr = PCIAddress{0, 0, 1, 2} @@ -53,6 +57,7 @@ var ifaceAddr = PCIAddress{0, 0, 4, 0} var videoAddr = PCIAddress{0, 0, 5, 0} var fsAddr = PCIAddress{0, 0, 6, 0} var balloonAddr = PCIAddress{0, 0, 7, 0} +var panicAddr = ISAAddress{0x505} var duplexAddr = PCIAddress{0, 0, 8, 0} var hostdevSCSI = DriveAddress{0, 0, 3, 0} @@ -303,6 +308,19 @@ var domainTestData = []struct { }, }, }, + Panics: []DomainPanic{ + DomainPanic{ + Model: "hyperv", + }, + DomainPanic{ + Model: "isa", + Address: &DomainAddress{ + ISA: &DomainAddressISA{ + Iobase: &panicAddr.Iobase, + }, + }, + }, + }, Consoles: []DomainConsole{ DomainConsole{ Type: "pty", @@ -433,6 +451,10 @@ var domainTestData = []struct { ` <memballoon model="virtio">`, ` <address type="pci" domain="0x0" bus="0x0" slot="0x7" function="0x0"></address>`, ` </memballoon>`, + ` <panic model="hyperv"></panic>`, + ` <panic model="isa">`, + ` <address type="isa" iobase="0x505"></address>`, + ` </panic>`, ` <sound model="ich6">`, ` <codec type="duplex"></codec>`, ` <address type="pci" domain="0x0" bus="0x0" slot="0x8" function="0x0"></address>`, @@ -1725,9 +1747,9 @@ var domainTestData = []struct { /* Host Bootloader -- bhyve, Xen */ { Object: &Domain{ - Type: "bhyve", - Name: "test", - Bootloader: "/usr/local/sbin/grub-bhyve", + Type: "bhyve", + Name: "test", + Bootloader: "/usr/local/sbin/grub-bhyve", BootloaderArgs: "-r cd0 -m /tmp/test-device.map -M 1024M linuxguest", }, Expected: []string{ -- 2.7.4

1 0

[libvirt] [PATCH] virhostcpu: Report correct topolgy info on host with deconfigured core
by Nitesh Konkar 14 Nov '17

14 Nov '17

The host which has a deconfigured core is treated as though the topology is not correct and the SMT is not reliable. Which is not true, so report the topology correctly by detecting if the host is actually in a proper SMT mode with the deconfigured core. Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> --- Steps to reproduce: This is what `virsh capabilities` shows in a 10-core POWER8 system (8 threads per core): $ virsh capabilities | grep threads <topology sockets='1' cores='10' threads='8'/> There are 10 CPUs online, given SMT is off (`ppc64_cpu --smt=off`): $ cat /sys/devices/system/cpu/online 0,8,16,24,32,40,48,56,64,72 Now, if one core is disabled/offlined (e.g., the last one, number 72)... $ echo 0 | sudo tee /sys/devices/system/cpu/cpu72/online Then this messes up with `virsh capabilities` number of cores (now 80) and threads (now 1) : $ virsh capabilities | grep threads <topology sockets='1' cores='80' threads='1'/> It goes back to normal if that CPU is enabled/onlined again: $ echo 1 | sudo tee /sys/devices/system/cpu/cpu72/online 1 $ virsh capabilities | grep threads <topology sockets='1' cores='10' threads='8'/> src/util/virhostcpu.c | 8 ++++++-- tests/virhostcpudata/linux-ppc64-deconf-cpus.expected | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index c485a97..5301583 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -524,6 +524,7 @@ virHostCPUGetInfoPopulateLinux(FILE *cpuinfo, DIR *nodedir = NULL; struct dirent *nodedirent = NULL; int nodecpus, nodecores, nodesockets, nodethreads, offline = 0; + int total_online_cpus = 0; int threads_per_subcore = 0; unsigned int node; int ret = -1; @@ -623,6 +624,8 @@ virHostCPUGetInfoPopulateLinux(FILE *cpuinfo, if (!online_cpus_map) goto cleanup; + total_online_cpus = virBitmapCountBits(online_cpus_map); + /* OK, we've parsed clock speed out of /proc/cpuinfo. Get the * core, node, socket, thread and topology information from /sys */ @@ -746,10 +749,11 @@ virHostCPUGetInfoPopulateLinux(FILE *cpuinfo, * the nodeinfo structure isn't designed to carry the full topology so * we're going to lie about the detected topology to notify the user * to check the host capabilities for the actual topology. */ - if ((*nodes * + if (((*nodes * *sockets * *cores * - *threads) != (*cpus + offline)) { + *threads) != (*cpus + offline)) && + ((total_online_cpus * threads_per_subcore) != (*cpus + offline))) { *nodes = 1; *sockets = 1; *cores = *cpus + offline; diff --git a/tests/virhostcpudata/linux-ppc64-deconf-cpus.expected b/tests/virhostcpudata/linux-ppc64-deconf-cpus.expected index 113bfa8..7998a8f 100644 --- a/tests/virhostcpudata/linux-ppc64-deconf-cpus.expected +++ b/tests/virhostcpudata/linux-ppc64-deconf-cpus.expected @@ -1 +1 @@ -CPUs: 80/80, MHz: 3690, Nodes: 1, Sockets: 1, Cores: 80, Threads: 1 +CPUs: 80/96, MHz: 3690, Nodes: 4, Sockets: 1, Cores: 3, Threads: 8 -- 1.8.3.1

1 0

[libvirt] [PATCH v2 1/2] remote: set neventCallbacks to zero at DEREG_CB
by xinhua.Cao 14 Nov '17

14 Nov '17

set neventCallbacks to zero after VIR_FREE(eventCallbacks) was called --- daemon/remote.c | 1 + 1 file changed, 1 insertion(+) diff --git a/daemon/remote.c b/daemon/remote.c index 07557e9..cbcb6e8 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -1686,6 +1686,7 @@ void remoteRelayConnectionClosedEvent(virConnectPtr conn ATTRIBUTE_UNUSED, int r VIR_WARN("unexpected %s event deregister failure", name); \ } \ VIR_FREE(eventCallbacks); \ + neventCallbacks = 0; \ } while (0); /* -- 2.8.3

3 8

[libvirt] [PATCH] qemu: Properly report errors from qemuDomainFixupCPUs
by Jiri Denemark 13 Nov '17

13 Nov '17

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 6d7827220e..a36e157529 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -10227,7 +10227,7 @@ qemuDomainFixupCPUs(virDomainObjPtr vm, virCPUDefPtr fixedCPU = NULL; virCPUDefPtr fixedOrig = NULL; virArch arch = vm->def->os.arch; - int ret = 0; + int ret = -1; if (!ARCH_IS_X86(arch)) return 0; -- 2.15.0

2 1

[libvirt] [PATCH] Revert "virNetDevSupportBandwidth: Enable QoS for vhostuser"
by Michal Privoznik 13 Nov '17

13 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=1497410 This reverts commit bc8a99ef06417a2303ccab455f9f045e2a617916. The vhostuser is not a TAP. Therefore our QoS code is not able to set any bandwidth. I don't really understand what I was thinking. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/netdev_bandwidth_conf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/netdev_bandwidth_conf.h b/src/conf/netdev_bandwidth_conf.h index c37828065..30f988953 100644 --- a/src/conf/netdev_bandwidth_conf.h +++ b/src/conf/netdev_bandwidth_conf.h @@ -46,9 +46,9 @@ static inline bool virNetDevSupportBandwidth(virDomainNetType type) case VIR_DOMAIN_NET_TYPE_NETWORK: case VIR_DOMAIN_NET_TYPE_DIRECT: case VIR_DOMAIN_NET_TYPE_ETHERNET: - case VIR_DOMAIN_NET_TYPE_VHOSTUSER: return true; case VIR_DOMAIN_NET_TYPE_USER: + case VIR_DOMAIN_NET_TYPE_VHOSTUSER: case VIR_DOMAIN_NET_TYPE_SERVER: case VIR_DOMAIN_NET_TYPE_CLIENT: case VIR_DOMAIN_NET_TYPE_MCAST: -- 2.13.6

2 2

[libvirt] [PATCH] conf: Fix message when maximum vCPU count is less than current
by Peter Krempa 13 Nov '17

13 Nov '17

Reword the message and drop the numbers (which were reversed) from it so that it actually makes sense. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1509151 --- src/conf/domain_conf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 77c20c697..64f8df1be 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -1505,9 +1505,9 @@ virDomainDefSetVcpus(virDomainDefPtr def, size_t i; if (vcpus > def->maxvcpus) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("maxvcpus must not be less than current vcpus (%u < %zu)"), - vcpus, def->maxvcpus); + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("maximum vCPU count must not be less than current " + "vCPU count")); return -1; } -- 2.14.3

2 2

[libvirt] [PATCH] news: add entries for specifying distance between vNUMA cells
by Jim Fehlig 13 Nov '17

13 Nov '17

Add two new entries under new features for 3.10.0. One advertising support for specifying distance between vNUMA cells and another advertising Xen's support for vNUMA configuration. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- docs/news.xml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index c7023c43b..3966710ee 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -35,6 +35,26 @@ <libvirt> <release version="v3.10.0" date="unreleased"> <section title="New features"> + <change> + <summary> + conf: Support defining distances between virtual NUMA cells + </summary> + <description> + A NUMA hardware architecture supports the notion of distances + between NUMA cells. This can now be specified using the + <code><distances></code> element within the NUMA cell + configuration. + </description> + </change> + <change> + <summary> + Xen: Support defining vNUMA topology + </summary> + <description> + Xen now supports defining a virtual NUMA topology for VMs, + including specifying distances between NUMA cells. + </description> + </change> </section> <section title="Improvements"> <change> -- 2.15.0

2 1

[libvirt] [PATCH v6 0/4] numa: describe sibling nodes distances
by Wim Ten Have 13 Nov '17

13 Nov '17

From: Wim ten Have <wim.ten.have(a)oracle.com> This patch extends guest domain administration adding support to advertise node sibling distances when configuring NUMA guests also referred to as vNUMA (Virtual NUMA). NUMA (Non-Uniform Memory Access), a method of configuring a cluster of nodes within a single multiprocessing system such that it shares processor local memory amongst others improving performance and the ability of the system to be expanded. A NUMA system could be illustrated as shown below. Within this 4-NODE system, every socket is equipped with its own distinct memory and some with I/O. Access to memory or I/O on remote nodes is only possible through the "Interconnect". This results in different performance for local and remote resources. In contrast to NUMA we recognize the flat SMP system where no concept of local or remote resource exists. The disadvantage of high socket count SMP systems is that the shared bus can easily become a performance bottleneck under high activity. +-------------+-------+ +-------+-------------+ |NODE0| | | | | |NODE3| | | CPU00 | CPU03 | | CPU12 | CPU15 | | | | | | | | | | | Mem +--- Socket0 ---<-------->--- Socket3 ---+ Mem | | | | | | | | | +-----+ CPU01 | CPU02 | | CPU13 | CPU14 | | | I/O | | | | | | | +-----+-------^-------+ +-------^-------+-----+ | | | Interconnect | | | +-------------v-------+ +-------v-------------+ |NODE1| | | | | |NODE2| | | CPU04 | CPU07 | | CPU08 | CPU11 | | | | | | | | | | | Mem +--- Socket1 ---<-------->--- Socket2 ---+ Mem | | | | | | | | | +-----+ CPU05 | CPU06 | | CPU09 | CPU10 | | | I/O | | | | | | | +-----+-------+-------+ +-------+-------+-----+ NUMA adds an intermediate level of memory shared amongst a few cores per socket as illustrated above, so that data accesses do not have to travel over a single bus. Unfortunately the way NUMA does this adds its own limitations. This, as visualized in the illustration above, happens when data is stored in memory associated with Socket2 and is accessed by a CPU (core) in Socket0. The processors use the "Interconnect" path to access resource on other nodes. These "Interconnect" hops add data access delays. It is therefore in our interest to describe the relative distances between nodes. The relative distances between nodes are described in the system's SLIT (System Locality Distance Information Table) which is part of the ACPI (Advanced Configuration and Power Interface) specification. On Linux systems the SLIT detail can be listed with help of the 'numactl -H' command. The above guest would show the following output. [root@f25 ~]# numactl -H available: 4 nodes (0-3) node 0 cpus: 0 1 2 3 node 0 size: 2007 MB node 0 free: 1931 MB node 1 cpus: 4 5 6 7 node 1 size: 1951 MB node 1 free: 1902 MB node 2 cpus: 8 9 10 11 node 2 size: 1998 MB node 2 free: 1910 MB node 3 cpus: 12 13 14 15 node 3 size: 2015 MB node 3 free: 1907 MB node distances: node 0 1 2 3 0: 10 21 31 21 1: 21 10 21 31 2: 31 21 10 21 3: 21 31 21 10 These patches extend core libvirt's XML description of NUMA cells to include NUMA distance information and propagate it to Xen guests via libxl. Recently qemu landed support for constructing the SLIT since commit 0f203430dd ("numa: Allow setting NUMA distance for different NUMA nodes"). The core libvirt extensions in this patch set could be used to propagate NUMA distances to qemu quests in the future. Wim ten Have (4): numa: describe siblings distances within cells xenconfig: add domxml conversions for xen-xl libxl: vnuma support xlconfigtest: add tests for numa cell sibling distances docs/formatdomain.html.in | 63 +++- docs/schemas/basictypes.rng | 7 + docs/schemas/cputypes.rng | 18 ++ src/conf/numa_conf.c | 328 +++++++++++++++++++- src/conf/numa_conf.h | 25 ++ src/libvirt_private.syms | 5 + src/libxl/libxl_conf.c | 119 ++++++++ src/libxl/libxl_domain.c | 7 +- src/xenconfig/xen_xl.c | 335 +++++++++++++++++++++ tests/libxlxml2domconfigdata/basic-hvm.json | 95 +++++- tests/libxlxml2domconfigdata/basic-hvm.xml | 66 +++- tests/virmocklibxl.c | 13 + .../test-fullvirt-vnuma-autocomplete.cfg | 26 ++ .../test-fullvirt-vnuma-autocomplete.xml | 85 ++++++ .../test-fullvirt-vnuma-nodistances.cfg | 26 ++ .../test-fullvirt-vnuma-nodistances.xml | 53 ++++ .../test-fullvirt-vnuma-partialdist.cfg | 26 ++ .../test-fullvirt-vnuma-partialdist.xml | 60 ++++ tests/xlconfigdata/test-fullvirt-vnuma.cfg | 26 ++ tests/xlconfigdata/test-fullvirt-vnuma.xml | 81 +++++ tests/xlconfigtest.c | 6 + 21 files changed, 1461 insertions(+), 9 deletions(-) create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-autocomplete.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-autocomplete.xml create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-nodistances.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-nodistances.xml create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-partialdist.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-partialdist.xml create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma.xml -- 2.13.6

3 11

[libvirt] [PATCH v4] vhost-user: add support reconnect for vhost-user ports
by ZhiPeng Lu 13 Nov '17

13 Nov '17

For vhost-user ports, Open vSwitch acts as the server and QEMU the client. When OVS crashes or restarts, the QEMU process should be reconnected to OVS. Signed-off-by: ZhiPeng Lu <lu.zhipeng(a)zte.com.cn> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v1->v2: - modify xml format v2->v3: - fix commit message syntax - reimplemente functions and the struct about reconnect v3->v4: - revert reimplemente functions and the struct about reconnect docs/formatdomain.html.in | 7 +- docs/schemas/domaincommon.rng | 26 ++-- src/conf/domain_conf.c | 158 ++++++++++++--------- .../qemuxml2argv-net-vhostuser-multiq.args | 12 +- .../qemuxml2argv-net-vhostuser-multiq.xml | 11 +- 5 files changed, 127 insertions(+), 87 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 92e14a9..7ea72ed 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5756,7 +5756,9 @@ qemu-kvm -net nic,model=? /dev/null </interface> <interface type='vhostuser'> <mac address='52:54:00:3b:83:1b'/> - <source type='unix' path='/tmp/vhost2.sock' mode='client'/> + <source type='unix' path='/tmp/vhost2.sock' mode='client'> + <reconnect enabled='yes' timeout='10'/> + </source> <model type='virtio'/> <driver queues='5'/> </interface> @@ -5772,6 +5774,9 @@ qemu-kvm -net nic,model=? /dev/null are supported. vhost-user requires the virtio model type, thus the <code><model></code> element is mandatory. + <span class="since">Since 3.10.0</span> the element has an optional + attribute <code>reconnect</code> which configures reconnect timeout + (in seconds) if the connection is lost. </p> <h5><a id="elementNwfilter">Traffic filtering with NWFilter</a></h5> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 9cec1a0..66b9758 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -2399,6 +2399,18 @@ </attribute> </optional> </define> + <define name="reconnect"> + <element name="reconnect"> + <attribute name="enabled"> + <ref name="virYesNo"/> + </attribute> + <optional> + <attribute name="timeout"> + <ref name="unsignedInt"/> + </attribute> + </optional> + </element> + </define> <!-- An interface description can either be of type bridge in which case @@ -2460,6 +2472,9 @@ <value>client</value> </choice> </attribute> + <optional> + <ref name="reconnect"/> + </optional> <empty/> </element> <ref name="interface-options"/> @@ -3708,16 +3723,7 @@ </attribute> </optional> <optional> - <element name="reconnect"> - <attribute name="enabled"> - <ref name="virYesNo"/> - </attribute> - <optional> - <attribute name="timeout"> - <ref name="unsignedInt"/> - </attribute> - </optional> - </element> + <ref name="reconnect"/> </optional> <zeroOrMore> <ref name='devSeclabel'/> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index f9ae057..be3374d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -10584,6 +10584,56 @@ virDomainNetAppendIPAddress(virDomainNetDefPtr def, return -1; } +static int +virDomainChrSourceReconnectDefParseXML(virDomainChrSourceReconnectDefPtr def, + xmlNodePtr node, + xmlXPathContextPtr ctxt) +{ + int ret = -1; + int tmpVal; + char *tmp = NULL; + xmlNodePtr saveNode = ctxt->node; + xmlNodePtr cur; + + ctxt->node = node; + + if ((cur = virXPathNode("./reconnect", ctxt))) { + if ((tmp = virXMLPropString(cur, "enabled"))) { + if ((tmpVal = virTristateBoolTypeFromString(tmp)) < 0) { + virReportError(VIR_ERR_XML_ERROR, + _("invalid reconnect enabled value: '%s'"), + tmp); + goto cleanup; + } + def->enabled = tmpVal; + VIR_FREE(tmp); + } + + if (def->enabled == VIR_TRISTATE_BOOL_YES) { + if ((tmp = virXMLPropString(cur, "timeout"))) { + if (virStrToLong_ui(tmp, NULL, 10, &def->timeout) < 0) { + virReportError(VIR_ERR_XML_ERROR, + _("invalid reconnect timeout value: '%s'"), + tmp); + goto cleanup; + } + VIR_FREE(tmp); + } else { + virReportError(VIR_ERR_XML_ERROR, "%s", + _("missing timeout for chardev with " + "reconnect enabled")); + goto cleanup; + } + } + } + + ret = 0; + cleanup: + ctxt->node = saveNode; + VIR_FREE(tmp); + return ret; +} + /* Parse the XML definition for a network interface * @param node XML nodeset to parse for net definition * @return 0 on success, -1 on failure @@ -10638,6 +10688,7 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, virNWFilterHashTablePtr filterparams = NULL; virDomainActualNetDefPtr actual = NULL; xmlNodePtr oldnode = ctxt->node; + virDomainChrSourceReconnectDef reconnect = {0}; int rv, val; if (VIR_ALLOC(def) < 0) @@ -10719,11 +10770,14 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, goto error; } } else if (!vhostuser_path && !vhostuser_mode && !vhostuser_type - && def->type == VIR_DOMAIN_NET_TYPE_VHOSTUSER && - virXMLNodeNameEqual(cur, "source")) { + && def->type == VIR_DOMAIN_NET_TYPE_VHOSTUSER + && virXMLNodeNameEqual(cur, "source")) { vhostuser_type = virXMLPropString(cur, "type"); vhostuser_path = virXMLPropString(cur, "path"); vhostuser_mode = virXMLPropString(cur, "mode"); + if (virDomainChrSourceReconnectDefParseXML(&reconnect, cur, ctxt) < 0) + goto error; + } else if (!def->virtPortProfile && virXMLNodeNameEqual(cur, "virtualport")) { if (def->type == VIR_DOMAIN_NET_TYPE_NETWORK) { @@ -10945,8 +10999,16 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, if (STREQ(vhostuser_mode, "server")) { def->data.vhostuser->data.nix.listen = true; + if (reconnect.enabled != VIR_TRISTATE_BOOL_ABSENT) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("'reconnect' attribute unsupported " + "'server' mode for <interface type='vhostuser'>")); + goto error; + } } else if (STREQ(vhostuser_mode, "client")) { def->data.vhostuser->data.nix.listen = false; + def->data.vhostuser->data.nix.reconnect.enabled = reconnect.enabled; + def->data.vhostuser->data.nix.reconnect.timeout = reconnect.timeout; } else { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("Wrong <source> 'mode' attribute " @@ -11608,57 +11670,6 @@ virDomainChrDefParseTargetXML(virDomainChrDefPtr def, return ret; } -static int -virDomainChrSourceReconnectDefParseXML(virDomainChrSourceReconnectDefPtr def, - xmlNodePtr node, - xmlXPathContextPtr ctxt) -{ - int ret = -1; - int tmpVal; - char *tmp = NULL; - xmlNodePtr saveNode = ctxt->node; - xmlNodePtr cur; - - ctxt->node = node; - - if ((cur = virXPathNode("./reconnect", ctxt))) { - if ((tmp = virXMLPropString(cur, "enabled"))) { - if ((tmpVal = virTristateBoolTypeFromString(tmp)) < 0) { - virReportError(VIR_ERR_XML_ERROR, - _("invalid reconnect enabled value: '%s'"), - tmp); - goto cleanup; - } - def->enabled = tmpVal; - VIR_FREE(tmp); - } - - if (def->enabled == VIR_TRISTATE_BOOL_YES) { - if ((tmp = virXMLPropString(cur, "timeout"))) { - if (virStrToLong_ui(tmp, NULL, 10, &def->timeout) < 0) { - virReportError(VIR_ERR_XML_ERROR, - _("invalid reconnect timeout value: '%s'"), - tmp); - goto cleanup; - } - VIR_FREE(tmp); - } else { - virReportError(VIR_ERR_XML_ERROR, "%s", - _("missing timeout for chardev with " - "reconnect enabled")); - goto cleanup; - } - } - } - - ret = 0; - cleanup: - ctxt->node = saveNode; - VIR_FREE(tmp); - return ret; -} - - typedef enum { VIR_DOMAIN_CHR_SOURCE_MODE_CONNECT, VIR_DOMAIN_CHR_SOURCE_MODE_BIND, @@ -23399,6 +23410,21 @@ virDomainVirtioNetDriverFormat(char **outstr, return 0; } +static void +virDomainChrSourceReconnectDefFormat(virBufferPtr buf, + virDomainChrSourceReconnectDefPtr def) +{ + if (def->enabled == VIR_TRISTATE_BOOL_ABSENT) + return; + + virBufferAsprintf(buf, "<reconnect enabled='%s'", + virTristateBoolTypeToString(def->enabled)); + + if (def->enabled == VIR_TRISTATE_BOOL_YES) + virBufferAsprintf(buf, " timeout='%u'", def->timeout); + + virBufferAddLit(buf, "/>\n"); +} int virDomainNetDefFormat(virBufferPtr buf, @@ -23493,6 +23519,14 @@ virDomainNetDefFormat(virBufferPtr buf, def->data.vhostuser->data.nix.listen ? "server" : "client"); sourceLines++; + if (def->data.vhostuser->data.nix.reconnect.enabled != VIR_TRISTATE_BOOL_ABSENT) { + virBufferAddLit(buf, ">\n"); + sourceLines++; + virBufferAdjustIndent(buf, 2); + virDomainChrSourceReconnectDefFormat(buf, &def->data.vhostuser->data.nix.reconnect); + virBufferAdjustIndent(buf, -2); + } + } break; @@ -23725,24 +23759,6 @@ virDomainChrAttrsDefFormat(virBufferPtr buf, return 0; } - -static void -virDomainChrSourceReconnectDefFormat(virBufferPtr buf, - virDomainChrSourceReconnectDefPtr def) -{ - if (def->enabled == VIR_TRISTATE_BOOL_ABSENT) - return; - - virBufferAsprintf(buf, "<reconnect enabled='%s'", - virTristateBoolTypeToString(def->enabled)); - - if (def->enabled == VIR_TRISTATE_BOOL_YES) - virBufferAsprintf(buf, " timeout='%u'", def->timeout); - - virBufferAddLit(buf, "/>\n"); -} - - static int virDomainChrSourceDefFormat(virBufferPtr buf, virDomainChrSourceDefPtr def, diff --git a/tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser-multiq.args b/tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser-multiq.args index b69ebd8..f2aec7b 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser-multiq.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser-multiq.args @@ -32,7 +32,11 @@ addr=0x4 \ -netdev socket,listen=:2015,id=hostnet2 \ -device rtl8139,netdev=hostnet2,id=net2,mac=52:54:00:95:db:c0,bus=pci.0,\ addr=0x5 \ --chardev socket,id=charnet3,path=/tmp/vhost2.sock \ --netdev vhost-user,chardev=charnet3,queues=4,id=hostnet3 \ --device virtio-net-pci,mq=on,vectors=10,netdev=hostnet3,id=net3,\ -mac=52:54:00:ee:96:6d,bus=pci.0,addr=0x6 +-chardev socket,id=charnet3,path=/tmp/vhost2.sock,reconnect=10 \ +-netdev vhost-user,chardev=charnet3,id=hostnet3 \ +-device virtio-net-pci,netdev=hostnet3,id=net3,\ +mac=52:54:00:ee:96:6d,bus=pci.0,addr=0x6 \ +-chardev socket,id=charnet4,path=/tmp/vhost3.sock,reconnect=0 \ +-netdev vhost-user,chardev=charnet4,queues=4,id=hostnet4 \ +-device virtio-net-pci,mq=on,vectors=10,netdev=hostnet4,id=net4,\ +mac=52:54:00:ee:96:6e,bus=pci.0,addr=0x7 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser-multiq.xml b/tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser-multiq.xml index d5c42fe..a30cce6 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser-multiq.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-net-vhostuser-multiq.xml @@ -40,7 +40,16 @@ </interface> <interface type='vhostuser'> <mac address='52:54:00:ee:96:6d'/> - <source type='unix' path='/tmp/vhost2.sock' mode='client'/> + <source type='unix' path='/tmp/vhost2.sock' mode='client'> + <reconnect enabled='yes' timeout='10'/> + </source> + <model type='virtio'/> + </interface> + <interface type='vhostuser'> + <mac address='52:54:00:ee:96:6e'/> + <source type='unix' path='/tmp/vhost3.sock' mode='client'> + <reconnect enabled='no'/> + </source> <model type='virtio'/> <driver queues='4'/> </interface> -- 1.8.3.1

1 0

[libvirt] [PATCH v3 1/2] remote: set neventCallbacks to zero at DEREG_CB
by xinhua.Cao 12 Nov '17

12 Nov '17

set neventCallbacks to zero after VIR_FREE(eventCallbacks) was called --- daemon/remote.c | 1 + 1 file changed, 1 insertion(+) diff --git a/daemon/remote.c b/daemon/remote.c index 07557e9..cbcb6e8 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -1686,6 +1686,7 @@ void remoteRelayConnectionClosedEvent(virConnectPtr conn ATTRIBUTE_UNUSED, int r VIR_WARN("unexpected %s event deregister failure", name); \ } \ VIR_FREE(eventCallbacks); \ + neventCallbacks = 0; \ } while (0); /* -- 2.8.3

2 3

[libvirt] bhyve: grub-bhyve: support overriding just --root flag
by Christian Schwarz 11 Nov '17

11 Nov '17

Hi, I was trying to get a GPT-formatted VM boot on FreeBSD using the bhyve driver and the grub-bhyve bootloader. Turns out that libvirt 3.9.0 hardcodes the boot partition to (hd0,msdos1) or allows overriding it completly using <bootloader_args>. I hacked together a patch that allows overring just the --root argument to grub-bhyve and updated the documentation: https://github.com/problame/libvirt/commit/5fd1265c05987d907d9f1d9913dbee83… Obviously, this does not meet quality standards and should not be merged as is, but maybe spawn some discussion (if anyone is actually using bhyve + libvirt). Cheers, Christian --- commit 5fd1265c05987d907d9f1d9913dbee832a227889 Author: Christian Schwarz <me(a)cschwarz.com> Date: Sat Nov 11 16:15:05 2017 +0100 bhyve: grub-bhyve: support overriding just the --root argument in domain config diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in index 63260afae..2583bfa01 100644 --- a/docs/drvbhyve.html.in +++ b/docs/drvbhyve.html.in @@ -300,17 +300,26 @@ are omitted, libvirt will try and infer boot ordering from user-supplied <boot order='N'> configuration in the domain. Failing that, it will boot the first disk in the domain (either <code>cdrom</code>- or <code>disk</code>-type devices). If the disk type is <code>disk</code>, it will -attempt to boot from the first partition in the disk image.</p> +attempt to boot from the first partition in the disk image, assuming +an <code>msdos</code> partitioning scheme +(i.e. <code>grub-bhyve --root hd0,msdos1</code>). +You can override this behavior using <code>bootloader_args</code> or <code>bootloader_grub_root</code>. +</p> <pre> ... <bootloader>/usr/local/sbin/grub-bhyve</bootloader> + <bootloader_args>...</bootloader_args> + +<bootloader_grub_root>hd0,gpt1</bootloader_grub_root> ... </pre> -<p>Caveat: <code>bootloader_args</code> does not support any quoting. -Filenames, etc, must not have spaces or they will be tokenized incorrectly.</p> +<p>Caveats when using <code>bootloader_args</code>: it does not support any quoting. +Filenames, etc, must not have spaces or they will be tokenized incorrectly. +Additionally, you will have to maintain your own <code>--device-map</code> +file and keep it in sync with the domain XML.</p> <h3><a id="uefi">Using UEFI bootrom, VNC, and USB tablet</a></h3> diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index 55032ae1d..6cab6e516 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -774,15 +774,21 @@ virBhyveProcessBuildGrubbhyveCmd(virDomainDefPtr def, } virCommandAddArg(cmd, "--root"); - if (userdef != NULL) { - if (userdef->device == VIR_DOMAIN_DISK_DEVICE_CDROM) + if (def->os.bootloaderGrubRoot != NULL) { + virCommandAddArg(cmd, def->os.bootloaderGrubRoot); + } else { + + if (userdef != NULL) { + if (userdef->device == VIR_DOMAIN_DISK_DEVICE_CDROM) + virCommandAddArg(cmd, "cd"); + else + virCommandAddArg(cmd, "hd0,msdos1"); + } else if (cd != NULL) { virCommandAddArg(cmd, "cd"); - else + } else { virCommandAddArg(cmd, "hd0,msdos1"); - } else if (cd != NULL) { - virCommandAddArg(cmd, "cd"); - } else { - virCommandAddArg(cmd, "hd0,msdos1"); + } + } virCommandAddArg(cmd, "--device-map"); diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 7dfd7b54e..ecd1f71dd 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -18141,6 +18141,7 @@ virDomainDefParseXML(xmlDocPtr xml, def->os.bootloader = virXPathString("string(./bootloader)", ctxt); def->os.bootloaderArgs = virXPathString("string(./bootloader_args)", ctxt); + def->os.bootloaderGrubRoot = virXPathString("string(./bootloader_grub_root)", ctxt); tmp = virXPathString("string(./os/type[1])", ctxt); if (!tmp) { diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index e3f060b12..f969e9195 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1884,6 +1884,7 @@ struct _virDomainOSDef { char *slic_table; virDomainLoaderDefPtr loader; char *bootloader; + char *bootloaderGrubRoot; char *bootloaderArgs; int smbios_mode;

1 0

[libvirt] [PATCH 00/11] Make auto completion better
by Michal Privoznik 10 Nov '17

10 Nov '17

After initial RFC [1] I had some time to work on this and here is the result. What's implemented? =================== Auto completion for both interactive and non-interactive virsh/virt-admin. Known limitations ================= Currently, just options completers work. I mean, to bring up list of domains you have to: virsh # start --domain <TAB><TAB> Doing bare: virsh # start <TAB><TAB> brings up list of --options. I am working on this meanwhile. But one can argue that having to use --option is not that much of a problem since we have good completion now. The other known limitation - and actually room for others to join and help - is missing completers. I mean, the last 3 patches give an example how to do that. But that is still very few. We need more completers. How does this work? =================== The basic idea is simple, when defining opts for command two new struct members can be set: {.name = "mac", .type = VSH_OT_STRING, + .completer = virshDomainInterfaceCompleter, + .completer_flags = VIRSH_DOMAIN_INTERFACE_COMPLETER_MAC, .help = N_("MAC address") }, @completer is the callback that is used when user wants to bring up list of possible strings. @completer_flags can then be used to refine return value of @completer. In this specific example, virshDomainInterfaceCompleter() brings up list of interfaces for given domain. It tries to return /interface/target/@dev but if not found (e.g. because domain is not running), /interface/mac/@address is returned otherwise. However, in one specific case we are interested only in MAC addresses (regardless of domain state) and thus VIRSH_DOMAIN_INTERFACE_COMPLETER_MAC flag is specified which alters @completer behaviour. For non-interactive virsh/virt-admin there's tools/bash-completion/vsh script which does no more than calling: $1 complete $USER_INPUT (where $1 is name of the binary user intents to run). How to test this? ================= Interactive completion should work out of the box. Just make sure you're connected. Completers don't connect! You certainly don't want ssh's 'Password:' prompt show on <TAB><TAB>, do you? Non-interactive completers do connect, but in order to avoid any password prompts, /dev/stdin is closed before anything else is done. In order to test it, just: libvirt.git $ source tools/bash-completion/vsh Now, bash completion should work: libvirt.git $ ./tools/virsh -c qemu:///system start --domain <TAB><TAB> Notes ===== This is that part of vsh that nobody wants to touch, but with these patches in we have the framework to just write small functions (as can be seen in examples). User would benefit from this! As usual, you can find all the patches on my github [2]. Michal 1: https://www.redhat.com/archives/libvir-list/2017-October/msg01374.html 2: https://github.com/zippy2/libvirt/tree/bash_autocomplete Michal Privoznik (11): vshCommandStringParse: Allow retrieving partial result vshCommandOpt: Relax check for valid options vsh: Add @silent to vshConnectionHook vsh: Fix vshCompleter signature vsh: Call vshCmdOptDef.completer properly vshCompleter: Pass partially parsed command vsh: Introduce complete command tools: Provide bash autompletion file virsh: Introduce virshDomainNameCompleter virsh: Introduce virshDomainInterfaceCompleter virt-admin: Introduce vshAdmServerCompleter configure.ac | 3 + libvirt.spec.in | 2 + m4/virt-bash-completion.m4 | 74 ++++++++++++++++ tools/Makefile.am | 40 ++++++++- tools/bash-completion/vsh | 73 ++++++++++++++++ tools/virsh-completer.c | 150 +++++++++++++++++++++++++++++++++ tools/virsh-completer.h | 41 +++++++++ tools/virsh-domain-monitor.c | 33 ++++---- tools/virsh-domain.c | 188 +++++++++++++++++++++-------------------- tools/virsh-snapshot.c | 24 +++--- tools/virsh.c | 72 +++++++++------- tools/virsh.h | 12 ++- tools/virt-admin-completer.c | 76 +++++++++++++++++ tools/virt-admin-completer.h | 33 ++++++++ tools/virt-admin.c | 62 ++++++++------ tools/vsh.c | 195 ++++++++++++++++++++++++++++++++----------- tools/vsh.h | 23 ++++- 17 files changed, 873 insertions(+), 228 deletions(-) create mode 100644 m4/virt-bash-completion.m4 create mode 100644 tools/bash-completion/vsh create mode 100644 tools/virsh-completer.c create mode 100644 tools/virsh-completer.h create mode 100644 tools/virt-admin-completer.c create mode 100644 tools/virt-admin-completer.h -- 2.13.6

3 31

[libvirt] [PATCH] tests: fix TTY check in virTestUseTerminalColors()
by Pino Toscano 10 Nov '17

10 Nov '17

Since colors would be used when writing to stdout, then check that stdout is a TTY, instead of stdin. This avoids the usage of terminal color codes when the output is directed to file. --- tests/testutils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/testutils.c b/tests/testutils.c index 915cd3b79..9266f15e8 100644 --- a/tests/testutils.c +++ b/tests/testutils.c @@ -92,7 +92,7 @@ bool virTestOOMActive(void) static int virTestUseTerminalColors(void) { - return isatty(STDIN_FILENO); + return isatty(STDOUT_FILENO); } static unsigned int -- 2.13.6

2 1

[libvirt] [PATCH] numa: avoid failure in nodememstats on non-NUMA systems
by Viktor Mihajlovski 10 Nov '17

10 Nov '17

libvirt reports a fake NUMA topology in virConnectGetCapabilities even if built without numactl support. The fake NUMA topology consists of a single cell representing the host's cpu and memory resources. Currently this is the case for ARM and s390[x] RPM builds. A client iterating over NUMA cells obtained via virConnectGetCapabilities and invoking virNodeGetMemoryStats on them will see an internal failure "NUMA isn't available on this host". An example for such a client is VDSM. Since the intention seems to be that libvirt always reports at least a single cell it is necessary to return "fake" node memory statistics matching the previously reported fake cell in case NUMA isn't supported on the system. Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> --- src/util/virhostmem.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/util/virhostmem.c b/src/util/virhostmem.c index a9ba278..fa04a37 100644 --- a/src/util/virhostmem.c +++ b/src/util/virhostmem.c @@ -267,6 +267,14 @@ virHostMemGetStats(int cellNum ATTRIBUTE_UNUSED, FILE *meminfo; int max_node; + /* + * Even if built without numactl, libvirt claims + * to have a one-cells NUMA topology. In such a + * case return the statistics for the entire host. + */ + if (!virNumaIsAvailable() && cellNum == 0) + cellNum = VIR_NODE_MEMORY_STATS_ALL_CELLS; + if (cellNum == VIR_NODE_MEMORY_STATS_ALL_CELLS) { if (VIR_STRDUP(meminfo_path, MEMINFO_PATH) < 0) return -1; -- 1.9.1

3 4

[libvirt] [PATCH 0/2] vbox: Add support for 5.2.x
by Dawid Zamirski 09 Nov '17

09 Nov '17

With each minor VBOX release a new SDK header needs to be added and wired up to the driver. This is basically the same as last time [1]. The first patch will be sent as a compressed attachment because it's a large header file taken from the SDK that would not pass the mailing list size constraints. [1] https://www.redhat.com/archives/libvir-list/2016-November/msg00355.html Dawid Zamirski (2): vbox: Add vbox 5.2 CAPI header file. vbox: Add support for 5.2.x src/Makefile.am | 1 + src/vbox/vbox_CAPI_v5_2.h | 26870 ++++++++++++++++++++++++++++++++++++++++ src/vbox/vbox_V5_2.c | 13 + src/vbox/vbox_common.h | 2 + src/vbox/vbox_storage.c | 2 + src/vbox/vbox_tmpl.c | 2 + src/vbox/vbox_uniformed_api.h | 1 + 7 files changed, 26891 insertions(+) create mode 100644 src/vbox/vbox_CAPI_v5_2.h create mode 100644 src/vbox/vbox_V5_2.c -- 2.14.2

2 4

[libvirt] [PATCH 0/4] qemu: fix usage of disk and storage source private data
by Peter Krempa 09 Nov '17

09 Nov '17

There were a few cases where we'd use private data for a storage source which was not allocated. Fix it by checking whether it is allocated. Qemu command line parser allocated disk definition via VIR_ALLOC rather than the proper function. This resulted into the disk private data strucutre not being allocated. That one is required. Peter Krempa (4): qemu: parse: Allocate disk definition with private data qemu: Tolerate storage source private data being NULL qemu: domain: Don't allocate storage source private data if not needed qemu: process: Setup disk secrets when preparing disks src/qemu/qemu_command.c | 18 ++++++++++++++---- src/qemu/qemu_domain.c | 14 ++++++++------ src/qemu/qemu_hotplug.c | 17 ++++++++++++----- src/qemu/qemu_parse_command.c | 4 +--- src/qemu/qemu_process.c | 14 +++++++++----- 5 files changed, 44 insertions(+), 23 deletions(-) -- 2.14.3

2 6

[libvirt] [PATCH] conf: Properly parse <backingStore/>
by Peter Krempa 09 Nov '17

09 Nov '17

The terminator would not be parsed properly since the XPath selector was looking for an populated element, and also the code did not bother assigning the terminating virStorageSourcePtr to the backingStore property of the parent. Some tests would catch it if there wasn't bigger fallout from the change to backing store termination in a693fdba0111. Fix them properly now. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1509110 --- src/conf/domain_conf.c | 14 ++++++-------- .../qemuxml2xmlout-disk-active-commit.xml | 1 + .../qemuxml2xmlout-disk-backing-chains-active.xml | 3 +++ .../qemuxml2xmlout-disk-mirror-active.xml | 4 ++++ .../qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-old.xml | 4 ++++ .../qemuxml2xmlout-seclabel-static-labelskip.xml | 1 + 6 files changed, 19 insertions(+), 8 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 7dfd7b54e..a1ca307c4 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -8545,23 +8545,21 @@ virDomainDiskBackingStoreParse(xmlXPathContextPtr ctxt, char *idx = NULL; int ret = -1; - if (!(ctxt->node = virXPathNode("./backingStore[*]", ctxt))) { + if (!(ctxt->node = virXPathNode("./backingStore", ctxt))) { ret = 0; goto cleanup; } - if (!(type = virXMLPropString(ctxt->node, "type"))) { - /* terminator does not have a type */ - if (VIR_ALLOC(backingStore) < 0) - goto cleanup; + if (VIR_ALLOC(backingStore) < 0) + goto cleanup; + /* terminator does not have a type */ + if (!(type = virXMLPropString(ctxt->node, "type"))) { + VIR_STEAL_PTR(src->backingStore, backingStore); ret = 0; goto cleanup; } - if (VIR_ALLOC(backingStore) < 0) - goto cleanup; - if (!(flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) && (idx = virXMLPropString(ctxt->node, "index")) && virStrToLong_uip(idx, NULL, 10, &backingStore->id) < 0) { diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-active-commit.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-active-commit.xml index 5766e4aea..cc26af109 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-active-commit.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-active-commit.xml @@ -20,6 +20,7 @@ <backingStore type='block' index='1'> <format type='raw'/> <source dev='/dev/HostVG/QEMUGuest1'/> + <backingStore/> </backingStore> <mirror type='block' job='active-commit'> <format type='raw'/> diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-backing-chains-active.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-backing-chains-active.xml index 828defcc2..d1fd2442c 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-backing-chains-active.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-backing-chains-active.xml @@ -49,6 +49,7 @@ <backingStore type='file' index='6'> <format type='raw'/> <source file='/tmp/Fedora-17-x86_64-Live-KDE.iso'/> + <backingStore/> </backingStore> </backingStore> </backingStore> @@ -63,6 +64,7 @@ <source protocol='gluster' name='Volume1/Image'> <host name='example.org' port='6000'/> </source> + <backingStore/> <target dev='vdc' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> @@ -79,6 +81,7 @@ <backingStore type='file' index='1'> <format type='qcow2'/> <source file='/tmp/image.qcow'/> + <backingStore/> </backingStore> <target dev='vdd' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-active.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-active.xml index 252bde338..c1e8a33ec 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-active.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-active.xml @@ -16,6 +16,7 @@ <emulator>/usr/bin/qemu-system-i686</emulator> <disk type='block' device='disk'> <source dev='/dev/HostVG/QEMUGuest1'/> + <backingStore/> <mirror type='block' job='copy' ready='yes'> <source dev='/dev/HostVG/QEMUGuest1Copy'/> </mirror> @@ -24,12 +25,14 @@ </disk> <disk type='block' device='cdrom'> <source dev='/dev/HostVG/QEMUGuest2'/> + <backingStore/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> <disk type='file' device='disk'> <source file='/tmp/data.img'/> + <backingStore/> <mirror type='file' file='/tmp/copy.img' format='qcow2' job='copy'> <format type='qcow2'/> <source file='/tmp/copy.img'/> @@ -39,6 +42,7 @@ </disk> <disk type='file' device='disk'> <source file='/tmp/logs.img'/> + <backingStore/> <mirror type='file' file='/tmp/logcopy.img' format='qcow2' job='copy' ready='abort'> <format type='qcow2'/> <source file='/tmp/logcopy.img'/> diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-old.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-old.xml index f4bd39a58..e390bc02f 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-old.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-mirror-old.xml @@ -16,6 +16,7 @@ <emulator>/usr/bin/qemu-system-i686</emulator> <disk type='block' device='disk'> <source dev='/dev/HostVG/QEMUGuest1'/> + <backingStore/> <mirror type='file' file='/dev/HostVG/QEMUGuest1Copy' job='copy' ready='yes'> <source file='/dev/HostVG/QEMUGuest1Copy'/> </mirror> @@ -24,12 +25,14 @@ </disk> <disk type='block' device='cdrom'> <source dev='/dev/HostVG/QEMUGuest2'/> + <backingStore/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> <disk type='file' device='disk'> <source file='/tmp/data.img'/> + <backingStore/> <mirror type='file' file='/tmp/copy.img' format='qcow2' job='copy'> <format type='qcow2'/> <source file='/tmp/copy.img'/> @@ -39,6 +42,7 @@ </disk> <disk type='file' device='disk'> <source file='/tmp/logs.img'/> + <backingStore/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-seclabel-static-labelskip.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-seclabel-static-labelskip.xml index 91f573db7..d37b950cb 100644 --- a/tests/qemuxml2xmloutdata/qemuxml2xmlout-seclabel-static-labelskip.xml +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-seclabel-static-labelskip.xml @@ -18,6 +18,7 @@ <source dev='/dev/HostVG/QEMUGuest1'> <seclabel model='selinux' labelskip='yes'/> </source> + <backingStore/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> -- 2.14.3

2 1

[libvirt] [PATCH 0/2] qemu: block: Fix issues pointed out by coverity
by Peter Krempa 09 Nov '17

09 Nov '17

Few unlikely memleaks and a more likely NULL deref. Peter Krempa (2): qemu: block: Break out early on invalid storage sources qemu: block: Don't leak server JSON object from protocol generators src/qemu/qemu_block.c | 76 ++++++++++++++++++++++++++++++++------------------- 1 file changed, 48 insertions(+), 28 deletions(-) -- 2.14.3

2 3

[libvirt] KVM Forum BoF session notes: QEMU configuration/command-line/QMP
by Eduardo Habkost 09 Nov '17

09 Nov '17

Hi, Below are the notes I collected during the BoF session about QEMU configuration, command-line and QMP. Sorry for taking so long to send them. All inaccuracies and mistakes below are my own fault. (I learned the hard way that trying to take notes while participating in the discussion at the same time is not a good idea.) -------------------------------- KVM Forum 2017 BoF session: configuration, command-line and QMP 2017-10-26 People: Jiri Denemark, Laine Stump, Peter Krempa, Markus Armbruster, Eduardo Habkost, Igor Mammedov, Kevin Wolf, Eduardo Otubo, Alistair Francis, Kashyap Chamarthy, Max Reitz ---------------- First topic: early QMP and -paused series by Igor ehabkost tried to explain the original problem and Igor's proposal[1]. Markus: startup time is important, some things can make it slow. Personally, not so much concerned about querying stuff. Just cache it! Markus, about starting a monitor earlier: "it just makes sense". One problem is: command-line processing ordering mess in QEMU. It's tempting but very scary. very easy to screw up. About command-line ordering, “I'd just go left-to-right”. ehabkost: is gradual change with NUMA stuff the right path? (Markus: "what's the right path?"; ehabkost: "I don't know"). If you are using CPU hotplug you still might have some stuff not appearing in the command-line, because it uses query-hotpluggable-cpus. pkrempa: if you're using cpu hotplug you don't care about startup time. NUMA is not different. Markus's objection to current -paused series: the need for another option/state. We basically have 3 states/phases: 1: between exec and monitor available 2: between monitor and machines start to runs (in that phase a device_add is/can be a cold plug) 3: then the machine actually runs, and all device_add is hotplug ehabkost: that's how I understand it, too. ehabkost: question for libvirt developers: is there an "expansion" operation where libvirt could fill-up missing data on the XML based on info queried from QEMU? (Answer seems to be yes) ---------------- Some comments from Igor and Peter about query-hotpluggable-cpus and the need to choose the right device type (sometimes TYPE_CPU is not appropriate for device_add, but only CPU cores, like on Power). ehabkost: that's probably another use case for query-device-slots: knowing that power machines can't device_add threads, but just cores. Tricky part: providing slot information at qemu-probing time (with -machine none), before any machine was built. ---------------- Some discussion about QEMU capability caching, why we need it, what we need to get rid of it (answer: early QMP?). Markus: would --query-FOO for some FOOs help? libvirt developers seem to prefer early QMP. ---------------- Now that libvirt queries QEMU for host CPUID capabilities, there are more interesting ways the cache may need to be invalidated. Markus: “there's a it of a combinatorial explosion, i.e. query results can depend on so much more than just the QEMU version and machine type. Makes invalidating the cache tricky, and possibly even finding something useful in it insufficiently likely to be worth the trouble.” ---------------- Some discussion about libvirt/qemu versions compatibility. Markus proposes that we could choose to make newer QEMU require a more recent libvirt version. OpenStack Nova re-evaluates every 6 months what next minimum libvirt and QEMU versions to use (via constants: NEXT_MIN_LIBVIRT_VERSION, NEXT_MIN_QEMU_VERSION) Markus: “The version decoupling we have is really nice, but I think an occasional dependency would be tolerable. Consider it when it saves lots of work.” Markus: “Also: drop support for old versions of QEMU. Anything before 1.5?” ---------------- References and notes: [1] References for “Early QMP”: * Igor’s proposal at: Subject: [Qemu-devel] [RFC 0/6] enable numa configuration before machine_init() from HMP/QMP https://www.mail-archive.com/qemu-devel@nongnu.org/msg488601.html * And what Eduardo has suggested at: http://www.linux-kvm.org/images/4/46/03x06A-Eduardo_HabkostMachine-type_Int… Comments from Markus: > Related: "Why /two/ config interfaces?" in my KVM Forum talk. The two > being CLI and QMP. > > We've long held the idea to support starting QEMU with a minimal command > line, then do all configuration via QMP. Not possible today, because > lots of things can only be done via CLI. In part because QMP becomes > available only after quite a few config boats have sailed. > > Making QMP available earlier during startup ("early QMP") would be a > stepping stone towards the "only QMP" goal. > > Related: rebasing CLI onto QAPI would make replicating CLI-only > interfaces in QMP easier. -- Eduardo

1 0

[libvirt] [PATCH] apparmor: add network netlink raw rule
by Cédric Bosdonnat 09 Nov '17

09 Nov '17

The rule 'network netlink raw' fixes these denials on libvirtd start: apparmor="DENIED" operation="create" profile="/usr/sbin/libvirtd" pid=12969 comm="libvirtd" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create" --- examples/apparmor/usr.sbin.libvirtd | 1 + 1 file changed, 1 insertion(+) diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index 819068ffc..8ac5233cc 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -36,6 +36,7 @@ network inet6 dgram, network packet dgram, network packet raw, + network netlink raw, ptrace (trace) peer=unconfined, ptrace (trace) peer=/usr/sbin/libvirtd, -- 2.14.3

3 2

[libvirt] [PATCH v3 00/11] qemu: replace nested job with interruptible async job state
by Nikolay Shirokovskiy 09 Nov '17

09 Nov '17

Hello, everyone. This is successor to [1] "[PATCH v2 RFC 0/4] qemu: replace nested job with interruptible async job state". I tried to expand on series rationale, to make better splitting and to add comments. ABSTRACT Let's use interruptible async job state instead of nested jobs to control concurrent execution of async and regular jobs. RATIONALE I'm not quite happy with current implementation of concurrent execution async and regular jobs because it is not straigthforward. What is current implementation of jobs concurrency? While async job is running any compatible regular job is allowed to run concurrently. Practically it means that as soon as async job drops the domain lock another rpc thread can run in, find domain in the domain list and start a regular job. This is what happens when for example migration drops the lock before waiting for migration completion event or before sending request to destination side. But if we are going to send command to qemu monitor and accordingly drop domain lock this concurrency is not desired because qemu monitor can not handle simultaneus commands now. (This is probably not the only reason. I guess we don't want to think about what can happen if regular job will run concurrenly for example to migration at any place. Ability to run concurrently during disk mirror or state transfer which take the most time of migration looks enough). Thus nested jobs were introduced. Now if async job wants to send command to monitor it start special nested jobs beforehand thus effectively block concurrent regular jobs. To me it sounds like hacky way to implement the fact that async job allows concurrency only in limited places. Let's call them interruptible. So I suggest introduce interruptible state for async job. Before we are going to wait for migration completion for example we enter this state allowing regular jobs run concurrently. Later when we meet migration completion condition we wait for concurrent regular job to finish if any before proceed. This final step is required in this approach by definition - when async job is not interruptible no regular jobs can run concurrenly. On practice this protects us from sending qemu monitor command from async job while concurrent regular job is not finished its qemu monitor communication yet. Sounds like this final wait can have consequenses on migration. Like what if finishing concurrent job take too much time. In this case we get increased migration downtime. Well we will get this increase with current appoach too. Because right after migration completion condition is met we fetch migration stats and wait in enter monitor function anyway until concurrent job is finished. This also demontrates that current appoach isolates async and concurrent regular job loosely. It is possible that regular job starts then async job resumes and continues its execution until it requires qemu monitor and only then regular job finishes its execution. I guess it will be easy to reason about concurrency if when concurrent regular is started async job can not continue until regular job is finished. Check patch 4 for a demonstration that job isolation is good. TESTS To test concurrency I ran about 100 times a migration of non-empty domain with shared disk in a run with concurrent domstats for this domain in a tight loop. Looks good. MISSING PARTS - Enter/exit interruptible state at the end/begin of migration phases. Until this point is done we have a bit of degradation because domain won't response for example to queries between migration phases. - Update THREADS.txt I'm going to implement missing parts as soon as RFC has overall approvement. TODO 1 Drop driver argument from calls to qemuDomainObjEnterMonitor 2 Replace qemuDomainObjEnterMonitorAsync with qemuDomainObjEnterMonitor 3 Make qemuDomainObjExitMonitor void and drop its driver argument. [1] https://www.redhat.com/archives/libvir-list/2017-May/msg00018.html Nikolay Shirokovskiy (11): qemu: introduce routines for interruptible state qemu: check interruptible state instead of taking nested job qemu: enter interruptlible state where appropriate qemu: remove nested job usage from qemuProcessStop qemu: remove unused qemuDomainObjBeginNestedJob qemu: remove QEMU_JOB_ASYNC_NESTED qemu: remove liveness check from qemuDomainObjExitMonitor qemu: drop qemuDomainObjEnterMonitorInternal qemu: drop qemuDomainObjExitMonitorInternal conf: cleanup: drop virDomainObjWait qemu: rename qemuDomainNestedJobAllowed src/conf/domain_conf.c | 19 ---- src/conf/domain_conf.h | 1 - src/libvirt_private.syms | 1 - src/qemu/qemu_domain.c | 265 ++++++++++++++++++++++++++++++---------------- src/qemu/qemu_domain.h | 17 ++- src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_migration.c | 18 ++-- src/qemu/qemu_process.c | 19 +--- 8 files changed, 195 insertions(+), 147 deletions(-) -- 1.8.3.1

1 11

[libvirt] [PATCH] virconf: properly set the end of content
by Jim Fehlig 09 Nov '17

09 Nov '17

There was a recent report of the xen-xl converter not handling config files missing an ending newline https://www.redhat.com/archives/libvir-list/2017-October/msg01353.html Commit 3cc2a9e0 fixed a similar problem when parsing content of a file but missed parsing in-memory content. But AFAICT, the better fix is to properly set the end of the content when initializing the virConfParserCtxt in virConfParse(). This commit reverts the part of 3cc2a9e0 that appends a newline to files missing it, and fixes setting the end of content when initializing virConfParserCtxt. A test is also added to check parsing in-memory content missing an ending newline. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/util/virconf.c | 13 ++-------- tests/virconftest.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+), 11 deletions(-) diff --git a/src/util/virconf.c b/src/util/virconf.c index 39c2bd917..a82a509ca 100644 --- a/src/util/virconf.c +++ b/src/util/virconf.c @@ -705,7 +705,7 @@ virConfParse(const char *filename, const char *content, int len, ctxt.filename = filename; ctxt.base = ctxt.cur = content; - ctxt.end = content + len - 1; + ctxt.end = content + len; ctxt.line = 1; ctxt.conf = virConfCreate(filename, flags); @@ -745,7 +745,7 @@ virConfReadFile(const char *filename, unsigned int flags) { char *content; int len; - virConfPtr conf = NULL; + virConfPtr conf; VIR_DEBUG("filename=%s", NULLSTR(filename)); @@ -757,17 +757,8 @@ virConfReadFile(const char *filename, unsigned int flags) if ((len = virFileReadAll(filename, MAX_CONFIG_FILE_SIZE, &content)) < 0) return NULL; - if (len && len < MAX_CONFIG_FILE_SIZE && content[len - 1] != '\n') { - VIR_DEBUG("appending newline to busted config file %s", filename); - if (VIR_REALLOC_N(content, len + 2) < 0) - goto cleanup; - content[len++] = '\n'; - content[len] = '\0'; - } - conf = virConfParse(filename, content, len, flags); - cleanup: VIR_FREE(content); return conf; diff --git a/tests/virconftest.c b/tests/virconftest.c index a8b18bae0..3cf0df3ac 100644 --- a/tests/virconftest.c +++ b/tests/virconftest.c @@ -77,6 +77,72 @@ static int testConfRoundTrip(const void *opaque) } +static int testConfMemoryNoNewline(const void *opaque ATTRIBUTE_UNUSED) +{ + const char *srcdata = \ + "ullong = '123456789'\n" \ + "string = 'foo'\n" \ + "uint = 12345"; + + virConfPtr conf = virConfReadString(srcdata, 0); + int ret = -1; + virConfValuePtr val; + unsigned long long llvalue; + char *str = NULL; + int uintvalue; + + if (!conf) + return -1; + + if (!(val = virConfGetValue(conf, "ullong"))) + goto cleanup; + + if (val->type != VIR_CONF_STRING) + goto cleanup; + + if (virStrToLong_ull(val->str, NULL, 10, &llvalue) < 0) + goto cleanup; + + if (llvalue != 123456789) { + fprintf(stderr, "Expected '123' got '%llu'\n", llvalue); + goto cleanup; + } + + if (virConfGetValueType(conf, "string") != + VIR_CONF_STRING) { + fprintf(stderr, "expected a string for 'string'\n"); + goto cleanup; + } + + if (virConfGetValueString(conf, "string", &str) < 0) + goto cleanup; + + if (STRNEQ_NULLABLE(str, "foo")) { + fprintf(stderr, "Expected 'foo' got '%s'\n", str); + goto cleanup; + } + + if (virConfGetValueType(conf, "uint") != VIR_CONF_ULLONG) { + fprintf(stderr, "expected an unsigned long for 'uint'\n"); + goto cleanup; + } + + if (virConfGetValueInt(conf, "uint", &uintvalue) < 0) + goto cleanup; + + if (uintvalue != 12345) { + fprintf(stderr, "Expected 12345 got %ud\n", uintvalue); + goto cleanup; + } + + ret = 0; + cleanup: + VIR_FREE(str); + virConfFree(conf); + return ret; +} + + static int testConfParseInt(const void *opaque ATTRIBUTE_UNUSED) { const char *srcdata = \ @@ -414,6 +480,9 @@ mymain(void) if (virTestRun("no-newline", testConfRoundTrip, "no-newline") < 0) ret = -1; + if (virTestRun("memory-no-newline", testConfMemoryNoNewline, NULL) < 0) + ret = -1; + if (virTestRun("int", testConfParseInt, NULL) < 0) ret = -1; -- 2.14.2

2 2

[libvirt] [PATCH] virconf: properly set the end of content
by Jim Fehlig 09 Nov '17

09 Nov '17

There was a recent report of the xen-xl converter not handling config files missing an ending newline https://www.redhat.com/archives/libvir-list/2017-October/msg01353.html Commit 3cc2a9e0 fixed a similar problem when parsing content of a file but missed parsing in-memory content. But AFAICT, the better fix is to properly set the end of the content when initializing the virConfParserCtxt in virConfParse(). This commit reverts the part of 3cc2a9e0 that appends a newline to files missing it, and fixes setting the end of content when initializing virConfParserCtxt. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/util/virconf.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/src/util/virconf.c b/src/util/virconf.c index 39c2bd917..a82a509ca 100644 --- a/src/util/virconf.c +++ b/src/util/virconf.c @@ -705,7 +705,7 @@ virConfParse(const char *filename, const char *content, int len, ctxt.filename = filename; ctxt.base = ctxt.cur = content; - ctxt.end = content + len - 1; + ctxt.end = content + len; ctxt.line = 1; ctxt.conf = virConfCreate(filename, flags); @@ -745,7 +745,7 @@ virConfReadFile(const char *filename, unsigned int flags) { char *content; int len; - virConfPtr conf = NULL; + virConfPtr conf; VIR_DEBUG("filename=%s", NULLSTR(filename)); @@ -757,17 +757,8 @@ virConfReadFile(const char *filename, unsigned int flags) if ((len = virFileReadAll(filename, MAX_CONFIG_FILE_SIZE, &content)) < 0) return NULL; - if (len && len < MAX_CONFIG_FILE_SIZE && content[len - 1] != '\n') { - VIR_DEBUG("appending newline to busted config file %s", filename); - if (VIR_REALLOC_N(content, len + 2) < 0) - goto cleanup; - content[len++] = '\n'; - content[len] = '\0'; - } - conf = virConfParse(filename, content, len, flags); - cleanup: VIR_FREE(content); return conf; -- 2.14.2

2 2

[libvirt] [PATCH v3 0/5] nwfilter common object adjustments
by John Ferlan 08 Nov '17

08 Nov '17

v2: https://www.redhat.com/archives/libvir-list/2017-July/msg00673.html (and a few pings along the way) Don't think much survived from v2 - this is a fresh start anyway. Perhaps old patch 2 the same, but beyond that a different approach to remove recursive read/write locks and replace with using rwlock read/write where the write's are in very tight confines. I've run the changes through avocado with success. There were some really strange deadlocks along the way - even causing libvirtd to go defunct. There's a lot of strange ways to use/access the nwfilters. John Ferlan (5): nwfilter: Add update locking to Initialization nwfilter: Remove unnecessary UUID comparison bypass nwfilter: Convert _virNWFilterObj to use virObjectRWLockable nwfilter: Convert _virNWFilterObjList to use virObjectRWLockable nwfilter: Remove need for nwfilterDriverLock in some API's src/conf/virnwfilterobj.c | 555 +++++++++++++++++++++++---------- src/conf/virnwfilterobj.h | 11 +- src/libvirt_private.syms | 3 +- src/nwfilter/nwfilter_driver.c | 77 +++-- src/nwfilter/nwfilter_gentech_driver.c | 11 +- 5 files changed, 433 insertions(+), 224 deletions(-) -- 2.13.6

1 6

[libvirt] [PATCH 0/4] Couple more hotplug cleanups
by John Ferlan 08 Nov '17

08 Nov '17

Patches speak for themselves - they also resolve a couple of new Coverity whines. John Ferlan (4): conf,qemu: Check for NULL addrs in virDomainUSBAddressRelease conf,qemu: Check for NULL addrs in virDomainUSBAddressEnsure qemu: Remove unnecessary virtio disk detach info.alias check qemu: Remove unnecessary controller detach info.alias check src/conf/domain_addr.c | 5 ++++- src/conf/domain_addr.h | 4 ++-- src/qemu/qemu_domain_address.c | 7 ++----- src/qemu/qemu_hotplug.c | 43 ++++++++++++++---------------------------- 4 files changed, 22 insertions(+), 37 deletions(-) -- 2.13.6

2 7

Re: [libvirt] [PATCH 0/7] x86: Rework KVM-defaults compat code, enable kvm_pv_unhalt by default
by Eduardo Habkost 08 Nov '17

08 Nov '17

(CCing libvir-list) On Mon, Oct 09, 2017 at 05:47:44PM +0200, Paolo Bonzini wrote: > On 09/10/2017 17:15, Waiman Long wrote: > > On 10/09/2017 09:39 AM, Paolo Bonzini wrote: > >> On 06/10/2017 23:52, Eduardo Habkost wrote: > >>> This series enables kvm_pv_unhalt by default on pc-*-2.11 and > >>> newer. > >> > >> I've discussed PV spinlocks with some folks at Microsoft for a few weeks > >> now, and I'm not 100% sure about enabling kvm_pv_unhalt by default. > >> It's probably a good idea overall, but it does come with some caveats. > >> > >> The problem is that there were two different implementations of fair > >> spinlocks in Linux, ticket spinlocks and queued spinlocks. When > >> kvm_pv_unhalt is disabled, ticket spinlocks sucked badly indeed; queued > >> spinlocks however simply revert to unfair spinlocks, which loses the > >> fairness but has the best performance. See virt_spin_lock in > >> arch/x86/include/asm/qspinlock.h. > >> > >> Now, fair spinlocks are only really needed for large NUMA machines. > >> With a single NUMA node, for example, test-and-set spinlocks work well > >> enough; there's not _much_ need for fairness in practice, and the > >> paravirtualization does introduce some overhead. > >> > >> Therefore, the best performance would be achieved with kvm_pv_unhalt > >> disabled on small VMs, and enabled on large VMs spanning multiple host > >> NUMA nodes. > >> > >> Waiman, Davidlohr, do you have an opinion on this as well? > > > > I agree. Using unfair lock in a small VM is good for performance. The > > only problem I see is how do we define what is small. Now, even a > > machine with a single socket can have up to 28 cores, 56 threads. If a > > VM has up to 56 vCPUs, we may still want pvqspinlock to be used. > > Yes. Another possibility is to enable it when there is >1 NUMA node in > the guest. We generally don't do this kind of magic but higher layers > (oVirt/OpenStack) do. Can't the guest make this decision, instead of the host? > > It also depends on how worse performance is with PV qspinlocks, > especially since now there's also vcpu_is_preempted that has to be > thrown in the mix. A lot more testing is needed. > This is an interesting case for "-cpu host"/host-passthrough: usage of "-cpu host" has an implicit assumption that no feature will decrease performance just because we told the guest that it is available. Can't the guest choose the most reasonable option based on the information we provide to it, instead of having to hide information from the guest to get better performance? > > Is the kvm_pv_unhalt flag a global one for all VMs within a machine? Or > > can it be different for each VM? We may want to have this flag > > dynamically determined depending on the configuration of the VM. > > It's per-VM, so that's easy. -- Eduardo

3 8

[libvirt] [PATCH] qemu-ns: Detect /dev/* mount point duplicates even better
by Michal Privoznik 08 Nov '17

08 Nov '17

In 4f1570720218302 I've tried to make duplicates detection for nested /dev mount better. However, I've missed the obvious case when there are two same mount points. For instance if: # mount --bind /dev/blah /dev/blah # mount --bind /dev/blah /dev/blah Yeah, very unlikely but possible. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 702463547..61d28337b 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -8352,7 +8352,7 @@ qemuDomainGetPreservedMounts(virQEMUDriverConfigPtr cfg, while (j < nmounts) { char *c = STRSKIP(mounts[j], mounts[i]); - if (c && *c == '/') { + if (c && (*c == '/' || *c == '\0')) { VIR_DEBUG("Dropping path %s because of %s", mounts[j], mounts[i]); VIR_DELETE_ELEMENT(mounts, j, nmounts); } else { -- 2.13.6

3 2

[libvirt] [PATCH] conf: Fix type for @liveStatus in virDomainObjListLoadAllConfigs
by Peter Krempa 08 Nov '17

08 Nov '17

Use bool instead of an int. --- src/bhyve/bhyve_driver.c | 4 ++-- src/conf/virdomainobjlist.c | 2 +- src/conf/virdomainobjlist.h | 2 +- src/libxl/libxl_driver.c | 6 +++--- src/lxc/lxc_driver.c | 6 +++--- src/qemu/qemu_driver.c | 6 +++--- src/uml/uml_driver.c | 4 ++-- 7 files changed, 15 insertions(+), 15 deletions(-) diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c index 5c432b25e..dd6e8abc6 100644 --- a/src/bhyve/bhyve_driver.c +++ b/src/bhyve/bhyve_driver.c @@ -1294,7 +1294,7 @@ bhyveStateInitialize(bool privileged, if (virDomainObjListLoadAllConfigs(bhyve_driver->domains, BHYVE_STATE_DIR, - NULL, 1, + NULL, true, bhyve_driver->caps, bhyve_driver->xmlopt, NULL, NULL) < 0) @@ -1302,7 +1302,7 @@ bhyveStateInitialize(bool privileged, if (virDomainObjListLoadAllConfigs(bhyve_driver->domains, BHYVE_CONFIG_DIR, - BHYVE_AUTOSTART_DIR, 0, + BHYVE_AUTOSTART_DIR, false, bhyve_driver->caps, bhyve_driver->xmlopt, NULL, NULL) < 0) diff --git a/src/conf/virdomainobjlist.c b/src/conf/virdomainobjlist.c index b9f78c572..87a742b1e 100644 --- a/src/conf/virdomainobjlist.c +++ b/src/conf/virdomainobjlist.c @@ -559,7 +559,7 @@ int virDomainObjListLoadAllConfigs(virDomainObjListPtr doms, const char *configDir, const char *autostartDir, - int liveStatus, + bool liveStatus, virCapsPtr caps, virDomainXMLOptionPtr xmlopt, virDomainLoadConfigNotify notify, diff --git a/src/conf/virdomainobjlist.h b/src/conf/virdomainobjlist.h index 60220ca0d..bb186bde3 100644 --- a/src/conf/virdomainobjlist.h +++ b/src/conf/virdomainobjlist.h @@ -72,7 +72,7 @@ void virDomainObjListRemoveLocked(virDomainObjListPtr doms, int virDomainObjListLoadAllConfigs(virDomainObjListPtr doms, const char *configDir, const char *autostartDir, - int liveStatus, + bool liveStatus, virCapsPtr caps, virDomainXMLOptionPtr xmlopt, virDomainLoadConfigNotify notify, diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 951937f14..40328a6cb 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -763,7 +763,7 @@ libxlStateInitialize(bool privileged, if (virDomainObjListLoadAllConfigs(libxl_driver->domains, cfg->stateDir, cfg->autostartDir, - 1, + true, cfg->caps, libxl_driver->xmlopt, NULL, NULL) < 0) @@ -775,7 +775,7 @@ libxlStateInitialize(bool privileged, if (virDomainObjListLoadAllConfigs(libxl_driver->domains, cfg->configDir, cfg->autostartDir, - 0, + false, cfg->caps, libxl_driver->xmlopt, NULL, NULL) < 0) @@ -815,7 +815,7 @@ libxlStateReload(void) virDomainObjListLoadAllConfigs(libxl_driver->domains, cfg->configDir, cfg->autostartDir, - 1, + true, cfg->caps, libxl_driver->xmlopt, NULL, libxl_driver); diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index 0069e5e92..b3447100f 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -1679,7 +1679,7 @@ static int lxcStateInitialize(bool privileged, /* Get all the running persistent or transient configs first */ if (virDomainObjListLoadAllConfigs(lxc_driver->domains, cfg->stateDir, - NULL, 1, + NULL, true, caps, lxc_driver->xmlopt, NULL, NULL) < 0) @@ -1690,7 +1690,7 @@ static int lxcStateInitialize(bool privileged, /* Then inactive persistent configs */ if (virDomainObjListLoadAllConfigs(lxc_driver->domains, cfg->configDir, - cfg->autostartDir, 0, + cfg->autostartDir, false, caps, lxc_driver->xmlopt, NULL, NULL) < 0) @@ -1755,7 +1755,7 @@ lxcStateReload(void) virDomainObjListLoadAllConfigs(lxc_driver->domains, cfg->configDir, - cfg->autostartDir, 0, + cfg->autostartDir, false, caps, lxc_driver->xmlopt, lxcNotifyLoadDomain, lxc_driver); diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 47f85b9bf..6132bc4a9 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -911,7 +911,7 @@ qemuStateInitialize(bool privileged, /* Get all the running persistent or transient configs first */ if (virDomainObjListLoadAllConfigs(qemu_driver->domains, cfg->stateDir, - NULL, 1, + NULL, true, qemu_driver->caps, qemu_driver->xmlopt, NULL, NULL) < 0) @@ -933,7 +933,7 @@ qemuStateInitialize(bool privileged, /* Then inactive persistent configs */ if (virDomainObjListLoadAllConfigs(qemu_driver->domains, cfg->configDir, - cfg->autostartDir, 0, + cfg->autostartDir, false, qemu_driver->caps, qemu_driver->xmlopt, NULL, NULL) < 0) @@ -1015,7 +1015,7 @@ qemuStateReload(void) cfg = virQEMUDriverGetConfig(qemu_driver); virDomainObjListLoadAllConfigs(qemu_driver->domains, cfg->configDir, - cfg->autostartDir, 0, + cfg->autostartDir, false, caps, qemu_driver->xmlopt, qemuNotifyLoadDomain, qemu_driver); cleanup: diff --git a/src/uml/uml_driver.c b/src/uml/uml_driver.c index 1846835cc..ab7fa7f27 100644 --- a/src/uml/uml_driver.c +++ b/src/uml/uml_driver.c @@ -566,7 +566,7 @@ umlStateInitialize(bool privileged, if (virDomainObjListLoadAllConfigs(uml_driver->domains, uml_driver->configDir, - uml_driver->autostartDir, 0, + uml_driver->autostartDir, false, uml_driver->caps, uml_driver->xmlopt, NULL, NULL) < 0) @@ -634,7 +634,7 @@ umlStateReload(void) umlDriverLock(uml_driver); virDomainObjListLoadAllConfigs(uml_driver->domains, uml_driver->configDir, - uml_driver->autostartDir, 0, + uml_driver->autostartDir, false, uml_driver->caps, uml_driver->xmlopt, umlNotifyLoadDomain, uml_driver); -- 2.14.3

2 1

[libvirt] [PATCH 00/12] qemu: Fully populate JSON formatters for the protocol layer (blockdev-add saga)
by Peter Krempa 08 Nov '17

08 Nov '17

This adds the missing formatters for JSON properties for the storage. John Ferlan (1): qemu: block: Add JSON props generator for iSCSI protocol This patch was stolen from the iSCSI saga and fixed, since the formatter did not format the port number into the portal string. Peter Krempa (11): qemu: block: Use proper type for servers for VxHS disks qemu: process: Split out useful parts from qemuBuildNetworkDriveURI storage: Don't store leading '/' in image name when splitting out volume storage: Store RBD image name as pool and image name qemu: block: Add JSON props generator for 'curl' based storage backends qemu: block: Add JSON props generator for NBD storage backing qemu: block: Add JSON props generator for RBD storage backing qemu: block: Add JSON props generator for sheepdog storage backing qemu: block: Add JSON props generator for ssh storage backing qemu: block: Add node-names to JSON backing storage strings tests: Add testing of storage backend JSON props formatter src/conf/domain_conf.c | 17 +- src/libxl/libxl_conf.c | 2 +- src/qemu/qemu_block.c | 403 ++++++++++++++++++++- src/qemu/qemu_block.h | 4 + src/qemu/qemu_command.c | 40 +- src/util/virstoragefile.c | 26 +- src/xenconfig/xen_xl.c | 2 +- tests/Makefile.am | 14 +- tests/domainsnapshotxml2xmlin/disk_snapshot.xml | 2 +- tests/domainsnapshotxml2xmlout/disk_snapshot.xml | 2 +- tests/qemublocktest.c | 189 ++++++++++ .../qemuxml2argv-disk-drive-network-gluster.args | 2 +- ...muxml2argv-disk-drive-network-tlsx509-vxhs.args | 8 +- .../qemuxml2argv-disk-drive-network-vxhs.args | 4 +- tests/virstoragetest.c | 3 +- 15 files changed, 640 insertions(+), 78 deletions(-) create mode 100644 tests/qemublocktest.c -- 2.14.3

3 23

[libvirt] [PATCH] util: storage: Fix parsing of IPv6 portal address for iSCSI
by Peter Krempa 08 Nov '17

08 Nov '17

Split on the last colon and avoid parsing port if the split remainder contains the closing square bracket, so that IPv6 addresses are interpreted correctly. --- src/util/virstoragefile.c | 3 ++- tests/virstoragetest.c | 20 ++++++++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 3a2d2aa05..e7fcb1238 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -3008,7 +3008,8 @@ virStorageSourceParseBackingJSONiSCSI(virStorageSourcePtr src, if (VIR_STRDUP(src->hosts->name, portal) < 0) goto cleanup; - if ((port = strchr(src->hosts->name, ':'))) { + if ((port = strrchr(src->hosts->name, ':')) && + !strchr(port, ']')) { if (virStringParsePort(port + 1, &src->hosts->port) < 0) goto cleanup; diff --git a/tests/virstoragetest.c b/tests/virstoragetest.c index cfcd8a79c..52a685d91 100644 --- a/tests/virstoragetest.c +++ b/tests/virstoragetest.c @@ -1578,6 +1578,26 @@ mymain(void) "<source protocol='iscsi' name='iqn.2016-12.com.virttest:emulated-iscsi-noauth.target/6'>\n" " <host name='test.org' port='1234'/>\n" "</source>\n"); + TEST_BACKING_PARSE("json:{\"file\":{\"driver\":\"iscsi\"," + "\"transport\":\"tcp\"," + "\"portal\":\"[2001::0]:1234\"," + "\"target\":\"iqn.2016-12.com.virttest:emulated-iscsi-noauth.target\"," + "\"lun\":6" + "}" + "}", + "<source protocol='iscsi' name='iqn.2016-12.com.virttest:emulated-iscsi-noauth.target/6'>\n" + " <host name='[2001::0]' port='1234'/>\n" + "</source>\n"); + TEST_BACKING_PARSE("json:{\"file\":{\"driver\":\"iscsi\"," + "\"transport\":\"tcp\"," + "\"portal\":\"[2001::0]\"," + "\"target\":\"iqn.2016-12.com.virttest:emulated-iscsi-noauth.target\"," + "\"lun\":6" + "}" + "}", + "<source protocol='iscsi' name='iqn.2016-12.com.virttest:emulated-iscsi-noauth.target/6'>\n" + " <host name='[2001::0]' port='3260'/>\n" + "</source>\n"); TEST_BACKING_PARSE("json:{\"file\":{\"driver\":\"sheepdog\"," "\"vdi\":\"test\"," "\"server\":{ \"type\":\"inet\"," -- 2.14.3

2 1

[libvirt] [PATCH go-xml] Add support for host paravirt bootloader.
by Brandon Bergren 08 Nov '17

08 Nov '17

--- domain.go | 2 ++ 1 file changed, 2 insertions(+) diff --git a/domain.go b/domain.go index 2b749b2..f4ef35c 100644 --- a/domain.go +++ b/domain.go @@ -791,6 +791,8 @@ type Domain struct { VCPU *DomainVCPU `xml:"vcpu"` VCPUs *DomainVCPUs `xml:"vcpus"` CPUTune *DomainCPUTune `xml:"cputune"` + Bootloader string `xml:"bootloader,omitempty"` + BootloaderArgs string `xml:"bootloader_args,omitempty"` Resource *DomainResource `xml:"resource"` SysInfo *DomainSysInfo `xml:"sysinfo"` OS *DomainOS `xml:"os"` -- 2.14.1

2 3

[libvirt] [PATCH 0/4] tests: Add caps for QEMU 2.10.0 on non-x86
by Andrea Bolognani 08 Nov '17

08 Nov '17

Patches 1, 2 and 4 are too big for the list, so I'm sending a [REDACTED] version. The full series is available from https://github.com/andreabolognani/libvirt/ in the "caps" branch. Andrea Bolognani (4): tests: Add caps for QEMU 2.10.0 on aarch64 (GICv2) tests: Add caps for QEMU 2.10.0 on aarch64 (GICv3) tests: Rename ppc64le caps to ppc64 tests: Add caps for QEMU 2.10.0 on ppc64 ...qemu_2.6.0.ppc64le.xml => qemu_2.6.0.ppc64.xml} | 2 +- tests/domaincapstest.c | 2 +- ...e.replies => caps_2.10.0-gicv2.aarch64.replies} | 23145 ++++++++----------- .../caps_2.10.0-gicv2.aarch64.xml | 303 + ...e.replies => caps_2.10.0-gicv3.aarch64.replies} | 23145 ++++++++----------- .../caps_2.10.0-gicv3.aarch64.xml | 303 + ...0.ppc64le.replies => caps_2.10.0.ppc64.replies} | 4714 ++-- ...aps_2.9.0.ppc64le.xml => caps_2.10.0.ppc64.xml} | 31 +- ....0.ppc64le.replies => caps_2.6.0.ppc64.replies} | 0 ...caps_2.6.0.ppc64le.xml => caps_2.6.0.ppc64.xml} | 0 ....0.ppc64le.replies => caps_2.9.0.ppc64.replies} | 0 ...caps_2.9.0.ppc64le.xml => caps_2.9.0.ppc64.xml} | 0 tests/qemucapabilitiestest.c | 7 +- 13 files changed, 24043 insertions(+), 27609 deletions(-) rename tests/domaincapsschemadata/{qemu_2.6.0.ppc64le.xml => qemu_2.6.0.ppc64.xml} (98%) copy tests/qemucapabilitiesdata/{caps_2.9.0.ppc64le.replies => caps_2.10.0-gicv2.aarch64.replies} (69%) create mode 100644 tests/qemucapabilitiesdata/caps_2.10.0-gicv2.aarch64.xml copy tests/qemucapabilitiesdata/{caps_2.9.0.ppc64le.replies => caps_2.10.0-gicv3.aarch64.replies} (69%) create mode 100644 tests/qemucapabilitiesdata/caps_2.10.0-gicv3.aarch64.xml copy tests/qemucapabilitiesdata/{caps_2.9.0.ppc64le.replies => caps_2.10.0.ppc64.replies} (83%) copy tests/qemucapabilitiesdata/{caps_2.9.0.ppc64le.xml => caps_2.10.0.ppc64.xml} (99%) rename tests/qemucapabilitiesdata/{caps_2.6.0.ppc64le.replies => caps_2.6.0.ppc64.replies} (100%) rename tests/qemucapabilitiesdata/{caps_2.6.0.ppc64le.xml => caps_2.6.0.ppc64.xml} (100%) rename tests/qemucapabilitiesdata/{caps_2.9.0.ppc64le.replies => caps_2.9.0.ppc64.replies} (100%) rename tests/qemucapabilitiesdata/{caps_2.9.0.ppc64le.xml => caps_2.9.0.ppc64.xml} (100%) -- 2.13.6

2 9

[libvirt] [PATCH v3 0/5] Predictable file names for memory-backend-file
by Michal Privoznik 08 Nov '17

08 Nov '17

v3 of: https://www.redhat.com/archives/libvir-list/2017-October/msg01091.html diff to v2: - Pushed 1/4 and 2/4 from the original series - Split 3/4 into smaller patches Michal Privoznik (5): qemu: Set alias for memory cell in qemuBuildMemoryCellBackendStr qemu: Rename qemuProcessBuildDestroyHugepagesPath qemu: Destroy whole memory tree qemu: Use predictable file names for memory-backend-file news: Document predictable file names for memory-backend-file docs/news.xml | 11 ++ src/qemu/qemu_command.c | 9 +- src/qemu/qemu_conf.c | 55 ++++++++- src/qemu/qemu_conf.h | 9 +- src/qemu/qemu_driver.c | 17 +++ src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_process.c | 137 +++++++++++++++------ src/qemu/qemu_process.h | 8 +- .../qemuxml2argv-cpu-numa-memshared.args | 6 +- .../qemuxml2argv-fd-memory-numa-topology.args | 3 +- .../qemuxml2argv-fd-memory-numa-topology2.args | 6 +- .../qemuxml2argv-fd-memory-numa-topology3.args | 9 +- .../qemuxml2argv-hugepages-memaccess2.args | 9 +- 13 files changed, 218 insertions(+), 63 deletions(-) -- 2.13.6

4 14

[libvirt] Libvirt config converter can't handle file not ending with new line
by Wei Liu 07 Nov '17

07 Nov '17

Hi Jim I discover a problem when using xen_xl converter. When the file in question doesn't end with a new line, I get the following error: error: configuration file syntax error: memory conf:53: expecting a value After digging a bit (but haven't read libvirt code), it appears that the file didn't end with a new line. I have worked around this, but I think this is an issue that should be fixed. Thanks, Wei.

3 4

[libvirt] [PATCH 0/3] cputest: Add more CPU data files
by Jiri Denemark 07 Nov '17

07 Nov '17

Jiri Denemark (3): cputest: Do not drop v[0-9] from CPU names cputest: Add data for Intel(R) Xeon(R) CPU E5-2650 v4 cputest: Add data for Intel(R) Core(TM) i7-7700 CPU tests/cputest.c | 10 +- tests/cputestdata/cpu-parse.sh | 2 +- .../x86_64-cpuid-Core-i7-7700-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-7700-enabled.xml | 9 + ...est.xml => x86_64-cpuid-Core-i7-7700-guest.xml} | 0 ...host.xml => x86_64-cpuid-Core-i7-7700-host.xml} | 0 .../cputestdata/x86_64-cpuid-Core-i7-7700-json.xml | 9 + tests/cputestdata/x86_64-cpuid-Core-i7-7700.json | 499 ++++++++++++++++++++ tests/cputestdata/x86_64-cpuid-Core-i7-7700.xml | 47 ++ ...l => x86_64-cpuid-Xeon-E3-1245-v5-disabled.xml} | 0 ...ml => x86_64-cpuid-Xeon-E3-1245-v5-enabled.xml} | 0 .../x86_64-cpuid-Xeon-E3-1245-v5-guest.xml | 25 + .../x86_64-cpuid-Xeon-E3-1245-v5-host.xml | 26 ++ ...n.xml => x86_64-cpuid-Xeon-E3-1245-v5-json.xml} | 0 ...1245.json => x86_64-cpuid-Xeon-E3-1245-v5.json} | 0 ...3-1245.xml => x86_64-cpuid-Xeon-E3-1245-v5.xml} | 0 ...l => x86_64-cpuid-Xeon-E5-2630-v3-disabled.xml} | 0 ...ml => x86_64-cpuid-Xeon-E5-2630-v3-enabled.xml} | 0 ....xml => x86_64-cpuid-Xeon-E5-2630-v3-guest.xml} | 0 ...t.xml => x86_64-cpuid-Xeon-E5-2630-v3-host.xml} | 0 ...n.xml => x86_64-cpuid-Xeon-E5-2630-v3-json.xml} | 0 ...2630.json => x86_64-cpuid-Xeon-E5-2630-v3.json} | 0 ...5-2630.xml => x86_64-cpuid-Xeon-E5-2630-v3.xml} | 0 ...l => x86_64-cpuid-Xeon-E5-2650-v3-disabled.xml} | 0 ...ml => x86_64-cpuid-Xeon-E5-2650-v3-enabled.xml} | 0 ....xml => x86_64-cpuid-Xeon-E5-2650-v3-guest.xml} | 0 ...t.xml => x86_64-cpuid-Xeon-E5-2650-v3-host.xml} | 0 ...n.xml => x86_64-cpuid-Xeon-E5-2650-v3-json.xml} | 0 ...2650.json => x86_64-cpuid-Xeon-E5-2650-v3.json} | 0 ...5-2650.xml => x86_64-cpuid-Xeon-E5-2650-v3.xml} | 0 ...l => x86_64-cpuid-Xeon-E5-2650-v4-disabled.xml} | 0 .../x86_64-cpuid-Xeon-E5-2650-v4-enabled.xml | 9 + .../x86_64-cpuid-Xeon-E5-2650-v4-guest.xml | 30 ++ .../x86_64-cpuid-Xeon-E5-2650-v4-host.xml | 34 ++ .../x86_64-cpuid-Xeon-E5-2650-v4-json.xml | 11 + .../cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.json | 505 +++++++++++++++++++++ tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.xml | 43 ++ .../x86_64-cpuid-Xeon-E7-8890-v3-disabled.xml | 6 + ...ml => x86_64-cpuid-Xeon-E7-8890-v3-enabled.xml} | 0 ....xml => x86_64-cpuid-Xeon-E7-8890-v3-guest.xml} | 0 ...t.xml => x86_64-cpuid-Xeon-E7-8890-v3-host.xml} | 0 ...n.xml => x86_64-cpuid-Xeon-E7-8890-v3-json.xml} | 0 ...8890.json => x86_64-cpuid-Xeon-E7-8890-v3.json} | 0 ...7-8890.xml => x86_64-cpuid-Xeon-E7-8890-v3.xml} | 0 44 files changed, 1266 insertions(+), 5 deletions(-) create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700-enabled.xml rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-guest.xml => x86_64-cpuid-Core-i7-7700-guest.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-host.xml => x86_64-cpuid-Core-i7-7700-host.xml} (100%) create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700.json create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-7700.xml rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-disabled.xml => x86_64-cpuid-Xeon-E3-1245-v5-disabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-enabled.xml => x86_64-cpuid-Xeon-E3-1245-v5-enabled.xml} (100%) create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E3-1245-v5-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E3-1245-v5-host.xml rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245-json.xml => x86_64-cpuid-Xeon-E3-1245-v5-json.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245.json => x86_64-cpuid-Xeon-E3-1245-v5.json} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E3-1245.xml => x86_64-cpuid-Xeon-E3-1245-v5.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-disabled.xml => x86_64-cpuid-Xeon-E5-2630-v3-disabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-enabled.xml => x86_64-cpuid-Xeon-E5-2630-v3-enabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-guest.xml => x86_64-cpuid-Xeon-E5-2630-v3-guest.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-host.xml => x86_64-cpuid-Xeon-E5-2630-v3-host.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630-json.xml => x86_64-cpuid-Xeon-E5-2630-v3-json.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630.json => x86_64-cpuid-Xeon-E5-2630-v3.json} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2630.xml => x86_64-cpuid-Xeon-E5-2630-v3.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-disabled.xml => x86_64-cpuid-Xeon-E5-2650-v3-disabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-enabled.xml => x86_64-cpuid-Xeon-E5-2650-v3-enabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-guest.xml => x86_64-cpuid-Xeon-E5-2650-v3-guest.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-host.xml => x86_64-cpuid-Xeon-E5-2650-v3-host.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650-json.xml => x86_64-cpuid-Xeon-E5-2650-v3-json.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650.json => x86_64-cpuid-Xeon-E5-2650-v3.json} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E5-2650.xml => x86_64-cpuid-Xeon-E5-2650-v3.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-disabled.xml => x86_64-cpuid-Xeon-E5-2650-v4-disabled.xml} (100%) create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E5-2650-v4.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-8890-v3-disabled.xml rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-enabled.xml => x86_64-cpuid-Xeon-E7-8890-v3-enabled.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-guest.xml => x86_64-cpuid-Xeon-E7-8890-v3-guest.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-host.xml => x86_64-cpuid-Xeon-E7-8890-v3-host.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890-json.xml => x86_64-cpuid-Xeon-E7-8890-v3-json.xml} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890.json => x86_64-cpuid-Xeon-E7-8890-v3.json} (100%) rename tests/cputestdata/{x86_64-cpuid-Xeon-E7-8890.xml => x86_64-cpuid-Xeon-E7-8890-v3.xml} (100%) -- 2.14.3

2 4

[libvirt] [PATCH 0/2] Update documentation for latest vbox changes.
by Dawid Zamirski 07 Nov '17

07 Nov '17

* update docs/drvvbox.html.in to show support for <controller> * update docs/fomatdomain.html.in to describe autoport behavior in the vbox driver Dawid Zamirski (2): docs: Update vbox driver documentation. docs: Document autoport behavior in the vbox driver docs/drvvbox.html.in | 28 +++++++++++++++++++++++++++- docs/formatdomain.html.in | 5 ++++- 2 files changed, 31 insertions(+), 2 deletions(-) -- 2.14.2

2 5

[libvirt] [PATCH v3 00/13] vbox: Improve handling of storage devices
by Dawid Zamirski 07 Nov '17

07 Nov '17

v2: https://www.redhat.com/archives/libvir-list/2017-October/msg01108.html Changes since v2: * Rebase on master * Do not segfault in 'Cleanup partially-defined VM on failure' when code jumps to cleanup and machine is NULL * Take out SAS controller handling code into a separate patch * Split up the snapshot function cleanup code into separate patches * Fixed code formatting as pointed out in review * Rename vboxDumpIDEHDDs -> vboxDumpDisks into a separate patch * Add docs/news.xml patch to describe improvements/fixes in the series Dawid Zamirski (13): vbox: Cleanup partially-defined VM on failure vbox: Process <controller> element in domain XML vbox: Add vboxDumpStorageControllers vbox: Rename vboxDumpIDEHDDs to vboxDumpDisks vbox: Cleanup/prepare snasphot dumpxml functions vbox: Do not free disk definitions on cleanup vbox: Swap vboxSnapshotGetReadOnlyDisks arguments vbox: Correctly generate drive name in dumpxml vbox: Cleanup vboxDumpDisks implementation vbox: Process empty removable disks in dumpxml vbox: Generate disk address element in dumpxml vbox: Add SAS controller support docs: Update news.xml with vbox changes. docs/news.xml | 74 ++++ src/vbox/vbox_common.c | 1105 +++++++++++++++++++++++++++++++----------------- src/vbox/vbox_common.h | 8 + 3 files changed, 792 insertions(+), 395 deletions(-) -- 2.14.3

2 16

[libvirt] [PATCH v2 00/15] vbox: Improve handling of storage devices
by Dawid Zamirski 07 Nov '17

07 Nov '17

From: Dawid Zamirski <dzrudy(a)gmail.com> v1: https://www.redhat.com/archives/libvir-list/2017-October/msg00381.html Changes since v1: * split out the original patches into smaller ones, with each bugfix or cleanup task is in its own isolated and compilable patch * make sure switch statements are type casted and all cases are handled * fixed implementation of partial VM cleanup code and isolated into separate patch (patch #3) * squashed doc and rng updates into a single patch (#9), updated doc wording as suggested * addressed other minor issues (add debug statements, code formatting, better comments, commit message spelling etc) Dawid Zamirski (15): vbox: Update ATTRIBUTE_UNUSED usage vbox: Close media when undefining domains vbox: Cleanup partially-defined VM on failure vbox: vboxAttachDrives now relies on address info vbox: Cleanup vboxAttachDrives implementation vbox: Errors in vboxAttachDrives are now critical vbox: Support empty removable drives. vbox: Add more IStorageController API mappings domain: Allow 'model' attribute for ide controller vbox: Process <controller> element in domain XML vbox: Add vboxDumpStorageControllers vbox: Correctly generate drive name in dumpxml vbox: Cleanup vboxDumpDisks implementation vbox: Process empty removable disks in dumpxml vbox: Generate disk address element in dumpxml docs/formatdomain.html.in | 4 + docs/schemas/domaincommon.rng | 18 +- src/conf/domain_conf.c | 9 + src/conf/domain_conf.h | 9 + src/libvirt_private.syms | 2 + src/vbox/vbox_common.c | 1422 +++++++++++++++++++++++++---------------- src/vbox/vbox_common.h | 21 + src/vbox/vbox_tmpl.c | 93 ++- src/vbox/vbox_uniformed_api.h | 3 + 9 files changed, 983 insertions(+), 598 deletions(-) -- 2.14.2

2 36

[libvirt] [PATCH 0/2] Misc apparmor fixes
by Christian Ehrhardt 07 Nov '17

07 Nov '17

Hi, here a few more apparmor fixes for your review. One is for an Ubuntu bug [1] which is non fatal, but denies a qemu fix to fully work. The other one I was carried in Ubuntu for some time and is related to ipv6 only setups where virt-aa-helper can fail if not permitted inet6. [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1729626 Christian Ehrhardt (2): apparmor: allow qemu to read max_segments apparmor, virt-aa-helper: allow ipv6 examples/apparmor/libvirt-qemu | 3 +++ examples/apparmor/usr.lib.libvirt.virt-aa-helper | 1 + 2 files changed, 4 insertions(+) -- 2.7.4

3 5

[libvirt] [PATCH REPOST 0/8] Privatize _virStoragePoolObj and _virStorageVolDefList (Batch #3)
by John Ferlan 07 Nov '17

07 Nov '17

Since the original series (19 patches): https://www.redhat.com/archives/libvir-list/2017-September/msg00594.html didn't garner any attention, I'm going with smaller patch piles to make forward progress. This is the last half of the storage backends plus one missed merge (because I broke things up <sigh>) John Ferlan (8): storage: Use virStoragePoolObjGetDef accessor for iSCSI backend storage: Use virStoragePoolObjGetDef accessor for MPATH backend storage: Use virStoragePoolObjGetDef accessor for RBD backend storage: Use virStoragePoolObjGetDef accessor for SCSI backend storage: Use virStoragePoolObjGetDef accessor for VSTORAGE backend storage: Use virStoragePoolObjGetDef accessor for ZFS backend storage: Use virStoragePoolObjGetDef accessor for new driver events storage: Privatize virStoragePoolObj and virStorageVolDefList src/conf/storage_conf.h | 4 --- src/conf/virstorageobj.c | 20 +++++++++++ src/conf/virstorageobj.h | 15 -------- src/storage/storage_backend_iscsi.c | 41 ++++++++++++---------- src/storage/storage_backend_mpath.c | 8 +++-- src/storage/storage_backend_rbd.c | 64 ++++++++++++++++++---------------- src/storage/storage_backend_scsi.c | 30 +++++++++------- src/storage/storage_backend_vstorage.c | 31 ++++++++-------- src/storage/storage_backend_zfs.c | 39 ++++++++++++--------- src/storage/storage_driver.c | 8 ++--- 10 files changed, 144 insertions(+), 116 deletions(-) -- 2.13.6

2 11

[libvirt] [PATCH v2] vz: allow to start vz driver without host cache info
by Mikhail Feoktistov 07 Nov '17

07 Nov '17

Show warning message instead of fail operation. It happens if kernel or cpu doesn't support reporting cpu cache info. In case of Virtuozzo file "id" doesn't exist. --- src/vz/vz_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index 6f4aee3..eb97e54 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -119,7 +119,7 @@ vzBuildCapabilities(void) goto error; if (virCapabilitiesInitCaches(caps) < 0) - goto error; + VIR_WARN("Failed to get host CPU cache info"); verify(ARRAY_CARDINALITY(archs) == ARRAY_CARDINALITY(emulators)); -- 1.8.3.1

2 5

[libvirt] Interim fix for exposing VMware firmware=bios|efi in libvirt XML
by Richard W.M. Jones 07 Nov '17

07 Nov '17

https://bugzilla.redhat.com/show_bug.cgi?id=1217444 VMware guests can use either BIOS or UEFI firmware. VMware itself exposes this information in the VMX file and it's available to the ESX driver in libvirt. virt-v2v wants to consume this information. Unfortunately after a few years and iterations we've not come up with an acceptable patch to expose “has UEFI” in the libvirt XML. (Latest patch was: https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html ) Could we instead add a temporary addition to the XML generated by the ESX driver? I'm thinking something like the existing <vmware:moref> and <vmware:datacenterpath> fields: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>Fedora</name> ... <vmware:datacenterpath>ha-datacenter</vmware:datacenterpath> <vmware:moref>2</vmware:moref> <vmware:firmware>uefi</vmware:firmware>  </domain> This field would be informational, ie. the ESX driver would create it but not read it when creating new VMs. This would solve our immediate problem in virt-v2v and is pretty simple to implement. Also it doesn't close off any future general solution. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/

2 1

[libvirt] [RFC] docs: Discourage usage of cache mode=passthrough
by Eduardo Habkost 06 Nov '17

06 Nov '17

Cache mode=passthrough can result in a broken cache topology if the domain topology is not exactly the same as the host topology. Warn about that in the documentation. Bug report for reference: https://bugzilla.redhat.com/show_bug.cgi?id=1184125 Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> --- docs/formatdomain.html.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 57ec2ff34..9c21892f3 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1478,7 +1478,9 @@ <dt><code>passthrough</code></dt> <dd>The real CPU cache data reported by the host CPU will be - passed through to the virtual CPU.</dd> + passed through to the virtual CPU. Using this mode is not + recommended unless the domain CPU and NUMA topology is exactly + the same as the host CPU and NUMA topology.</dd> <dt><code>disable</code></dt> <dd>The virtual CPU will report no CPU cache of the specified -- 2.13.5

3 8

[libvirt] [PATCH] conf: Don't inline virDomainNetTypeSharesHostView()
by Andrea Bolognani 06 Nov '17

06 Nov '17

Introduced in d86fd2402e9d. Fails to compile on aarch64 with qemu/qemu_driver.c: In function 'qemuDomainSetInterfaceParameters': ./conf/domain_conf.h:3406:1: error: inlining failed in call to 'virDomainNetTypeSharesHostView': call is unlikely and code size would grow [-Werror=inline] virDomainNetTypeSharesHostView(const virDomainNetDef *net) ^ qemu/qemu_driver.c:11240:66: error: called from here [-Werror=inline] !virDomainNetTypeSharesHostView(net)) < 0 || ^ Solve the issue by turning it into a regular function. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/conf/domain_conf.c | 35 +++++++++++++++++++++++++++++++++++ src/conf/domain_conf.h | 36 ++---------------------------------- src/libvirt_private.syms | 1 + 3 files changed, 38 insertions(+), 34 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index f9ae05769..2b06250df 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -28091,3 +28091,38 @@ virDomainGenerateMachineName(const char *drivername, virBufferCheckError(&buf); return virBufferContentAndReset(&buf); } + +/** + * virDomainNetTypeSharesHostView: + * @net: interface + * + * Some types of interfaces "share" the host view. For instance, + * for macvtap interface, every domain RX is the host RX too. And + * every domain TX is host TX too. IOW, for some types of + * interfaces guest and host are on the same side of RX/TX + * barrier. This is important so that we set up QoS correctly and + * report proper stats. + */ +bool +virDomainNetTypeSharesHostView(const virDomainNetDef *net) +{ + virDomainNetType actualType = virDomainNetGetActualType(net); + switch (actualType) { + case VIR_DOMAIN_NET_TYPE_DIRECT: + case VIR_DOMAIN_NET_TYPE_ETHERNET: + return true; + case VIR_DOMAIN_NET_TYPE_USER: + case VIR_DOMAIN_NET_TYPE_VHOSTUSER: + case VIR_DOMAIN_NET_TYPE_SERVER: + case VIR_DOMAIN_NET_TYPE_CLIENT: + case VIR_DOMAIN_NET_TYPE_MCAST: + case VIR_DOMAIN_NET_TYPE_NETWORK: + case VIR_DOMAIN_NET_TYPE_BRIDGE: + case VIR_DOMAIN_NET_TYPE_INTERNAL: + case VIR_DOMAIN_NET_TYPE_HOSTDEV: + case VIR_DOMAIN_NET_TYPE_UDP: + case VIR_DOMAIN_NET_TYPE_LAST: + break; + } + return false; +} diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 0def905b2..7f21f9871 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -3391,40 +3391,8 @@ virDomainGenerateMachineName(const char *drivername, int id, const char *name, bool privileged); -/** - * virDomainNetTypeSharesHostView: - * @net: interface - * - * Some types of interfaces "share" the host view. For instance, - * for macvtap interface, every domain RX is the host RX too. And - * every domain TX is host TX too. IOW, for some types of - * interfaces guest and host are on the same side of RX/TX - * barrier. This is important so that we set up QoS correctly and - * report proper stats. - */ -static inline bool -virDomainNetTypeSharesHostView(const virDomainNetDef *net) -{ - virDomainNetType actualType = virDomainNetGetActualType(net); - switch (actualType) { - case VIR_DOMAIN_NET_TYPE_DIRECT: - case VIR_DOMAIN_NET_TYPE_ETHERNET: - return true; - case VIR_DOMAIN_NET_TYPE_USER: - case VIR_DOMAIN_NET_TYPE_VHOSTUSER: - case VIR_DOMAIN_NET_TYPE_SERVER: - case VIR_DOMAIN_NET_TYPE_CLIENT: - case VIR_DOMAIN_NET_TYPE_MCAST: - case VIR_DOMAIN_NET_TYPE_NETWORK: - case VIR_DOMAIN_NET_TYPE_BRIDGE: - case VIR_DOMAIN_NET_TYPE_INTERNAL: - case VIR_DOMAIN_NET_TYPE_HOSTDEV: - case VIR_DOMAIN_NET_TYPE_UDP: - case VIR_DOMAIN_NET_TYPE_LAST: - break; - } - return false; -} + +bool virDomainNetTypeSharesHostView(const virDomainNetDef *net); bool virDomainDefLifecycleActionAllowed(virDomainLifecycle type, diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 2e67366b7..36cd5b55b 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -446,6 +446,7 @@ virDomainNetInsert; virDomainNetRemove; virDomainNetRemoveHostdev; virDomainNetTypeFromString; +virDomainNetTypeSharesHostView; virDomainNetTypeToString; virDomainNostateReasonTypeFromString; virDomainNostateReasonTypeToString; -- 2.13.6

3 2

[libvirt] [PATCH] remote: Fix libvirtd service memory leak when libvirt client was terminated unexpectly
by xinhua.Cao 06 Nov '17

06 Nov '17

base on commit 2033e8cc119454bc4273e8a41e66c899c60ba58b and fe8f1c8b8650c8ab5e7d27338f4538582651bd14, we solve libvirt coredump problem, but it introduce a memory leak sense. the sense follow 1. one client register a domain event such as reboot event 2. and client was terminated unexpectly, then this client will not free at libvirtd service program. remoteDispatchConnectDomainEventCallbackRegisterAny reference the client, but when client was terminated before it call deRegisterAny, the reference of client will not reduced to zero. so the memory leak take place. this patch will deRegister all event when client was close. --- daemon/remote.c | 47 +++++++++++++++++++++++++++++------------------ 1 file changed, 29 insertions(+), 18 deletions(-) diff --git a/daemon/remote.c b/daemon/remote.c index 3f7d2d3..2b5a18b 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -1686,25 +1686,16 @@ void remoteRelayConnectionClosedEvent(virConnectPtr conn ATTRIBUTE_UNUSED, int r VIR_WARN("unexpected %s event deregister failure", name); \ } \ VIR_FREE(eventCallbacks); \ + neventCallbacks = 0; \ } while (0); -/* - * You must hold lock for at least the client - * We don't free stuff here, merely disconnect the client's - * network socket & resources. - * We keep the libvirt connection open until any async - * jobs have finished, then clean it up elsewhere - */ -void remoteClientFreeFunc(void *data) +static void +remoteFreePrivCallbacks(void *data) { struct daemonClientPrivate *priv = data; /* Deregister event delivery callback */ - if (priv->conn) { - virIdentityPtr sysident = virIdentityGetSystem(); - - virIdentitySetCurrent(sysident); - + if (priv && priv->conn) { DEREG_CB(priv->conn, priv->domainEventCallbacks, priv->ndomainEventCallbacks, virConnectDomainEventDeregisterAny, "domain"); @@ -1723,6 +1714,26 @@ void remoteClientFreeFunc(void *data) DEREG_CB(priv->conn, priv->qemuEventCallbacks, priv->nqemuEventCallbacks, virConnectDomainQemuMonitorEventDeregister, "qemu monitor"); + } +} +#undef DEREG_CB + +/* + * You must hold lock for at least the client + * We don't free stuff here, merely disconnect the client's + * network socket & resources. + * We keep the libvirt connection open until any async + * jobs have finished, then clean it up elsewhere + */ +void remoteClientFreeFunc(void *data) +{ + struct daemonClientPrivate *priv = data; + + if (priv) { + virIdentityPtr sysident = virIdentityGetSystem(); + + virIdentitySetCurrent(sysident); + remoteFreePrivCallbacks(priv); if (priv->closeRegistered) { if (virConnectUnregisterCloseCallback(priv->conn, @@ -1734,18 +1745,18 @@ void remoteClientFreeFunc(void *data) virIdentitySetCurrent(NULL); virObjectUnref(sysident); + VIR_FREE(priv); } - - VIR_FREE(priv); } -#undef DEREG_CB - static void remoteClientCloseFunc(virNetServerClientPtr client) { struct daemonClientPrivate *priv = virNetServerClientGetPrivateData(client); - daemonRemoveAllClientStreams(priv->streams); + if (priv) { + daemonRemoveAllClientStreams(priv->streams); + remoteFreePrivCallbacks(priv); + } } -- 2.8.3

3 6

[libvirt] [PATCH 0/2] Removing backend support when net interface is user/direct/hostdev.
by Julio Faracco 05 Nov '17

05 Nov '17

The <backend> xml tag is not supported for some interface types and the virsh command 'attach-device' permits to add <backend> settings to all of them. These commits avoid <backend> for user, direct and hostdev interface types. Julio Faracco (2): tests: removing backend xml tag inside some test cases. conf: network user/direct/hostdev do not support backend tag. src/conf/domain_conf.c | 10 ++++++++++ tests/qemuxml2argvdata/qemuxml2argv-tap-vhost-incorrect.xml | 2 -- tests/qemuxml2argvdata/qemuxml2argv-tap-vhost.xml | 1 - tests/qemuxml2argvtest.c | 6 +++--- .../qemuxml2xmloutdata/qemuxml2xmlout-tap-vhost-incorrect.xml | 2 -- tests/qemuxml2xmloutdata/qemuxml2xmlout-tap-vhost.xml | 1 - 6 files changed, 13 insertions(+), 9 deletions(-) -- 2.7.4

2 4

[libvirt] [PATCH go-xml] Improve DomainChardevSource.
by Brandon Bergren 04 Nov '17

04 Nov '17

* Add missing attributes to DomainChardevSource. * Change Path to be omitempty because several chardev types do not use it. * Document which chardev types use which attributes (for convenience) I was mainly interested in making it possible to define nmdm devices from go code, but I figured I would add the other missing attributes while I was here. --- domain.go | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/domain.go b/domain.go index f4ef35c..debc5b2 100644 --- a/domain.go +++ b/domain.go @@ -256,9 +256,15 @@ type DomainInterface struct { } type DomainChardevSource struct { - Mode string `xml:"mode,attr,omitempty"` - Path string `xml:"path,attr"` - Append string `xml:"append,attr,omitempty"` + Mode string `xml:"mode,attr,omitempty"` // tcp,udp,unix + Path string `xml:"path,attr,omitempty"` // file,pty,dev,pipe + Channnel string `xml:"channel,attr,omitempty"` // spiceport + Append string `xml:"append,attr,omitempty"` // file + Host string `xml:"host,attr,omitempty"` // tcp,udp + Service string `xml:"service,attr,omitempty"` // tcp,udp + TLS string `xml:"tls,attr,omitempty"` // tcp(QEMU) + Master string `xml:"master,attr,omitempty"` // nmdm + Slave string `xml:"slave,attr,omitempty"` // nmdm } type DomainChardevTarget struct { -- 2.14.1

1 1

Re: [libvirt] How to best handle the reoccurring of rom changes breaking cross version migrations?
by Christian Ehrhardt 03 Nov '17

03 Nov '17

Ping - since there wasn't any reply so far - any best practices one could share? Let me add a TL;DR: - bump of ipxe rom versions change the size of virtio-net-pci.rom - that breaks on migration "Length mismatch" I'd guess the size of that rom has to be fixed up on the fly, but if that is really ok and how/where is the question. Also to +1 on bad things for today - I made this a cross post to libvirt in case there is one that has done that in the past. On Mon, Aug 28, 2017 at 4:36 PM, Christian Ehrhardt < christian.ehrhardt(a)canonical.com> wrote: > Hi, > migration issues due to rom changes seem to occur over and over in past > years [1], [2],[3],[4],[5]. > From the past I know several workarounds (like just truncating to the > bigger size) but all have various deficiencies. > > But OTOH rom's will always change due to fixes in them. And recently I > found one such change [6] that affects the next Ubuntu release and wonder > what the ?right?, well lets say best way to fix it would be. > Current issue: > Length mismatch: 0000:00:03.0/virtio-net-pci.rom: 0x40000 in != 0x80000: > Invalid argument > Due to efi-virtio.rom growing over 256k due to an update to a newer ipxe > from upstream. > > I beg your pardon (for not being educated enough on this yet), but I want > to avoid to go a route that is fixing it in a sub-optimal way and ask for > some guidance. There might be better ways in the modern qemu of today than > there were in the past. > TL;DR I look for the best way (if any) to declare in the new qemu: "I know > that the old size was smaller, let me fix that up on migration". > > I'll try on my own as I expect the machine type structures/mechanisms (and > we have Ubuntu specific types that could encapsulate the rom status from > the ipxe package to be coupled with the type) have all that is needed. > Yet me almost randomly trying around there surely isn't the best way to go > - so if there is some existing case or a short hint at what in there might > be the best way to fixup a changed rom size on a migration I'd be very > happy to hear about that. > > [1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1536331 > [2]: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg01881.html > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1293566 > [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1090093 > [5]: https://forge.univention.org/bugzilla/show_bug.cgi?id=38877 > [6]: https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1713490 > > P.S: As everybody else I don't mind so much on reverse migration to older > releases > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

3 3

[libvirt] [REPOST PATCH v6 0/8] Use secret objects to pass iSCSI passwords
by John Ferlan 03 Nov '17

03 Nov '17

Reposting after 3.9.0 release and refresh to current HEAD. Had to move the news.xml into the 3.10.0 section as well and address a couple of merge conflicts. Original: https://www.redhat.com/archives/libvir-list/2017-October/msg01012.html Copy of Original cover letter: v5: https://www.redhat.com/archives/libvir-list/2017-October/msg00228.html FWIW: AFAICT this series does not need/require changes that Peter has posted for continuing blocked-add saga related to user-specified backing chains: https://www.redhat.com/archives/libvir-list/2017-October/msg00956.html Changes since v5: * Some patches pushed as part of Peter Krempa's work and the two patches to perform the parsing of auth and encryption data in virStorageSource were pushed separately * Removed patches dealing with qemuDomainStorageSourceCopy and virDomainDiskStorageSourceNew Patches 9->16 reworked Patch1: (previous patch 10) - Rework logic to remove the need to pass around the @xmlopt for virStorageSourcePtr allocation and instead VIR_ALLOC(iscsisrc->src) directly as other consumers do. Patch2: (previous patch 11) - Use the qemuDomainStorageSourcePrivatePtr and friend macro QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE to manage the iscsisrc->src data making sure to ensure that srcPriv (e.g. privateData) exists. Patch3: (previous patch 12) - Only minor merge related changes. Patch4: (previous patch 13) - Merge related plus additional check to ensure srcPriv exists before dereference secinfo Patch5: (previous patch 14) - No change Patch 6: (previous patch 15) - Merge related changes, plus checks for srcPriv before deref secinfo NB: Testing note - I did ensure at this point if the password secret capability check fails that the code will still do the right thing. Patch7: (previous patch 9) - No change... Presented since it wasn't ACK'd before Patch8: (previous patch16) - No change John Ferlan (8): conf,qemu: Replace iscsisrc fields with virStorageSourcePtr qemu: Use private storage source for iscsi instead of private hostdev qemu: Remove private hostdev qemu: Refactor qemuBuildSCSIiSCSIHostdevDrvStr slightly qemu: Get capabilities to use iscsi password-secret argument qemu: Use secret objects to pass iSCSI passwords docs: Add news article regarding auth/encryption placement docs: Add news article to describe iSCSI usage of secret object docs/news.xml | 23 ++++++ src/conf/domain_conf.c | 58 ++++++++-------- src/conf/domain_conf.h | 9 +-- src/lxc/lxc_native.c | 2 +- src/qemu/qemu_block.c | 65 ++++++++++++++++- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 75 +++++++++++++++----- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_domain.c | 81 +++++++--------------- src/qemu/qemu_domain.h | 14 ---- src/qemu/qemu_hotplug.c | 52 +++++++++++++- src/qemu/qemu_parse_command.c | 4 +- src/vbox/vbox_common.c | 2 +- src/xenconfig/xen_common.c | 2 +- src/xenconfig/xen_sxpr.c | 2 +- src/xenconfig/xen_xl.c | 2 +- tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + ...xml2argv-disk-drive-network-iscsi-auth-AES.args | 41 +++++++++++ ...uxml2argv-disk-drive-network-iscsi-auth-AES.xml | 43 ++++++++++++ ...ml2argv-hostdev-scsi-virtio-iscsi-auth-AES.args | 45 ++++++++++++ ...xml2argv-hostdev-scsi-virtio-iscsi-auth-AES.xml | 48 +++++++++++++ tests/qemuxml2argvtest.c | 10 +++ tests/virhostdevtest.c | 2 +- 28 files changed, 451 insertions(+), 140 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-auth-AES.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-iscsi-auth-AES.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi-auth-AES.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-virtio-iscsi-auth-AES.xml -- 2.13.6

1 8

[libvirt] [PATCH] cpu_map: Add cqm alternative name for cmt
by Jiri Denemark 03 Nov '17

03 Nov '17

Linux kernel shows our "cmt" feature as "cqm". Let's mention the name in the cpu_map.xml to make it easier to find. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/cpu/cpu_map.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 96f4ce60d..e5da7a887 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -224,7 +224,7 @@ <feature name='rtm'> <cpuid eax_in='0x07' ecx_in='0x00' ebx='0x00000800'/> </feature> - <feature name='cmt'> + <feature name='cmt'>  <cpuid eax_in='0x07' ecx_in='0x00' ebx='0x00001000'/> </feature> <feature name='mpx'> -- 2.14.3

3 2

[libvirt] [PATCH 0/9] qemu: command: -drive formatting cleanups (blockdev-add saga)
by Peter Krempa 03 Nov '17

03 Nov '17

Kill some ugly code. Peter Krempa (9): util: Fix condition check in virDiskNameToIndex qemu: command: Remove dead code when formatting -drive qemu: command: Move disk index validation closer to usage qemu: command: Directly report bus type in qemuBuildDriveStrValidate qemu: command: Refactor qemuBuildDriveStrValidate to make qemuCaps optional qemu: command: Merge checks from qemuBuildDriveStrValidate to qemuCheckDiskConfig qemu: command: Refactor blkiotune checks to tolerate NULL qemuCaps qemu: command: Move blkiotune checks to qemuCheckDiskConfig qemu: command: Move disk serial validation to checker function src/qemu/qemu_command.c | 485 +++++++++++++++++++++++------------------------- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_driver.c | 2 +- src/util/virutil.c | 2 +- 4 files changed, 236 insertions(+), 256 deletions(-) -- 2.14.3

2 13

[libvirt] [PATCH] conf: Don't inline virDomainNetTypeSharesHostView
by Jiri Denemark 03 Nov '17

03 Nov '17

When coverage build is enabled, gcc complains about it: In file included from qemu/qemu_agent.h:29:0, from qemu/qemu_driver.c:47: qemu/qemu_driver.c: In function 'qemuDomainSetInterfaceParameters': ./conf/domain_conf.h:3397:1: error: inlining failed in call to 'virDomainNetTypeSharesHostView': call is unlikely and code size would grow [-Werror=inline] virDomainNetTypeSharesHostView(const virDomainNetDef *net) ^ Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- Notes: Shouldn't we just kill all (or most of) our worthless usage of the inline keyword? src/conf/domain_conf.c | 36 ++++++++++++++++++++++++++++++++++++ src/conf/domain_conf.h | 37 +++---------------------------------- src/libvirt_private.syms | 1 + 3 files changed, 40 insertions(+), 34 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 77c20c697..394afb0d8 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -28082,3 +28082,39 @@ virDomainGenerateMachineName(const char *drivername, virBufferCheckError(&buf); return virBufferContentAndReset(&buf); } + + +/** + * virDomainNetTypeSharesHostView: + * @net: interface + * + * Some types of interfaces "share" the host view. For instance, + * for macvtap interface, every domain RX is the host RX too. And + * every domain TX is host TX too. IOW, for some types of + * interfaces guest and host are on the same side of RX/TX + * barrier. This is important so that we set up QoS correctly and + * report proper stats. + */ +bool +virDomainNetTypeSharesHostView(const virDomainNetDef *net) +{ + virDomainNetType actualType = virDomainNetGetActualType(net); + switch (actualType) { + case VIR_DOMAIN_NET_TYPE_DIRECT: + case VIR_DOMAIN_NET_TYPE_ETHERNET: + return true; + case VIR_DOMAIN_NET_TYPE_USER: + case VIR_DOMAIN_NET_TYPE_VHOSTUSER: + case VIR_DOMAIN_NET_TYPE_SERVER: + case VIR_DOMAIN_NET_TYPE_CLIENT: + case VIR_DOMAIN_NET_TYPE_MCAST: + case VIR_DOMAIN_NET_TYPE_NETWORK: + case VIR_DOMAIN_NET_TYPE_BRIDGE: + case VIR_DOMAIN_NET_TYPE_INTERNAL: + case VIR_DOMAIN_NET_TYPE_HOSTDEV: + case VIR_DOMAIN_NET_TYPE_UDP: + case VIR_DOMAIN_NET_TYPE_LAST: + break; + } + return false; +} diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 38de70b15..171f34078 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -3382,40 +3382,9 @@ virDomainGenerateMachineName(const char *drivername, int id, const char *name, bool privileged); -/** - * virDomainNetTypeSharesHostView: - * @net: interface - * - * Some types of interfaces "share" the host view. For instance, - * for macvtap interface, every domain RX is the host RX too. And - * every domain TX is host TX too. IOW, for some types of - * interfaces guest and host are on the same side of RX/TX - * barrier. This is important so that we set up QoS correctly and - * report proper stats. - */ -static inline bool -virDomainNetTypeSharesHostView(const virDomainNetDef *net) -{ - virDomainNetType actualType = virDomainNetGetActualType(net); - switch (actualType) { - case VIR_DOMAIN_NET_TYPE_DIRECT: - case VIR_DOMAIN_NET_TYPE_ETHERNET: - return true; - case VIR_DOMAIN_NET_TYPE_USER: - case VIR_DOMAIN_NET_TYPE_VHOSTUSER: - case VIR_DOMAIN_NET_TYPE_SERVER: - case VIR_DOMAIN_NET_TYPE_CLIENT: - case VIR_DOMAIN_NET_TYPE_MCAST: - case VIR_DOMAIN_NET_TYPE_NETWORK: - case VIR_DOMAIN_NET_TYPE_BRIDGE: - case VIR_DOMAIN_NET_TYPE_INTERNAL: - case VIR_DOMAIN_NET_TYPE_HOSTDEV: - case VIR_DOMAIN_NET_TYPE_UDP: - case VIR_DOMAIN_NET_TYPE_LAST: - break; - } - return false; -} + +bool +virDomainNetTypeSharesHostView(const virDomainNetDef *net); bool virDomainDefLifecycleActionAllowed(virDomainLifecycle type, diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 448d962b2..811d9053e 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -444,6 +444,7 @@ virDomainNetInsert; virDomainNetRemove; virDomainNetRemoveHostdev; virDomainNetTypeFromString; +virDomainNetTypeSharesHostView; virDomainNetTypeToString; virDomainNostateReasonTypeFromString; virDomainNostateReasonTypeToString; -- 2.14.3

2 1

[libvirt] [PATCH 00/12] qemu: block: Prepare for user-specified backing chains (blockdev-add saga)
by Peter Krempa 03 Nov '17

03 Nov '17

When users will specify backing chain, we need to take into account what was passed in them and/or inherit the data from the parents as we are copying the data (labels, etc...) from the parent disk source. Peter Krempa (12): storage: Extract common code to retrieve driver backend for support check storage: Add feature check for storage file backend supporting access check storage: Extract error reporting for broken chains security: selinux: Pass parent storage source into image labeling helper security: dac: Take parent security label into account security: selinux: Take parent security label into account qemu: domain: Simplify using DAC permissions of top of backing chain qemu: domain: Extract setup for disk source secrets qemu: domain: Destroy secrets for complete backing chain qemu: domain: Remove pointless alias check qemu: domain: Prepare TLS data for the whole backing chain qemu: domain: skip chain detection to end of backing chain src/qemu/qemu_domain.c | 177 ++++++++++++++++++++++++++-------------- src/qemu/qemu_domain.h | 6 +- src/qemu/qemu_driver.c | 6 +- src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_process.c | 2 +- src/security/security_dac.c | 38 +++++++-- src/security/security_selinux.c | 26 +++--- src/storage/storage_source.c | 110 ++++++++++++++++--------- src/storage/storage_source.h | 5 ++ 9 files changed, 246 insertions(+), 126 deletions(-) -- 2.14.1

2 26

[libvirt] storage lock issues
by Cedric Bosdonnat 02 Nov '17

02 Nov '17

Hi all, I'm investigating a crash in the storage driver, and it seems the solution is not as obvious as I wanted it. Basically what happens is that libvirtd crashes due to the pool refresh thread clearing the list of pool volumes while someone is adding a new volume. Here is the valgrind log I have for that: http://paste.opensuse.org/58733866 I tried adding a call to virStoragePoolObjLock() in the virStorageVolPoolRefreshThread(), since the storageVolCreateXML() appears to have it, but I'm getting a dead lock. Here are the waiting threads I got from gdb: http://paste.opensuse.org/45961070 Any idea what would be a proper fix for that? My vision of the storage drivers locks is too limited it seems ;) -- Cedric

2 5

[libvirt] [PATCH 00/12] qemu: Add support for more migration parameters
by Jiri Denemark 02 Nov '17

02 Nov '17

QEMU is transforming existing special migration parameters (those which need dedicated QMP commands to be set or queried) into proper parameters handled by query-migrate-parameters and migrate-set-parameters. Even though we may still want to use the existing commands adding support for tha transformed parameters will help us clean all of them before migration and reset them to their original values after a failed migration. Thus we wouldn't need to add more ad-hoc code which resets some of them and ignores some others. Jiri Denemark (12): qemu: Generalize PARSE macro in qemuMonitorJSONGetMigrationParams qemu: Use macro for parsing string migration parameters qemu: Use macro for parsing ull migration parameters qemu: Generalize APPEND macro in qemuMonitorJSONSetMigrationParams qemu: Use macro for setting string migration parameters qemu: Drop giant if statement from qemuMonitorSetMigrationParams qemumonitorjsontest: Rename 1st CHECK macro in migration params test qemumonitorjsontest: Rename 2nd CHECK macro in migration params test qemu: Add support for setting downtime-limit migration parameter qemu: Rename TLS related migration parameters qemu: Add support for max-bandwidth migration parameter qemu: Add support for block-incremental migration parameter src/qemu/qemu_migration.c | 23 +++++----- src/qemu/qemu_monitor.c | 20 +++------ src/qemu/qemu_monitor.h | 10 ++++- src/qemu/qemu_monitor_json.c | 104 +++++++++++++++++++++++++++---------------- tests/qemumonitorjsontest.c | 46 ++++++++++++------- 5 files changed, 123 insertions(+), 80 deletions(-) -- 2.14.3

2 14

[libvirt] [PATCH] Post-release version bump to 3.10.0
by Jiri Denemark 02 Nov '17

02 Nov '17

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- Pushed. configure.ac | 2 +- docs/news.xml | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index ebe3318e0..b2d991c3b 100644 --- a/configure.ac +++ b/configure.ac @@ -16,7 +16,7 @@ dnl You should have received a copy of the GNU Lesser General Public dnl License along with this library. If not, see dnl <http://www.gnu.org/licenses/>. -AC_INIT([libvirt], [3.9.0], [libvir-list(a)redhat.com] [], [https://libvirt.org] +AC_INIT([libvirt], [3.10.0], [libvir-list(a)redhat.com] [], [https://libvirt.org] AC_CONFIG_SRCDIR([src/libvirt.c]) AC_CONFIG_AUX_DIR([build-aux]) AC_CONFIG_HEADERS([config.h]) diff --git a/docs/news.xml b/docs/news.xml index c24cc3f99..ef855d895 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -33,6 +33,14 @@ --> <libvirt> + <release version="v3.10.0" date="unreleased"> + <section title="New features"> + </section> + <section title="Improvements"> + </section> + <section title="Bug fixes"> + </section> + </release> <release version="v3.9.0" date="2017-11-02"> <section title="New features"> <change> -- 2.14.3

1 0

[libvirt] Release of libvirt-3.9.0
by Daniel Veillard 02 Nov '17

02 Nov '17

It's out ! I tagged it on git and pushed signed tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ I also made a 3.9.0 release of libvirt-python but it's virtually equivalent to 3.8.0 as no commit were made last month in that module. People are strongly encouraged to upgrade, as 3.9.0 includes a security fix, there is also a reasonable amount of user visible new features, improvement and bug fixes as usual: Security: - qemu: Ensure TLS clients always verify the server certificate While it's reasonable to turn off client certificate validation, as setting it up can be non-trivial, clients should always verify the server certificate to avoid MITM attacks. However, libvirt was using the same knob to control both checks, leading to CVE-2017-1000256 / LSN-2017-0002. New features: - Add capability to allow hot (un)plug of a domain watchdog device - Allow users to set device aliases Users can set aliases to domain devices and thus identify them easily. - qemu: Support multiqueue for virtio-blk Multiqueue support for virtio-blk has been available in QEMU ever since 2.7.0, and now libvirt guests can enable it. - Add virDomainSetLifecycleAction API Provided a new API to allow dynamic guest lifecycle control for guest reactions to poweroff, restart, or crash type events related to the domain XML on_poweroff, on_reboot, and on_crash elements. The virsh set-lifecycle-action command was created to control the actions. - qemu: Allow cold(un)plugging and hot(un)plugging input devices - net: Implement QoS for vhostuser Improvements: - Allow a logical volume to be create using LUKS A logical volume may be created using an encryption element using "luks" format. This does require a previously created secret to store the passphrase used to encrypt the volume Adding the volume to a domain can then either provide the secret or allow the consumer in the guest to provide the passphrase in order to decrypt the volume. - net: Ignore auto-generated MAC address when detaching an interface If the MAC address has not been specified by the user, libvirt will try and fill in the gaps by generating one; however, for some error paths that led to some confusing error messages, so when an auto-generated MAC address is specified the error message will not include the auto-generated MAC. - net: Enable MAC address lookup for virDomainInterfaceStats - apparmor: Several improvements Changes include permitting access to data about USB devices and dnsmasq instances, allowing spaces in guest names and many more. - cpu: Use CPU information obtained from QEMU when possible Recent QEMU versions can expose information about which CPU models are available and usable on the host; libvirt will now make use of such information whenever possible. - hyperv: Various improvements The error reported when clients can't connect to Hyper-V has been made more descriptive, and memory limits for guests are now mapped to more appropriate libvirt equivalents. - qemu: Report QEMU error on failed migration Instead of reporting a generic error, ask QEMU for a more detailed and thus hopefully more helpful one. - vbox: Implement autoport for RDP libvirt will now obtain the (dynamically allocated) RDP port number from VirtualBox itself, avoiding conflicts between multiple guests wanting to use RDP at the same time. - qemu: Allow rotation of small logs On a host where numerous unique instances are executed per day, it's quite possible that, even though each of the single log files are fairly small, collectively the quantity and volume may add tens of thousands of log files to the /var/log/libvirt/qemu/ directory. Removing the constraints that log have to be bigger than 100 KiB before they can be rotated solves the issue. Bug fixes: - Fix swapped interface statistics and QoS Due to internal implementation, reported statistics for some types of interfaces were swapped (RX appeared in TX and vice versa). Similarly, QoS was set in reversed way. - Properly resize local LUKS encrypted volume Resizing of a local LUKS encrypted volume will now use qemu-img to resize the volume. This will require configuring a secret for the LUKS encrypted volume. - qemu: Reserve PCI addresses for implicit i440fx devices Failing to do so causes the addresses to be considered usable by libvirt, which means they could be assigned to more than one device resulting in the guest failing to start. - spec: Restart libvirtd only at the end of the upgrade process Use %posttrans to make sure libvirtd is not restarted before all other components, such as the library itself and storage / hypervisor drivers, have already been upgraded. Thanks everybody for your help with this release, be it with patches, bug reports, ideas, reviews, docs, etc... Enjoy ! Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

Re: [libvirt] networking problem
by msliu＠reynoldstocks.com 02 Nov '17

02 Nov '17

Hi Daniel, # ls /usr/share/libvirt/ cpu_map.xml libvirtLogo.png schemas No "network" folder found # locate default.xml /etc/libvirt/storage/default.xml /etc/libvirt/storage/autostart/default.xml /home/satimis/.config/libvirt/storage/default.xml /home/satimis/.config/libvirt/storage/autostart/default.xml /usr/share/gutenprint/5.2/xml/escp2/inputslots/default.xml Besides # ls /etc/libvirt/qemu/networks/ autostart NAT.xml # ls /etc/libvirt/qemu/networks/autostart/ NAT.xml There are 2 NAT.xml file of same content # cat /etc/libvirt/qemu/networks/NAT.xml  <network> <name>NAT</name> <uuid>2b550fe1-cff0-476e-aabe-f8a239231315</uuid> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:a6:37:e4'/> <domain name='NAT'/> <ip address='192.168.100.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.100.128' end='192.168.100.254'/> </dhcp> </ip> </network> # cat /etc/libvirt/qemu/networks/autostart/NAT.xml  <network> <name>NAT</name> <uuid>2b550fe1-cff0-476e-aabe-f8a239231315</uuid> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:a6:37:e4'/> <domain name='NAT'/> <ip address='192.168.100.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.100.128' end='192.168.100.254'/> </dhcp> </ip> </network> Regards SL -------- Original Message -------- Subject: Re: [libvirt] networking problem From: "Daniel P. Berrange" <berrange(a)redhat.com> Date: Thu, November 02, 2017 9:31 am To: Stefan Hajnoczi <stefanha(a)gmail.com> Cc: msliu(a)reynoldstocks.com, libvir-list(a)redhat.com, kvm(a)vger.kernel.org On Thu, Nov 02, 2017 at 09:24:22AM +0000, Stefan Hajnoczi wrote: > On Sun, Oct 29, 2017 at 04:07:09AM -0700, msliu(a)reynoldstocks.com wrote: > > I have performed following steps: > > > > $ virsh net-destroy default > > $ virsh net-undefine default > > > > Now I couldn't start guest with following warning popup: > > Error starting domain: Network not found: no network with matching name > > 'default' > > > > Please advise how to re-create 'default' instead of reinstalling all > > guests. > > This is a libvirt question. I have CCed the libvirt mailing list so you > can continue discussion there. > > On Red Hat-based distros try reinstalling the > libvirt-daemon-config-network package. On Debian-based distros try > reinstalling the libvirt-daemon-system package. This should restore the > /etc/libvirt/qemu/networks/default.xml file that you are missing. No need to re-install those RPMs - Libvirt leaves a copy of the stock XML file at /usr/share/libvirt/networks/default.xml. So just run virsh define /usr/share/libvirt/networks/default.xml virsh start default 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 :|

1 0

[libvirt] [jenkins-ci PATCH 0/2] fix libosinfo rpm build
by Pavel Hrdina 02 Nov '17

02 Nov '17

Pavel Hrdina (2): jobs: rename check_env into job_env jobs: use job_env in all job templates jobs/autotools.yaml | 5 ++++- jobs/defaults.yaml | 2 +- jobs/perl-makemaker.yaml | 3 +++ projects/libosinfo.yaml | 2 +- projects/libvirt.yaml | 2 +- 5 files changed, 10 insertions(+), 4 deletions(-) -- 2.13.6

3 10

[libvirt] [PATCH v5 0/4] numa: describe sibling nodes distances
by Wim Ten Have 02 Nov '17

02 Nov '17

From: Wim ten Have <wim.ten.have(a)oracle.com> This patch extends guest domain administration adding support to advertise node sibling distances when configuring NUMA guests also referred to as vNUMA (Virtual NUMA). NUMA (Non-Uniform Memory Access), a method of configuring a cluster of nodes within a single multiprocessing system such that it shares processor local memory amongst others improving performance and the ability of the system to be expanded. A NUMA system could be illustrated as shown below. Within this 4-NODE system, every socket is equipped with its own distinct memory and some with I/O. Access to memory or I/O on remote nodes is only possible through the "Interconnect". This results in different performance for local and remote resources. In contrast to NUMA we recognize the flat SMP system where no concept of local or remote resource exists. The disadvantage of high socket count SMP systems is that the shared bus can easily become a performance bottleneck under high activity. +-------------+-------+ +-------+-------------+ |NODE0| | | | | |NODE3| | | CPU00 | CPU03 | | CPU12 | CPU15 | | | | | | | | | | | Mem +--- Socket0 ---<-------->--- Socket3 ---+ Mem | | | | | | | | | +-----+ CPU01 | CPU02 | | CPU13 | CPU14 | | | I/O | | | | | | | +-----+-------^-------+ +-------^-------+-----+ | | | Interconnect | | | +-------------v-------+ +-------v-------------+ |NODE1| | | | | |NODE2| | | CPU04 | CPU07 | | CPU08 | CPU11 | | | | | | | | | | | Mem +--- Socket1 ---<-------->--- Socket2 ---+ Mem | | | | | | | | | +-----+ CPU05 | CPU06 | | CPU09 | CPU10 | | | I/O | | | | | | | +-----+-------+-------+ +-------+-------+-----+ NUMA adds an intermediate level of memory shared amongst a few cores per socket as illustrated above, so that data accesses do not have to travel over a single bus. Unfortunately the way NUMA does this adds its own limitations. This, as visualized in the illustration above, happens when data is stored in memory associated with Socket2 and is accessed by a CPU (core) in Socket0. The processors use the "Interconnect" path to access resource on other nodes. These "Interconnect" hops add data access delays. It is therefore in our interest to describe the relative distances between nodes. The relative distances between nodes are described in the system's SLIT (System Locality Distance Information Table) which is part of the ACPI (Advanced Configuration and Power Interface) specification. On Linux systems the SLIT detail can be listed with help of the 'numactl -H' command. The above guest would show the following output. [root@f25 ~]# numactl -H available: 4 nodes (0-3) node 0 cpus: 0 1 2 3 node 0 size: 2007 MB node 0 free: 1931 MB node 1 cpus: 4 5 6 7 node 1 size: 1951 MB node 1 free: 1902 MB node 2 cpus: 8 9 10 11 node 2 size: 1998 MB node 2 free: 1910 MB node 3 cpus: 12 13 14 15 node 3 size: 2015 MB node 3 free: 1907 MB node distances: node 0 1 2 3 0: 10 21 31 21 1: 21 10 21 31 2: 31 21 10 21 3: 21 31 21 10 These patches extend core libvirt's XML description of NUMA cells to include NUMA distance information and propagate it to Xen guests via libxl. Recently qemu landed support for constructing the SLIT since commit 0f203430dd ("numa: Allow setting NUMA distance for different NUMA nodes"). The core libvirt extensions in this patch set could be used to propagate NUMA distances to qemu quests in the future. Wim ten Have (4): numa: describe siblings distances within cells xenconfig: add domxml conversions for xen-xl libxl: vnuma support xlconfigtest: add tests for numa cell sibling distances docs/formatdomain.html.in | 63 +++- docs/schemas/basictypes.rng | 7 + docs/schemas/cputypes.rng | 18 ++ src/conf/numa_conf.c | 359 ++++++++++++++++++++- src/conf/numa_conf.h | 20 ++ src/libvirt_private.syms | 5 + src/libxl/libxl_conf.c | 121 +++++++ src/libxl/libxl_driver.c | 3 +- src/xenconfig/xen_xl.c | 333 +++++++++++++++++++ .../test-fullvirt-vnuma-autocomplete.cfg | 26 ++ .../test-fullvirt-vnuma-autocomplete.xml | 85 +++++ .../test-fullvirt-vnuma-nodistances.cfg | 26 ++ .../test-fullvirt-vnuma-nodistances.xml | 53 +++ .../test-fullvirt-vnuma-partialdist.cfg | 26 ++ .../test-fullvirt-vnuma-partialdist.xml | 60 ++++ tests/xlconfigdata/test-fullvirt-vnuma.cfg | 26 ++ tests/xlconfigdata/test-fullvirt-vnuma.xml | 81 +++++ tests/xlconfigtest.c | 6 + 18 files changed, 1313 insertions(+), 5 deletions(-) create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-autocomplete.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-autocomplete.xml create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-nodistances.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-nodistances.xml create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-partialdist.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma-partialdist.xml create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-vnuma.xml -- 2.13.6

4 13

Re: [libvirt] networking problem
by msliu＠reynoldstocks.com 02 Nov '17

02 Nov '17

1 0

[libvirt] [PATCH] news: Update for 3.9.0 release
by Andrea Bolognani 02 Nov '17

02 Nov '17

Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- As usual, a lot of changes have made it to master without the release notes being updated at the same time. I'll push this tomorrow in the morning, so that it can make it into the release, unless it gets (N)ACKed earlier. docs/news.xml | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index 6a864916d..3cf761d89 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -49,6 +49,36 @@ easily. </description> </change> + <change> + <summary> + qemu: Support multiqueue for virtio-blk + </summary> + <description> + Multiqueue support for <code>virtio-blk</code> has been available + in QEMU ever since 2.7.0, and now libvirt guests can enable it. + </description> + </change> + <change> + <summary> + Add virDomainSetLifecycleAction() API + </summary> + <description> + This new API, also exposed through the + <code>set-lifecycle-action</code> <code>virsh</code> command, allows + the user to dynamically control how the guest will react to being + powered off, being restarted or crashing. + </description> + </change> + <change> + <summary> + qemu: Allow cold(un)plugging and hot(un)plugging input devices + </summary> + </change> + <change> + <summary> + net: Implement QoS for vhostuser + </summary> + </change> </section> <section title="Improvements"> <change> @@ -64,6 +94,82 @@ in order to decrypt the volume. </description> </change> + <change> + <summary> + net: Ignore auto-generated MAC address when detaching an interface + </summary> + <description> + If the MAC address has not been specified by the user, libvirt will + try and fill in the gaps by generating one; however, that leads to + very confusing error messages, so it's not desiderable. + </description> + </change> + <change> + <summary> + net: Enable MAC address lookup for virDomainInterfaceStats() + </summary> + </change> + <change> + <summary> + apparmor: Several improvements + </summary> + <description> + Changes include permitting access to data about USB devices and + <code>dnsmasq</code> instances, allowing spaces in guest names and + many more. + </description> + </change> + <change> + <summary> + cpu: Use CPU information obtained from QEMU when possible + </summary> + <description> + Recent QEMU versions can expose information about which CPU models + are available and usable on the host; libvirt will now make use of + such information whenever possible. + </description> + </change> + <change> + <summary> + hyperv: Various improvements + </summary> + <description> + The error reported when clients can't connect to Hyper-V has been + made more descriptive, and memory limits for guests are now mapped + to more appropriate libvirt equivalents. + </description> + </change> + <change> + <summary> + qemu: Report QEMU error on failed migration + </summary> + <description> + Instead of reporting a generic error, ask QEMU for a more detailed + and thus hopefully more helpful one. + </description> + </change> + <change> + <summary> + vbox: Implement autoport for RDP + </summary> + <description> + libvirt will now obtain the (dynamically allocated) RDP port number + from VirtualBox itself, avoiding conflicts between multiple guests + wanting to use RDP at the same time. + </description> + </change> + <change> + <summary> + qemu: Allow rotation of small logs + </summary> + <description> + On a host where tons of unique instances are executed per day, it's + quite possible that while each of the single log files are quite + small, they will build up to quite a bit of clutter. Removing the + constraints that log have to be bigger than 100 KiB before they can + be rotated solves the issue. + </description> + </change> </section> <section title="Bug fixes"> <change> @@ -87,6 +193,38 @@ the LUKS encrypted volume. </description> </change> + <change> + <summary> + qemu: Reserve PCI addresses for implicit i440fx devices + </summary> + <description> + Failing to do so causes the addresses to be considered usable by + libvirt, which means they could be assigned to more than one device + resulting in the guest failing to start. + </description> + </change> + <change> + <summary> + qemu: Ensure TLS clients always verify the server certificate + </summary> + <description> + While it's reasonable to turn off client certificate validation, + as setting it up can be non-trivial, clients should always verify + the server certificate to avoid MITM attacks. libvirt was, however, + using the same knob to control both checks, leading to + CVE-2017-1000256 / LSN-2017-0002. + </description> + </change> + <change> + <summary> + spec: Restart libvirtd only at the end of the upgrade process + </summary> + <description> + Use <code>%posttrans</code> to make sure <code>libvirtd</code> + is not restarted before all other components, such as the library + itself and storage / hypervisor drivers, have already been upgraded. + </description> + </change> </section> </release> <release version="v3.8.0" date="2017-10-04"> -- 2.13.6

2 3

[libvirt] [PATCH] cputest: Skip tests requiring JSON_MODELS if QEMU is disabled
by Jiri Denemark 02 Nov '17

02 Nov '17

Some tests require JSON_MODELS to be parsed into qemuCaps and applied when computing CPU models and such test cannot succeed if QEMU driver is disabled. Let's mark the tests with JSON_MODELS_REQUIRED and skip the appropriate parts if building without QEMU. On the other hand, CPU tests with JSON_MODELS should succeed even if model definitions from QEMU are not parsed and applied. Let's explicitly test this by repeating the tests without JSON_MODELS set. This fixes the build with QEMU driver disabled, e.g., on some architectures on RHEL/CentOS. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- tests/cputest.c | 70 ++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 49 insertions(+), 21 deletions(-) diff --git a/tests/cputest.c b/tests/cputest.c index 5d1fe7d99..8e94c2152 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -464,6 +464,7 @@ typedef enum { JSON_NONE, JSON_HOST, JSON_MODELS, + JSON_MODELS_REQUIRED, } cpuTestCPUIDJson; #if WITH_QEMU && WITH_YAJL @@ -491,7 +492,8 @@ cpuTestMakeQEMUCaps(const struct data *data) goto error; virQEMUCapsSet(qemuCaps, QEMU_CAPS_KVM); - if (data->flags == JSON_MODELS) + if (data->flags == JSON_MODELS || + data->flags == JSON_MODELS_REQUIRED) virQEMUCapsSet(qemuCaps, QEMU_CAPS_QUERY_CPU_DEFINITIONS); virQEMUCapsSetArch(qemuCaps, data->arch); @@ -517,32 +519,41 @@ cpuTestMakeQEMUCaps(const struct data *data) } -static virDomainCapsCPUModelsPtr -cpuTestGetCPUModels(const struct data *data) +static int +cpuTestGetCPUModels(const struct data *data, + virDomainCapsCPUModelsPtr *models) { - virDomainCapsCPUModelsPtr models = NULL; virQEMUCapsPtr qemuCaps; - if (data->flags != JSON_MODELS) - return NULL; + *models = NULL; + + if (data->flags != JSON_MODELS && + data->flags != JSON_MODELS_REQUIRED) + return 0; if (!(qemuCaps = cpuTestMakeQEMUCaps(data))) - return NULL; + return -1; - models = virQEMUCapsGetCPUDefinitions(qemuCaps, VIR_DOMAIN_VIRT_KVM); - virObjectRef(models); + *models = virQEMUCapsGetCPUDefinitions(qemuCaps, VIR_DOMAIN_VIRT_KVM); + virObjectRef(*models); virObjectUnref(qemuCaps); - return models; + return 0; } #else /* if WITH_QEMU && WITH_YAJL */ -static virDomainCapsCPUModelsPtr -cpuTestGetCPUModels(const struct data *data ATTRIBUTE_UNUSED) +static int +cpuTestGetCPUModels(const struct data *data, + virDomainCapsCPUModelsPtr *models) { - return NULL; + *models = NULL; + + if (data->flags == JSON_MODELS_REQUIRED) + return EXIT_AM_SKIP; + + return 0; } #endif @@ -580,8 +591,15 @@ cpuTestCPUID(bool guest, const void *arg) cpu->type = VIR_CPU_TYPE_HOST; } - if (guest) - models = cpuTestGetCPUModels(data); + if (guest) { + int rc; + + rc = cpuTestGetCPUModels(data, &models); + if (rc != 0) { + ret = rc; + goto cleanup; + } + } if (cpuDecode(cpu, hostData, models) < 0) goto cleanup; @@ -755,11 +773,17 @@ cpuTestUpdateLive(const void *arg) virDomainCapsCPUModelPtr hvModel; char **blockers = NULL; virDomainCapsCPUUsable usable = VIR_DOMCAPS_CPU_USABLE_UNKNOWN; + int rc; if (!(models = virDomainCapsCPUModelsNew(0))) goto cleanup; - hvModels = cpuTestGetCPUModels(data); + rc = cpuTestGetCPUModels(data, &hvModels); + if (rc != 0) { + ret = rc; + goto cleanup; + } + hvModel = virDomainCapsCPUModelsGet(hvModels, expected->model); if (hvModel) { @@ -969,15 +993,19 @@ mymain(void) host, cpu, models, 0, result) #if WITH_QEMU && WITH_YAJL -# define DO_TEST_CPUID_JSON(arch, host, json) \ +# define DO_TEST_JSON(arch, host, json) \ do { \ + if (json == JSON_MODELS) { \ + DO_TEST(arch, cpuTestGuestCPUID, host, host, \ + NULL, NULL, 0, 0); \ + } \ if (json != JSON_NONE) { \ DO_TEST(arch, cpuTestJSONCPUID, host, host, \ NULL, NULL, json, 0); \ } \ } while (0) #else -# define DO_TEST_CPUID_JSON(arch, host, json) +# define DO_TEST_JSON(arch, host, json) #endif #define DO_TEST_CPUID(arch, host, json) \ @@ -986,7 +1014,7 @@ mymain(void) NULL, NULL, 0, 0); \ DO_TEST(arch, cpuTestGuestCPUID, host, host, \ NULL, NULL, json, 0); \ - DO_TEST_CPUID_JSON(arch, host, json); \ + DO_TEST_JSON(arch, host, json); \ if (json != JSON_NONE) { \ DO_TEST(arch, cpuTestUpdateLive, host, host, \ NULL, NULL, json, 0); \ @@ -1126,7 +1154,7 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-4670T", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-6600", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600", JSON_HOST); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600-xsaveopt", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600-xsaveopt", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-3520M", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-3740QM", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-3770", JSON_HOST); @@ -1150,7 +1178,7 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E5-2630", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E5-2650", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E7-4820", JSON_HOST); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E7-4830", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E7-4830", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E7-8890", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6148", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-W3520", JSON_HOST); -- 2.14.3

2 2

Re: [libvirt] networking problem
by Stefan Hajnoczi 02 Nov '17

02 Nov '17

On Sun, Oct 29, 2017 at 04:07:09AM -0700, msliu(a)reynoldstocks.com wrote: > I have performed following steps: > > $ virsh net-destroy default > $ virsh net-undefine default > > Now I couldn't start guest with following warning popup: > Error starting domain: Network not found: no network with matching name > 'default' > > Please advise how to re-create 'default' instead of reinstalling all > guests. This is a libvirt question. I have CCed the libvirt mailing list so you can continue discussion there. On Red Hat-based distros try reinstalling the libvirt-daemon-config-network package. On Debian-based distros try reinstalling the libvirt-daemon-system package. This should restore the /etc/libvirt/qemu/networks/default.xml file that you are missing. Stefan

2 1

[libvirt] [PATCH v2 0/4] Predictable file names for memory-backend-file
by Michal Privoznik 02 Nov '17

02 Nov '17

v2 of: https://www.redhat.com/archives/libvir-list/2017-October/msg01063.html Patches are to be found here too: https://github.com/zippy2/libvirt/tree/qemu_mem_path_v3 diff to v1: -Dropped qemu.conf config knob -s/rmdir/virFileDeleteTree/ in qemuProcessBuildDestroyMemoryPathsImpl() because qemu leaves files behind and thus we need to unlink them too. Michal Privoznik (4): conf: s/virDomainObjGetShortName/virDomainDefGetShortName/ qemu: Move memPath generation from memoryBackingDir to a separate function qemu: Use predictable file names for memory-backend-file news: Document predictable file names for memory-backend-file docs/news.xml | 11 ++ src/conf/domain_conf.c | 4 +- src/conf/domain_conf.h | 2 +- src/libvirt_private.syms | 2 +- src/qemu/qemu_command.c | 9 +- src/qemu/qemu_conf.c | 71 ++++++++++- src/qemu/qemu_conf.h | 10 ++ src/qemu/qemu_domain.c | 4 +- src/qemu/qemu_driver.c | 19 ++- src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_process.c | 137 +++++++++++++++------ src/qemu/qemu_process.h | 8 +- .../qemuxml2argv-cpu-numa-memshared.args | 6 +- .../qemuxml2argv-fd-memory-numa-topology.args | 3 +- .../qemuxml2argv-fd-memory-numa-topology2.args | 6 +- .../qemuxml2argv-fd-memory-numa-topology3.args | 9 +- .../qemuxml2argv-hugepages-memaccess2.args | 9 +- 17 files changed, 244 insertions(+), 68 deletions(-) -- 2.13.6

2 11

[libvirt] [PATCH go-xml] Add support for CPUTune in Domain
by Michal Rostecki 01 Nov '17

01 Nov '17

From: Michal Rostecki <michal.rostecki(a)gmail.com> Signed-off-by: Victoria Efimova <neverpushthisbutton(a)yandex.ru> Signed-off-by: Ivan Shvedunov <ischvedunov(a)mirantis.com> Signed-off-by: Miha Pleško <miha.plesko(a)xlab.si> Signed-off-by: Michal Rostecki <michal.rostecki(a)gmail.com> --- domain.go | 19 +++++++++++++++++++ domain_test.go | 20 ++++++++++++++++++++ 2 files changed, 39 insertions(+) diff --git a/domain.go b/domain.go index bacab11..3efd68c 100644 --- a/domain.go +++ b/domain.go @@ -722,6 +722,24 @@ type DomainFeatureList struct { SMM *DomainFeatureState `xml:"smm"` } +type DomainCPUTuneShares struct { + Value uint `xml:",chardata"` +} + +type DomainCPUTunePeriod struct { + Value uint64 `xml:",chardata"` +} + +type DomainCPUTuneQuota struct { + Value int64 `xml:",chardata"` +} + +type DomainCPUTune struct { + Shares *DomainCPUTuneShares `xml:"shares"` + Period *DomainCPUTunePeriod `xml:"period"` + Quota *DomainCPUTuneQuota `xml:"quota"` +} + type DomainQEMUCommandlineArg struct { Value string `xml:"value,attr"` } @@ -751,6 +769,7 @@ type Domain struct { MemoryBacking *DomainMemoryBacking `xml:"memoryBacking"` VCPU *DomainVCPU `xml:"vcpu"` VCPUs *DomainVCPUs `xml:"vcpus"` + CPUTune *DomainCPUTune `xml:"cputune"` Resource *DomainResource `xml:"resource"` SysInfo *DomainSysInfo `xml:"sysinfo"` OS *DomainOS `xml:"os"` diff --git a/domain_test.go b/domain_test.go index dbebe42..b427b50 100644 --- a/domain_test.go +++ b/domain_test.go @@ -1335,6 +1335,26 @@ var domainTestData = []struct { `</domain>`, }, }, + { + Object: &Domain{ + Name: "test", + CPUTune: &DomainCPUTune{ + Shares: &DomainCPUTuneShares{Value: 1024}, + Period: &DomainCPUTunePeriod{Value: 500000}, + Quota: &DomainCPUTuneQuota{Value: -1}, + }, + }, + Expected: []string{ + `<domain>`, + ` <name>test</name>`, + ` <cputune>`, + ` <shares>1024</shares>`, + ` <period>500000</period>`, + ` <quota>-1</quota>`, + ` </cputune>`, + `</domain>`, + }, + }, /* Tests for sub-documents that can be hotplugged */ { -- 2.13.6

2 1

[libvirt] [PATCH go-xml] Add bootp option to NetworkDHCP
by Michal Rostecki 01 Nov '17

01 Nov '17

From: Michal Rostecki <michal.rostecki(a)gmail.com> Support specyfing concrete file and TFTP server for PXE boot. Signed-off-by: Michal Rostecki <michal.rostecki(a)gmail.com> --- network.go | 6 ++++++ network_test.go | 7 +++++++ 2 files changed, 13 insertions(+) diff --git a/network.go b/network.go index 32f125a..10c4dfc 100644 --- a/network.go +++ b/network.go @@ -78,9 +78,15 @@ type NetworkDHCPHost struct { IP string `xml:"ip,attr,omitempty"` } +type NetworkBootp struct { + File string `xml:"file,attr,omitempty"` + Server string `xml:"server,attr,omitempty"` +} + type NetworkDHCP struct { Ranges []NetworkDHCPRange `xml:"range"` Hosts []NetworkDHCPHost `xml:"host"` + Bootp []NetworkBootp `xml:"bootp"` } type NetworkIP struct { diff --git a/network_test.go b/network_test.go index b1bd168..3efb278 100644 --- a/network_test.go +++ b/network_test.go @@ -100,6 +100,12 @@ var networkTestData = []struct { IP: "192.168.122.10", }, }, + Bootp: []NetworkBootp{ + NetworkBootp{ + File: "pxelinux.0", + Server: "192.168.122.1", + }, + }, }, }, NetworkIP{ @@ -179,6 +185,7 @@ var networkTestData = []struct { ` <dhcp>`, ` <range start="192.168.122.2" end="192.168.122.254"></range>`, ` <host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10"></host>`, + ` <bootp file="pxelinux.0" server="192.168.122.1"></bootp>`, ` </dhcp>`, ` </ip>`, ` <ip address="2001:db8:ca2:2::1" family="ipv6" prefix="64">`, -- 2.13.6

2 1

[libvirt] [jenkins-ci PATCH] projects: disable libvirt-perl RPM build on centos-6
by Pavel Hrdina 01 Nov '17

01 Nov '17

There is no perl-CPAN-Changes package. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- Pushed under trivial rule. projects/libvirt-perl.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/projects/libvirt-perl.yaml b/projects/libvirt-perl.yaml index 77bc4ea..665befd 100644 --- a/projects/libvirt-perl.yaml +++ b/projects/libvirt-perl.yaml @@ -21,7 +21,6 @@ - perl-makemaker-rpm-job: parent_jobs: 'libvirt-perl-master-test' machines: - - libvirt-centos-6 - libvirt-centos-7 - libvirt-fedora-25 - libvirt-fedora-26 -- 2.13.6

1 0

[libvirt] [PATCH go-xml] Add address support for memory device
by zhenwei.pi 01 Nov '17

01 Nov '17

Add Base element for DomainAddress. Add address element for DomainMemorydev. Add test code for new DomainMemorydev. Signed-off-by: zhenwei.pi <zhenwei.pi(a)youruncloud.com> --- domain.go | 2 ++ domain_test.go | 9 +++++++++ 2 files changed, 11 insertions(+) diff --git a/domain.go b/domain.go index bacab11..3d9404f 100644 --- a/domain.go +++ b/domain.go @@ -297,6 +297,7 @@ type DomainAddress struct { Function *HexUint `xml:"function,attr"` Target *uint `xml:"target,attr"` Unit *uint `xml:"unit,attr"` + Base *HexUint `xml:"base,attr"` } type DomainConsole struct { @@ -450,6 +451,7 @@ type DomainMemorydev struct { Model string `xml:"model,attr"` Access string `xml:"access,attr"` Target *DomainMemorydevTarget `xml:"target"` + Address *DomainAddress `xml:"address"` } type DomainDeviceList struct { diff --git a/domain_test.go b/domain_test.go index dbebe42..cbc5d7f 100644 --- a/domain_test.go +++ b/domain_test.go @@ -66,6 +66,9 @@ var vcpuId0 uint = 0 var vcpuOrder0 uint = 1 var vcpuId1 uint = 1 +var memorydevAddressSlot HexUint = 0 +var memorydevAddressBase HexUint = 4294967296 + var domainTestData = []struct { Object Document Expected []string @@ -385,6 +388,11 @@ var domainTestData = []struct { Value: 0, }, }, + Address: &DomainAddress{ + Type: "dimm", + Slot: &memorydevAddressSlot, + Base: &memorydevAddressBase, + }, }, }, }, @@ -434,6 +442,7 @@ var domainTestData = []struct { ` <size unit="GiB">1</size>`, ` <node>0</node>`, ` </target>`, + ` <address type="dimm" slot="0" base="4294967296"></address>`, ` </memory>`, ` </devices>`, `</domain>`, -- 2.7.4

3 2

[libvirt] [jenkins-ci PATCH 0/7] several fixes
by Pavel Hrdina 01 Nov '17

01 Nov '17

Pavel Hrdina (7): projects: make sure that we use correct make for all projects projects: run RPM builds only on systems where it makes sense projects: build osinfo-db on debian-8 jobs: projects: be explicit about python2 binary guests: install unzip for virt-manager guests: install libgovirt-devel on all RPM based distros projects: disable libvirt-sandbox on centos-7 guests/vars/mappings.yml | 6 +++++- guests/vars/projects/virt-manager.yml | 1 + jobs/python-distutils.yaml | 8 ++++---- projects/libosinfo.yaml | 5 +++++ projects/libvirt-cim.yaml | 8 +++++--- projects/libvirt-glib.yaml | 5 +++++ projects/libvirt-perl.yaml | 6 ++++++ projects/libvirt-python.yaml | 6 ++++++ projects/libvirt-sandbox.yaml | 5 ++++- projects/libvirt-tck.yaml | 4 ++++ projects/osinfo-db-tools.yaml | 5 +++++ projects/osinfo-db.yaml | 16 ++++++++++++---- projects/virt-manager.yaml | 7 ++++++- projects/virt-viewer.yaml | 3 +++ 14 files changed, 71 insertions(+), 14 deletions(-) -- 2.13.6

3 13

[libvirt] [PATCH v2] spec: Restart libvirtd in posttrans
by Jiri Denemark 01 Nov '17

01 Nov '17

When upgrading libvirt packages, there's no strict ordering for the installation or removal of the individual libvirt sub packages. Thus libvirt-daemon may be upgraded (and its %postun scriptlet) started before all sub packages with driver libraries are upgraded. When libvirt-daemon's %postun scriptlet restarts the daemon old drivers may still be laying around and the daemon may crash when it tries to use them. Let's restart the daemon in %posttrans to make sure libvirtd is restarted only after all sub packages are at the same version. https://bugzilla.redhat.com/show_bug.cgi?id=1464300 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 37 ++++++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 0123d0655..b00689cab 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1516,6 +1516,10 @@ fi /sbin/chkconfig --add virtlockd %endif +# request daemon restart in posttrans +mkdir -p %{_localstatedir}/lib/rpm-state/libvirt || : +touch %{_localstatedir}/lib/rpm-state/libvirt/restart || : + %preun daemon %if %{with_systemd} %if %{with_systemd_macros} @@ -1554,13 +1558,11 @@ fi if [ $1 -ge 1 ] ; then /bin/systemctl reload-or-try-restart virtlockd.service >/dev/null 2>&1 || : /bin/systemctl reload-or-try-restart virtlogd.service >/dev/null 2>&1 || : - /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : fi %else if [ $1 -ge 1 ]; then /sbin/service virtlockd reload > /dev/null 2>&1 || : /sbin/service virtlogd reload > /dev/null 2>&1 || : - /sbin/service libvirtd condrestart > /dev/null 2>&1 fi %endif @@ -1570,7 +1572,6 @@ fi if [ "$1" -ge "1" ]; then /sbin/service virtlockd reload > /dev/null 2>&1 || : /sbin/service virtlogd reload > /dev/null 2>&1 || : - /sbin/service libvirtd condrestart > /dev/null 2>&1 fi %endif @@ -1593,6 +1594,16 @@ if [ $1 -ge 1 ] ; then %endif fi +%posttrans daemon +if [ -f %{_localstatedir}/lib/rpm-state/libvirt/restart ]; then +%if %{with_systemd} + /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : +%else + /sbin/service libvirtd condrestart > /dev/null 2>&1 || : +%endif +fi +rm -rf %{_localstatedir}/lib/rpm-state/libvirt || : + %post daemon-config-network if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; then # see if the network used by default network creates a conflict, @@ -1631,23 +1642,35 @@ if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml # Make sure libvirt picks up the new network defininiton + mkdir -p %{_localstatedir}/lib/rpm-state/libvirt || : + touch %{_localstatedir}/lib/rpm-state/libvirt/restart || : +fi + +%posttrans daemon-config-network +if [ -f %{_localstatedir}/lib/rpm-state/libvirt/restart ]; then %if %{with_systemd} - /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 ||: + /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : %else /sbin/service libvirtd condrestart > /dev/null 2>&1 || : %endif - fi - +rm -rf %{_localstatedir}/lib/rpm-state/libvirt || : %post daemon-config-nwfilter cp %{_datadir}/libvirt/nwfilter/*.xml %{_sysconfdir}/libvirt/nwfilter/ # Make sure libvirt picks up the new nwfilter defininitons +mkdir -p %{_localstatedir}/lib/rpm-state/libvirt || : +touch %{_localstatedir}/lib/rpm-state/libvirt/restart || : + +%posttrans daemon-config-nwfilter +if [ -f %{_localstatedir}/lib/rpm-state/libvirt/restart ]; then %if %{with_systemd} - /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 ||: + /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : %else /sbin/service libvirtd condrestart > /dev/null 2>&1 || : %endif +fi +rm -rf %{_localstatedir}/lib/rpm-state/libvirt || : %if %{with_systemd} -- 2.14.3

2 1

[libvirt] [PATCH RFC v2] lib: provide error message in new block job error event
by Nikolay Shirokovskiy 01 Nov '17

01 Nov '17

If block job is completed with error qemu additionally provides error message. This patch introduces new event VIR_DOMAIN_EVENT_ID_BLOCK_JOB_ERROR to pass error message to client. This error message has no semantics and should not be interpreted. API and RPC layer also have reserved 'code' field to pass semantics loaded error code value in the future. --- The patch is applied on top of [1] patch series (not yet pushed though). Diff from v1 [2]: 1. Replace block job event version 3 with block job error event. 2. Add code field to API/RPC to pass error code in the future. Peter, I decided not to use enum/union as this looks like to much effort to extend code generation for this simple case. Using typed params looks unsuitable too. [1] https://www.redhat.com/archives/libvir-list/2017-October/msg01292.html [2] https://www.redhat.com/archives/libvir-list/2017-October/msg01369.html daemon/remote.c | 48 +++++++++++++++++++ examples/object-events/event-test.c | 20 ++++++++ include/libvirt/libvirt-domain.h | 25 ++++++++++ src/conf/domain_event.c | 96 +++++++++++++++++++++++++++++++++++++ src/conf/domain_event.h | 13 +++++ src/libvirt_private.syms | 2 + src/qemu/qemu_blockjob.c | 9 +++- src/qemu/qemu_blockjob.h | 3 +- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 10 ++-- src/qemu/qemu_process.c | 12 +++-- src/remote/remote_driver.c | 34 +++++++++++++ src/remote/remote_protocol.x | 17 ++++++- src/remote_protocol-structs | 9 ++++ tools/virsh-domain.c | 24 ++++++++++ 15 files changed, 313 insertions(+), 10 deletions(-) diff --git a/daemon/remote.c b/daemon/remote.c index 3f7d2d3..545bf67 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -1342,6 +1342,53 @@ remoteRelayDomainEventBlockThreshold(virConnectPtr conn, } +static int +remoteRelayDomainEventBlockJobError(virConnectPtr conn, + virDomainPtr dom, + const char *dev, + int type, + unsigned int code, + const char *message, + void *opaque) +{ + daemonClientEventCallbackPtr callback = opaque; + remote_domain_event_block_job_error_msg msg; + + if (callback->callbackID < 0 || + !remoteRelayDomainEventCheckACL(callback->client, conn, dom)) + return -1; + + VIR_DEBUG("Relaying domain block job error event %s %d %s %i %u %s, callback %d", + dom->name, dom->id, dev, type, code, NULLSTR(message), + callback->callbackID); + + memset(&msg, 0, sizeof(msg)); + msg.callbackID = callback->callbackID; + if (VIR_STRDUP(msg.dev, dev) < 0) + return -1; + if (message) { + if (VIR_ALLOC(msg.message) < 0 || + VIR_STRDUP(*(msg.message), message) < 0) + goto error; + } + msg.type = type; + msg.code = code; + make_nonnull_domain(&msg.dom, dom); + + remoteDispatchObjectEventSend(callback->client, remoteProgram, + REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB_ERROR, + (xdrproc_t)xdr_remote_domain_event_block_job_error_msg, + &msg); + return 0; + + error: + VIR_FREE(msg.dev); + VIR_FREE(msg.message); + + return -1; +} + + static virConnectDomainEventGenericCallback domainEventCallbacks[] = { VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventLifecycle), VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventReboot), @@ -1368,6 +1415,7 @@ static virConnectDomainEventGenericCallback domainEventCallbacks[] = { VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventDeviceRemovalFailed), VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventMetadataChange), VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventBlockThreshold), + VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventBlockJobError), }; verify(ARRAY_CARDINALITY(domainEventCallbacks) == VIR_DOMAIN_EVENT_ID_LAST); diff --git a/examples/object-events/event-test.c b/examples/object-events/event-test.c index a144638..43a3878 100644 --- a/examples/object-events/event-test.c +++ b/examples/object-events/event-test.c @@ -936,6 +936,25 @@ myDomainEventBlockJobCallback(virConnectPtr conn ATTRIBUTE_UNUSED, static int +myDomainEventBlockJobErrorCallback(virConnectPtr conn ATTRIBUTE_UNUSED, + virDomainPtr dom, + const char *dev, + int type, + unsigned int code, + const char *message, + void *opaque) +{ + const char *eventName = opaque; + + printf("%s EVENT: Domain %s(%d) block job error callback '%s' disk '%s', " + "type '%s' code '%u' message '%s'", + __func__, virDomainGetName(dom), virDomainGetID(dom), eventName, + dev, blockJobTypeToStr(type), code, NULLSTR(message)); + return 0; +} + + +static int myDomainEventBlockThresholdCallback(virConnectPtr conn ATTRIBUTE_UNUSED, virDomainPtr dom, const char *dev, @@ -1082,6 +1101,7 @@ struct domainEventData domainEvents[] = { DOMAIN_EVENT(VIR_DOMAIN_EVENT_ID_DEVICE_REMOVAL_FAILED, myDomainEventDeviceRemovalFailedCallback), DOMAIN_EVENT(VIR_DOMAIN_EVENT_ID_METADATA_CHANGE, myDomainEventMetadataChangeCallback), DOMAIN_EVENT(VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD, myDomainEventBlockThresholdCallback), + DOMAIN_EVENT(VIR_DOMAIN_EVENT_ID_BLOCK_JOB_ERROR, myDomainEventBlockJobErrorCallback), }; struct storagePoolEventData { diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 4048acf..9f5c1ba 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -4363,6 +4363,30 @@ typedef void (*virConnectDomainEventBlockThresholdCallback)(virConnectPtr conn, unsigned long long excess, void *opaque); + +/** + * virConnectDomainEventBlockJobErrorCallback: + * @conn: connection object + * @dom: domain on which the event occurred + * @dev: name associated with the affected disk or storage backing chain + * element + * @type: type of block job (virDomainBlockJobType) + * @code: always 0, reserved for future use + * @message: error message with no semantics, can be NULL + * @opaque: application specified data + * + * The callback occurs when block job is completed with error and provides + * error message in @message. + * + */ +typedef void (*virConnectDomainEventBlockJobErrorCallback)(virConnectPtr conn, + virDomainPtr dom, + const char *dev, + int type, + unsigned int code, + const char *message, + void *opaque); + /** * VIR_DOMAIN_EVENT_CALLBACK: * @@ -4405,6 +4429,7 @@ typedef enum { VIR_DOMAIN_EVENT_ID_DEVICE_REMOVAL_FAILED = 22, /* virConnectDomainEventDeviceRemovalFailedCallback */ VIR_DOMAIN_EVENT_ID_METADATA_CHANGE = 23, /* virConnectDomainEventMetadataChangeCallback */ VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD = 24, /* virConnectDomainEventBlockThresholdCallback */ + VIR_DOMAIN_EVENT_ID_BLOCK_JOB_ERROR = 25, /* virConnectDomainEventBlockJobErrorCallback */ # ifdef VIR_ENUM_SENTINELS VIR_DOMAIN_EVENT_ID_LAST diff --git a/src/conf/domain_event.c b/src/conf/domain_event.c index 7baccd5..3a98de7 100644 --- a/src/conf/domain_event.c +++ b/src/conf/domain_event.c @@ -47,6 +47,7 @@ static virClassPtr virDomainEventWatchdogClass; static virClassPtr virDomainEventIOErrorClass; static virClassPtr virDomainEventGraphicsClass; static virClassPtr virDomainEventBlockJobClass; +static virClassPtr virDomainEventBlockJobErrorClass; static virClassPtr virDomainEventDiskChangeClass; static virClassPtr virDomainEventTrayChangeClass; static virClassPtr virDomainEventBalloonChangeClass; @@ -69,6 +70,7 @@ static void virDomainEventWatchdogDispose(void *obj); static void virDomainEventIOErrorDispose(void *obj); static void virDomainEventGraphicsDispose(void *obj); static void virDomainEventBlockJobDispose(void *obj); +static void virDomainEventBlockJobErrorDispose(void *obj); static void virDomainEventDiskChangeDispose(void *obj); static void virDomainEventTrayChangeDispose(void *obj); static void virDomainEventBalloonChangeDispose(void *obj); @@ -151,6 +153,17 @@ struct _virDomainEventBlockJob { typedef struct _virDomainEventBlockJob virDomainEventBlockJob; typedef virDomainEventBlockJob *virDomainEventBlockJobPtr; +struct _virDomainEventBlockJobError { + virDomainEvent parent; + + char *dev; + int type; + unsigned int code; + char *message; +}; +typedef struct _virDomainEventBlockJobError virDomainEventBlockJobError; +typedef virDomainEventBlockJobError *virDomainEventBlockJobErrorPtr; + struct _virDomainEventGraphics { virDomainEvent parent; @@ -337,6 +350,12 @@ virDomainEventsOnceInit(void) sizeof(virDomainEventBlockJob), virDomainEventBlockJobDispose))) return -1; + if (!(virDomainEventBlockJobErrorClass = + virClassNew(virDomainEventClass, + "virDomainEventBlockJobError", + sizeof(virDomainEventBlockJobError), + virDomainEventBlockJobErrorDispose))) + return -1; if (!(virDomainEventDiskChangeClass = virClassNew(virDomainEventClass, "virDomainEventDiskChange", @@ -504,6 +523,16 @@ virDomainEventBlockJobDispose(void *obj) } static void +virDomainEventBlockJobErrorDispose(void *obj) +{ + virDomainEventBlockJobErrorPtr event = obj; + VIR_DEBUG("obj=%p", event); + + VIR_FREE(event->dev); + VIR_FREE(event->message); +} + +static void virDomainEventDiskChangeDispose(void *obj) { virDomainEventDiskChangePtr event = obj; @@ -1061,6 +1090,59 @@ virDomainEventBlockJob2NewFromDom(virDomainPtr dom, dst, type, status); } +static virObjectEventPtr +virDomainEventBlockJobErrorNew(int id, + const char *name, + unsigned char *uuid, + const char *dev, + int type, + unsigned int code, + const char *message) +{ + virDomainEventBlockJobErrorPtr ev; + + if (virDomainEventsInitialize() < 0) + return NULL; + + if (!(ev = virDomainEventNew(virDomainEventBlockJobErrorClass, + VIR_DOMAIN_EVENT_ID_BLOCK_JOB_ERROR, + id, name, uuid))) + return NULL; + + if (VIR_STRDUP(ev->dev, dev) < 0) { + virObjectUnref(ev); + return NULL; + } + ignore_value(VIR_STRDUP_QUIET(ev->message, message)); + ev->type = type; + ev->code = code; + + return (virObjectEventPtr)ev; +} + +virObjectEventPtr +virDomainEventBlockJobErrorNewFromObj(virDomainObjPtr obj, + const char *dev, + int type, + unsigned int code, + const char *message) +{ + return virDomainEventBlockJobErrorNew(obj->def->id, obj->def->name, + obj->def->uuid, dev, type, code, + message); +} + +virObjectEventPtr +virDomainEventBlockJobErrorNewFromDom(virDomainPtr dom, + const char *dev, + int type, + unsigned int code, + const char *message) +{ + return virDomainEventBlockJobErrorNew(dom->id, dom->name, dom->uuid, + dev, type, code, message); +} + virObjectEventPtr virDomainEventControlErrorNewFromDom(virDomainPtr dom) { @@ -1871,6 +1953,20 @@ virDomainEventDispatchDefaultFunc(virConnectPtr conn, goto cleanup; } + case VIR_DOMAIN_EVENT_ID_BLOCK_JOB_ERROR: + { + virDomainEventBlockJobErrorPtr blockJobErrorEvent; + + blockJobErrorEvent = (virDomainEventBlockJobErrorPtr)event; + ((virConnectDomainEventBlockJobErrorCallback)cb)(conn, dom, + blockJobErrorEvent->dev, + blockJobErrorEvent->type, + blockJobErrorEvent->code, + blockJobErrorEvent->message, + cbopaque); + goto cleanup; + } + case VIR_DOMAIN_EVENT_ID_DISK_CHANGE: { virDomainEventDiskChangePtr diskChangeEvent; diff --git a/src/conf/domain_event.h b/src/conf/domain_event.h index 3992a29..456026c 100644 --- a/src/conf/domain_event.h +++ b/src/conf/domain_event.h @@ -138,6 +138,19 @@ virDomainEventBlockJob2NewFromDom(virDomainPtr dom, int status); virObjectEventPtr +virDomainEventBlockJobErrorNewFromObj(virDomainObjPtr obj, + const char *dev, + int type, + unsigned int code, + const char *message); +virObjectEventPtr +virDomainEventBlockJobErrorNewFromDom(virDomainPtr dom, + const char *dev, + int type, + unsigned int code, + const char *message); + +virObjectEventPtr virDomainEventDiskChangeNewFromObj(virDomainObjPtr obj, const char *oldSrcPath, const char *newSrcPath, diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 448d962..594c792 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -562,6 +562,8 @@ virDomainEventBalloonChangeNewFromDom; virDomainEventBalloonChangeNewFromObj; virDomainEventBlockJob2NewFromDom; virDomainEventBlockJob2NewFromObj; +virDomainEventBlockJobErrorNewFromDom; +virDomainEventBlockJobErrorNewFromObj; virDomainEventBlockJobNewFromDom; virDomainEventBlockJobNewFromObj; virDomainEventBlockThresholdNewFromDom; diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c index 0b1616a..7edc30a 100644 --- a/src/qemu/qemu_blockjob.c +++ b/src/qemu/qemu_blockjob.c @@ -70,7 +70,8 @@ qemuBlockJobUpdate(virQEMUDriverPtr driver, if (status != -1) { qemuBlockJobEventProcess(driver, vm, disk, asyncJob, diskPriv->blockJobType, - diskPriv->blockJobStatus); + diskPriv->blockJobStatus, + diskPriv->blockJobError); diskPriv->blockJobStatus = -1; if (error) VIR_STEAL_PTR(*error, diskPriv->blockJobError); @@ -100,10 +101,12 @@ qemuBlockJobEventProcess(virQEMUDriverPtr driver, virDomainDiskDefPtr disk, qemuDomainAsyncJob asyncJob, int type, - int status) + int status, + const char *error) { virObjectEventPtr event = NULL; virObjectEventPtr event2 = NULL; + virObjectEventPtr event3 = NULL; const char *path; virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); virDomainDiskDefPtr persistDisk = NULL; @@ -123,6 +126,7 @@ qemuBlockJobEventProcess(virQEMUDriverPtr driver, path = virDomainDiskGetSource(disk); event = virDomainEventBlockJobNewFromObj(vm, path, type, status); event2 = virDomainEventBlockJob2NewFromObj(vm, disk->dst, type, status); + event3 = virDomainEventBlockJobErrorNewFromObj(vm, disk->dst, type, 0, error); /* If we completed a block pull or commit, then update the XML * to match. */ @@ -212,6 +216,7 @@ qemuBlockJobEventProcess(virQEMUDriverPtr driver, qemuDomainEventQueue(driver, event); qemuDomainEventQueue(driver, event2); + qemuDomainEventQueue(driver, event3); virObjectUnref(cfg); } diff --git a/src/qemu/qemu_blockjob.h b/src/qemu/qemu_blockjob.h index e71d691..18bcaaa 100644 --- a/src/qemu/qemu_blockjob.h +++ b/src/qemu/qemu_blockjob.h @@ -36,7 +36,8 @@ void qemuBlockJobEventProcess(virQEMUDriverPtr driver, virDomainDiskDefPtr disk, qemuDomainAsyncJob asyncJob, int type, - int status); + int status, + const char *error); void qemuBlockJobSyncBegin(virDomainDiskDefPtr disk); void qemuBlockJobSyncEnd(virQEMUDriverPtr driver, diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 735e810..99a71b3 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -457,6 +457,7 @@ struct qemuProcessEvent { int action; int status; void *data; + char *error; }; typedef struct _qemuDomainLogContext qemuDomainLogContext; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 725b46a..c6626bb 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -4715,7 +4715,8 @@ processBlockJobEvent(virQEMUDriverPtr driver, virDomainObjPtr vm, char *diskAlias, int type, - int status) + int status, + char *error) { virDomainDiskDefPtr disk; @@ -4728,12 +4729,14 @@ processBlockJobEvent(virQEMUDriverPtr driver, } if ((disk = qemuProcessFindDomainDiskByAlias(vm, diskAlias))) - qemuBlockJobEventProcess(driver, vm, disk, QEMU_ASYNC_JOB_NONE, type, status); + qemuBlockJobEventProcess(driver, vm, disk, QEMU_ASYNC_JOB_NONE, + type, status, error); endjob: qemuDomainObjEndJob(driver, vm); cleanup: VIR_FREE(diskAlias); + VIR_FREE(error); } @@ -4815,7 +4818,8 @@ static void qemuProcessEventHandler(void *data, void *opaque) processBlockJobEvent(driver, vm, processEvent->data, processEvent->action, - processEvent->status); + processEvent->status, + processEvent->error); break; case QEMU_PROCESS_EVENT_MONITOR_EOF: processMonitorEOFEvent(driver, vm); diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 4bfad5d..6a3d9bc 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -1008,6 +1008,7 @@ qemuProcessHandleBlockJob(qemuMonitorPtr mon ATTRIBUTE_UNUSED, virDomainDiskDefPtr disk; qemuDomainDiskPrivatePtr diskPriv; char *data = NULL; + char *errorCopy = NULL; virObjectLock(vm); @@ -1018,13 +1019,14 @@ qemuProcessHandleBlockJob(qemuMonitorPtr mon ATTRIBUTE_UNUSED, goto error; diskPriv = QEMU_DOMAIN_DISK_PRIVATE(disk); + ignore_value(VIR_STRDUP_QUIET(errorCopy, error)); + if (diskPriv->blockJobSync) { /* We have a SYNC API waiting for this event, dispatch it back */ diskPriv->blockJobType = type; diskPriv->blockJobStatus = status; VIR_FREE(diskPriv->blockJobError); - if (error && VIR_STRDUP_QUIET(diskPriv->blockJobError, error) < 0) - VIR_WARN("Can not pass error message further: %s", error); + VIR_STEAL_PTR(diskPriv->blockJobError, errorCopy); virDomainObjBroadcast(vm); } else { /* there is no waiting SYNC API, dispatch the update to a thread */ @@ -1038,6 +1040,7 @@ qemuProcessHandleBlockJob(qemuMonitorPtr mon ATTRIBUTE_UNUSED, processEvent->vm = vm; processEvent->action = type; processEvent->status = status; + VIR_STEAL_PTR(processEvent->error, errorCopy); virObjectRef(vm); if (virThreadPoolSendJob(driver->workerPool, 0, processEvent) < 0) { @@ -1047,11 +1050,14 @@ qemuProcessHandleBlockJob(qemuMonitorPtr mon ATTRIBUTE_UNUSED, } cleanup: + VIR_FREE(errorCopy); virObjectUnlock(vm); return 0; error: - if (processEvent) + if (processEvent) { VIR_FREE(processEvent->data); + VIR_FREE(processEvent->error); + } VIR_FREE(processEvent); goto cleanup; } diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 06719bb..69d93aa 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -405,6 +405,11 @@ remoteConnectNotifyEventConnectionClosed(virNetClientProgramPtr prog ATTRIBUTE_U virNetClientPtr client ATTRIBUTE_UNUSED, void *evdata, void *opaque); +static void +remoteDomainBuildEventBlockJobError(virNetClientProgramPtr prog, + virNetClientPtr client, + void *evdata, void *opaque); + static virNetClientProgramEvent remoteEvents[] = { { REMOTE_PROC_DOMAIN_EVENT_LIFECYCLE, remoteDomainBuildEventLifecycle, @@ -611,6 +616,10 @@ static virNetClientProgramEvent remoteEvents[] = { remoteDomainBuildEventBlockThreshold, sizeof(remote_domain_event_block_threshold_msg), (xdrproc_t)xdr_remote_domain_event_block_threshold_msg }, + { REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB_ERROR, + remoteDomainBuildEventBlockJobError, + sizeof(remote_domain_event_block_job_error_msg), + (xdrproc_t)xdr_remote_domain_event_block_job_error_msg }, }; static void @@ -5610,6 +5619,31 @@ remoteDomainBuildEventBlockThreshold(virNetClientProgramPtr prog ATTRIBUTE_UNUSE } +static void +remoteDomainBuildEventBlockJobError(virNetClientProgramPtr prog ATTRIBUTE_UNUSED, + virNetClientPtr client ATTRIBUTE_UNUSED, + void *evdata, void *opaque) +{ + virConnectPtr conn = opaque; + remote_domain_event_block_job_error_msg *msg = evdata; + struct private_data *priv = conn->privateData; + virDomainPtr dom; + virObjectEventPtr event = NULL; + + dom = get_nonnull_domain(conn, msg->dom); + if (!dom) + return; + + event = virDomainEventBlockJobErrorNewFromDom(dom, msg->dev, msg->type, + msg->code, + msg->message ? *msg->message : NULL); + + virObjectUnref(dom); + + remoteEventQueue(priv, event, msg->callbackID); +} + + static int remoteStreamSend(virStreamPtr st, const char *data, diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x index 0aed252..3aba4a3 100644 --- a/src/remote/remote_protocol.x +++ b/src/remote/remote_protocol.x @@ -3095,6 +3095,15 @@ struct remote_domain_event_block_job_2_msg { int status; }; +struct remote_domain_event_block_job_error_msg { + int callbackID; + remote_nonnull_domain dom; + remote_nonnull_string dev; + int type; + int code; + remote_string message; +}; + struct remote_domain_event_block_threshold_msg { int callbackID; remote_nonnull_domain dom; @@ -6120,5 +6129,11 @@ enum remote_procedure { * @generate: both * @acl: domain:write */ - REMOTE_PROC_DOMAIN_SET_LIFECYCLE_ACTION = 390 + REMOTE_PROC_DOMAIN_SET_LIFECYCLE_ACTION = 390, + + /** + * @generate: none + * @acl: none + */ + REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB_ERROR = 391 }; diff --git a/src/remote_protocol-structs b/src/remote_protocol-structs index 59b0ace..29dcfc1 100644 --- a/src/remote_protocol-structs +++ b/src/remote_protocol-structs @@ -2535,6 +2535,14 @@ struct remote_domain_event_block_job_2_msg { int type; int status; }; +struct remote_domain_event_block_job_error_msg { + int callbackID; + remote_nonnull_domain dom; + remote_nonnull_string dev; + int type; + int code; + remote_string message; +}; struct remote_domain_event_block_threshold_msg { int callbackID; remote_nonnull_domain dom; @@ -3262,4 +3270,5 @@ enum remote_procedure { REMOTE_PROC_DOMAIN_MANAGED_SAVE_GET_XML_DESC = 388, REMOTE_PROC_DOMAIN_MANAGED_SAVE_DEFINE_XML = 389, REMOTE_PROC_DOMAIN_SET_LIFECYCLE_ACTION = 390, + REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB_3 = 391, }; diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 1e33e82..7fec0b3 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -13253,6 +13253,28 @@ virshEventBlockThresholdPrint(virConnectPtr conn ATTRIBUTE_UNUSED, } +static void +virshEventBlockJobErrorPrint(virConnectPtr conn ATTRIBUTE_UNUSED, + virDomainPtr dom, + const char *dev, + int type, + unsigned int code ATTRIBUTE_UNUSED, + const char *message, + void *opaque) +{ + virBuffer buf = VIR_BUFFER_INITIALIZER; + + virBufferAsprintf(&buf, _("event '%s' for domain %s: %s for %s, " + "error: %s\n"), + ((virshDomEventData *) opaque)->cb->name, + virDomainGetName(dom), + virshDomainBlockJobToString(type), + dev, + NULLSTR(message)); + virshEventPrint(opaque, &buf); +} + + static vshEventCallback vshEventCallbacks[] = { { "lifecycle", VIR_DOMAIN_EVENT_CALLBACK(virshEventLifecyclePrint), }, @@ -13302,6 +13324,8 @@ static vshEventCallback vshEventCallbacks[] = { VIR_DOMAIN_EVENT_CALLBACK(virshEventMetadataChangePrint), }, { "block-threshold", VIR_DOMAIN_EVENT_CALLBACK(virshEventBlockThresholdPrint), }, + { "block-job-error", + VIR_DOMAIN_EVENT_CALLBACK(virshEventBlockJobErrorPrint), }, }; verify(VIR_DOMAIN_EVENT_ID_LAST == ARRAY_CARDINALITY(vshEventCallbacks)); -- 1.8.3.1

1 0

[libvirt] Entering freeze for next release
by Daniel Veillard 01 Nov '17

01 Nov '17

The Candidate Release 1 is tagged in git, I also pushed signed tarball and rpms to the usual place : ftp://libvirt.org/libvirt/ I'm travelling so not really in a position to do much testing, but https://ci.centos.org/view/libvirt/ is all green (yay!) so that sounds rather good ATM :-) I will try to push RC2 on Tuesday evening or Wed morning, with a final release on Tuesday 2nd, in the meantime please give it a try, as usual testing on various arches and OSes is very useful ! Thanks, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

2 3

[libvirt] [PATCH dbus v2] Run system instance as an unprivileged user account
by Daniel P. Berrange 31 Oct '17

31 Oct '17

There is no reason for the libvirt-dbus daemon to require root privileges. All it actually needs is ability to connect to libvirtd, which can be achieved by dropping in a polkit configuration file Now a libvirt connection to the system bus gives you privileges equivalent to root, so this doesn't really improve security on its own. It relies on there being a dbus policy that prevents users from issuing elevated APIs. For example, a DBus policy could allow non-root users to list VMs on the system bus and get their status (aka virsh list equiv). In this case, the security isolation does give some benefit. Security can be further improved if the admin uses the libvirt polkit file to restrict what libvirt-dbus is permitted to do. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- configure.ac | 5 ++++ data/Makefile.am | 33 ++++++++++++++++++---- data/system/libvirt-dbus.rules.in | 8 ++++++ .../{org.libvirt.conf => org.libvirt.conf.in} | 5 +++- data/system/org.libvirt.service.in | 2 +- libvirt-dbus.spec.in | 9 ++++++ src/main.c | 8 ++++++ 7 files changed, 62 insertions(+), 8 deletions(-) create mode 100644 data/system/libvirt-dbus.rules.in rename data/system/{org.libvirt.conf => org.libvirt.conf.in} (87%) diff --git a/configure.ac b/configure.ac index 228ea11..aef3d37 100644 --- a/configure.ac +++ b/configure.ac @@ -70,6 +70,11 @@ else fi AC_SUBST(DBUS_SYSTEM_POLICIES_DIR) +LIBVIRT_ARG_WITH([SYSTEM_USER], [username to run system instance as], + ['libvirtdbus']) +SYSTEM_USER=$with_system_user +AC_SUBST([SYSTEM_USER]) + AC_OUTPUT(Makefile data/Makefile src/Makefile diff --git a/data/Makefile.am b/data/Makefile.am index 58e855f..3f27b02 100644 --- a/data/Makefile.am +++ b/data/Makefile.am @@ -9,18 +9,28 @@ system_servicedir = $(DBUS_SYSTEM_SERVICES_DIR) system_service_DATA = $(system_service_in_files:.service.in=.service) system_policy_files = \ - system/org.libvirt.conf + system/org.libvirt.conf.in system_policydir = $(DBUS_SYSTEM_POLICIES_DIR) -system_policy_DATA = $(system_policy_files) +system_policy_DATA = $(system_policy_files:.conf.in=.conf) + +polkit_files = \ + system/libvirt-dbus.rules.in +polkit_policydir = $(sysconfdir)/polkit-1/rules.d +polkit_policy_DATA = $(polkit_files:.rules.in=.rules) EXTRA_DIST = \ $(service_in_files) \ $(system_service_in_files) \ - $(system_policy_files) + $(system_policy_files) \ + $(polkit_files) \ + $(NULL) CLEANFILES = \ $(service_DATA) \ - $(system_service_DATA) + $(system_service_DATA) \ + $(system_policy_DATA) \ + $(polkit_DATA) \ + $(NULL) session/org.libvirt.service: session/org.libvirt.service.in $(AM_V_GEN)$(MKDIR_P) session && \ @@ -29,5 +39,16 @@ session/org.libvirt.service: session/org.libvirt.service.in system/org.libvirt.service: system/org.libvirt.service.in $(AM_V_GEN)$(MKDIR_P) system && \ - sed -e 's|[@]bindir[@]|$(bindir)|g' < $< > $@-t && \ - mv $@-t $@ + sed -e 's|[@]bindir[@]|$(bindir)|g' \ + -e 's|[@]SYSTEM_USER[@]|$(SYSTEM_USER)|' \ + < $< > $@-t && mv $@-t $@ + +system/org.libvirt.conf: system/org.libvirt.conf.in + $(AM_V_GEN)$(MKDIR_P) system && \ + sed -e 's|[@]SYSTEM_USER[@]|$(SYSTEM_USER)|' \ + < $< > $@-t && mv $@-t $@ + +system/libvirt-dbus.rules: system/libvirt-dbus.rules.in + $(AM_V_GEN)$(MKDIR_P) system && \ + sed -e 's|[@]SYSTEM_USER[@]|$(SYSTEM_USER)|' \ + < $< > $@-t && mv $@-t $@ diff --git a/data/system/libvirt-dbus.rules.in b/data/system/libvirt-dbus.rules.in new file mode 100644 index 0000000..4eb4ee1 --- /dev/null +++ b/data/system/libvirt-dbus.rules.in @@ -0,0 +1,8 @@ +// Allow libvirt-dbus running in dedicated account to use libvirt + +polkit.addRule(function(action, subject) { + if (action.id == "org.libvirt.unix.manage" && + subject.user == "@SYSTEM_USER@") { + return polkit.Result.YES; + } +}); diff --git a/data/system/org.libvirt.conf b/data/system/org.libvirt.conf.in similarity index 87% rename from data/system/org.libvirt.conf rename to data/system/org.libvirt.conf.in index 5cbc732..fe61b70 100644 --- a/data/system/org.libvirt.conf +++ b/data/system/org.libvirt.conf.in @@ -4,8 +4,11 @@ <busconfig> - <policy user="root"> + <policy user="@SYSTEM_USER@"> <allow own="org.libvirt"/> + </policy> + + <policy user="root"> <allow send_destination="org.libvirt"/> </policy> diff --git a/data/system/org.libvirt.service.in b/data/system/org.libvirt.service.in index 08d32a2..0d3abdd 100644 --- a/data/system/org.libvirt.service.in +++ b/data/system/org.libvirt.service.in @@ -1,4 +1,4 @@ [D-BUS Service] Name=org.libvirt Exec=@bindir@/libvirt-dbus --system -User=root +User=@SYSTEM_USER@ diff --git a/libvirt-dbus.spec.in b/libvirt-dbus.spec.in index 5be4c22..572300f 100644 --- a/libvirt-dbus.spec.in +++ b/libvirt-dbus.spec.in @@ -19,6 +19,7 @@ BuildRequires: systemd-devel >= %{systemd_version} Requires: libvirt-libs >= %{libvirt_version} Requires: systemd-libs >= %{systemd_version} +Requires(pre): shadow-utils %description This package provides integration between libvirt and the DBus @@ -37,9 +38,17 @@ rm -rf $RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT +%pre +getent group libvirtdbus >/dev/null || groupadd -r libvirtdbus +getent passwd libvirtdbus >/dev/null || \ + useradd -r -g libvirtdbus -d / -s /sbin/nologin \ + -c "Libvirt DBus bridge" libvirtdbus +exit 0 + %files %defattr(-,root,root,-) %doc README COPYING AUTHORS NEWS +%{_sysconfdir}/polkit-1/rules.d/libvirt-dbus.rules %{_bindir}/libvirt-dbus %{_datadir}/dbus-1/services/org.libvirt.service %{_datadir}/dbus-1/system-services/org.libvirt.service diff --git a/src/main.c b/src/main.c index a6a0212..225fb46 100644 --- a/src/main.c +++ b/src/main.c @@ -143,6 +143,14 @@ main(int argc, char *argv[]) } } + if (uri == NULL) { + if (system_bus) { + uri = "qemu:///system"; + } else { + uri = "qemu:///session"; + } + } + sigemptyset(&mask); sigaddset(&mask, SIGTERM); sigaddset(&mask, SIGINT); -- 2.13.6

2 1