[libvirt] [PATCH v3 1/2] systemd: fix build without dbus
by Daniel P. Berrange
The virDBusMethodCall method has a DBusError as one of its
parameters. If the caller wants to pass a non-NULL value
for this, it immediately makes the calling code require
DBus at build time. This has led to breakage of non-DBus
builds several times. It is desirable that only the virdbus.c
file should need WITH_DBUS conditionals, so we must ideally
remove the DBusError parameter from the method.
We can't simply raise a libvirt error, since the whole point
of this parameter is to give the callers a way to check if
the error is one they want to ignore, without having the logs
polluted with an error message. So, we add a virErrorPtr
parameter which the caller can then either ignore or raise
using the new virReportErrorObject method.
This new method is distinct from virSetError in that it
ensures the logging hooks are run.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
po/POTFILES.in | 1 -
src/libvirt_private.syms | 1 +
src/util/virdbus.c | 31 ++++++++------
src/util/virdbus.h | 4 +-
src/util/virerror.c | 104 +++++++++++++++++++++++++++++++++++++----------
src/util/virerror.h | 8 ++++
src/util/virfirewall.c | 29 +++----------
src/util/virsystemd.c | 15 ++++---
8 files changed, 125 insertions(+), 68 deletions(-)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 26c098f..3064037 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -217,7 +217,6 @@ src/util/virstorageencryption.c
src/util/virstoragefile.c
src/util/virstring.c
src/util/virsysinfo.c
-src/util/virsystemd.c
src/util/virerror.c
src/util/virerror.h
src/util/virtime.c
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index a2eec83..528e93c 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -1284,6 +1284,7 @@ virErrorInitialize;
virErrorSetErrnoFromLastError;
virLastErrorIsSystemErrno;
virRaiseErrorFull;
+virRaiseErrorObject;
virReportErrorHelper;
virReportOOMErrorFull;
virReportSystemErrorFull;
diff --git a/src/util/virdbus.c b/src/util/virdbus.c
index d9665c1..3522ae0 100644
--- a/src/util/virdbus.c
+++ b/src/util/virdbus.c
@@ -1522,7 +1522,7 @@ static int
virDBusCall(DBusConnection *conn,
DBusMessage *call,
DBusMessage **replyout,
- DBusError *error)
+ virErrorPtr error)
{
DBusMessage *reply = NULL;
@@ -1530,8 +1530,9 @@ virDBusCall(DBusConnection *conn,
int ret = -1;
const char *iface, *member, *path, *dest;
- if (!error)
- dbus_error_init(&localerror);
+ dbus_error_init(&localerror);
+ if (error)
+ memset(error, 0, sizeof(*error));
iface = dbus_message_get_interface(call);
member = dbus_message_get_member(call);
@@ -1545,13 +1546,20 @@ virDBusCall(DBusConnection *conn,
if (!(reply = dbus_connection_send_with_reply_and_block(conn,
call,
VIR_DBUS_METHOD_CALL_TIMEOUT_MILLIS,
- error ? error : &localerror))) {
+ &localerror))) {
PROBE(DBUS_METHOD_ERROR,
"'%s.%s' on '%s' at '%s' error %s: %s",
iface, member, path, dest,
- error ? error->name : localerror.name,
- error ? error->message : localerror.message);
+ localerror.name,
+ localerror.message);
if (error) {
+ error->level = VIR_ERR_ERROR;
+ error->code = VIR_ERR_DBUS_SERVICE;
+ error->domain = VIR_FROM_DBUS;
+ if (VIR_STRDUP(error->message, localerror.message) < 0)
+ goto cleanup;
+ if (VIR_STRDUP(error->str1, localerror.name) < 0)
+ goto cleanup;
ret = 0;
} else {
virReportError(VIR_ERR_DBUS_SERVICE, _("%s: %s"), member,
@@ -1567,8 +1575,9 @@ virDBusCall(DBusConnection *conn,
ret = 0;
cleanup:
- if (!error)
- dbus_error_free(&localerror);
+ if (ret < 0 && error)
+ virResetError(error);
+ dbus_error_free(&localerror);
if (reply) {
if (ret == 0 && replyout)
*replyout = reply;
@@ -1616,7 +1625,7 @@ virDBusCall(DBusConnection *conn,
*/
int virDBusCallMethod(DBusConnection *conn,
DBusMessage **replyout,
- DBusError *error,
+ virErrorPtr error,
const char *destination,
const char *path,
const char *iface,
@@ -1634,8 +1643,6 @@ int virDBusCallMethod(DBusConnection *conn,
if (ret < 0)
goto cleanup;
- ret = -1;
-
ret = virDBusCall(conn, call, replyout, error);
cleanup:
@@ -1832,7 +1839,7 @@ int virDBusCreateReply(DBusMessage **reply ATTRIBUTE_UNUSED,
int virDBusCallMethod(DBusConnection *conn ATTRIBUTE_UNUSED,
DBusMessage **reply ATTRIBUTE_UNUSED,
- DBusError *error ATTRIBUTE_UNUSED,
+ virErrorPtr error ATTRIBUTE_UNUSED,
const char *destination ATTRIBUTE_UNUSED,
const char *path ATTRIBUTE_UNUSED,
const char *iface ATTRIBUTE_UNUSED,
diff --git a/src/util/virdbus.h b/src/util/virdbus.h
index d0c7de2..e2b8d2b 100644
--- a/src/util/virdbus.h
+++ b/src/util/virdbus.h
@@ -28,7 +28,7 @@
# else
# define DBusConnection void
# define DBusMessage void
-# define DBusError void
+# define dbus_message_unref(m) do {} while (0)
# endif
# include "internal.h"
@@ -62,7 +62,7 @@ int virDBusCreateReplyV(DBusMessage **reply,
int virDBusCallMethod(DBusConnection *conn,
DBusMessage **reply,
- DBusError *error,
+ virErrorPtr error,
const char *destination,
const char *path,
const char *iface,
diff --git a/src/util/virerror.c b/src/util/virerror.c
index f5d7f54..9635c82 100644
--- a/src/util/virerror.c
+++ b/src/util/virerror.c
@@ -618,6 +618,39 @@ virDispatchError(virConnectPtr conn)
}
+/*
+ * Reports an error through the logging subsystem
+ */
+static
+void virRaiseErrorLog(const char *filename,
+ const char *funcname,
+ size_t linenr,
+ virErrorPtr err,
+ virLogMetadata *meta)
+{
+ int priority;
+
+ /*
+ * Hook up the error or warning to the logging facility
+ */
+ priority = virErrorLevelPriority(err->level);
+ if (virErrorLogPriorityFilter)
+ priority = virErrorLogPriorityFilter(err, priority);
+
+ /* We don't want to pollute stderr if no logging outputs
+ * are explicitly requested by the user, since the default
+ * error function already pollutes stderr and most apps
+ * hate & thus disable that too. If the daemon has set
+ * a priority filter though, we should always forward
+ * all errors to the logging code.
+ */
+ if (virLogGetNbOutputs() > 0 ||
+ virErrorLogPriorityFilter)
+ virLogMessage(&virLogSelf,
+ priority,
+ filename, linenr, funcname,
+ meta, "%s", err->message);
+}
/**
* virRaiseErrorFull:
@@ -639,7 +672,7 @@ virDispatchError(virConnectPtr conn)
* immediately if a callback is found and store it for later handling.
*/
void
-virRaiseErrorFull(const char *filename ATTRIBUTE_UNUSED,
+virRaiseErrorFull(const char *filename,
const char *funcname,
size_t linenr,
int domain,
@@ -655,7 +688,6 @@ virRaiseErrorFull(const char *filename ATTRIBUTE_UNUSED,
int save_errno = errno;
virErrorPtr to;
char *str;
- int priority;
virLogMetadata meta[] = {
{ .key = "LIBVIRT_DOMAIN", .s = NULL, .iv = domain },
{ .key = "LIBVIRT_CODE", .s = NULL, .iv = code },
@@ -709,30 +741,58 @@ virRaiseErrorFull(const char *filename ATTRIBUTE_UNUSED,
to->int1 = int1;
to->int2 = int2;
- /*
- * Hook up the error or warning to the logging facility
- */
- priority = virErrorLevelPriority(level);
- if (virErrorLogPriorityFilter)
- priority = virErrorLogPriorityFilter(to, priority);
-
- /* We don't want to pollute stderr if no logging outputs
- * are explicitly requested by the user, since the default
- * error function already pollutes stderr and most apps
- * hate & thus disable that too. If the daemon has set
- * a priority filter though, we should always forward
- * all errors to the logging code.
- */
- if (virLogGetNbOutputs() > 0 ||
- virErrorLogPriorityFilter)
- virLogMessage(&virLogSelf,
- priority,
- filename, linenr, funcname,
- meta, "%s", str);
+ virRaiseErrorLog(filename, funcname, linenr,
+ to, meta);
errno = save_errno;
}
+
+/**
+ * virRaiseErrorObject:
+ * @filename: filename where error was raised
+ * @funcname: function name where error was raised
+ * @linenr: line number where error was raised
+ * @newerr: the error object to report
+ *
+ * Sets the thread local error object to be a copy of
+ * @newerr and logs the error
+ *
+ * This is like virRaiseErrorFull, except that it accepts the
+ * error information via a pre-filled virErrorPtr object
+ *
+ * This is like virSetError, except that it will trigger the
+ * logging callbacks.
+ *
+ * The caller must clear the @newerr instance afterwards, since
+ * it will be copied into the thread local error.
+ */
+void virRaiseErrorObject(const char *filename,
+ const char *funcname,
+ size_t linenr,
+ virErrorPtr newerr)
+{
+ int saved_errno = errno;
+ virErrorPtr err;
+ virLogMetadata meta[] = {
+ { .key = "LIBVIRT_DOMAIN", .s = NULL, .iv = newerr->domain },
+ { .key = "LIBVIRT_CODE", .s = NULL, .iv = newerr->code },
+ { .key = NULL },
+ };
+
+ err = virLastErrorObject();
+ if (!err)
+ goto cleanup;
+
+ virResetError(err);
+ virCopyError(newerr, err);
+ virRaiseErrorLog(filename, funcname, linenr,
+ err, meta);
+ cleanup:
+ errno = saved_errno;
+}
+
+
/**
* virErrorMsg:
* @error: the virErrorNumber
diff --git a/src/util/virerror.h b/src/util/virerror.h
index 5c8578f..ad3a946 100644
--- a/src/util/virerror.h
+++ b/src/util/virerror.h
@@ -47,6 +47,11 @@ void virRaiseErrorFull(const char *filename,
const char *fmt, ...)
ATTRIBUTE_FMT_PRINTF(12, 13);
+void virRaiseErrorObject(const char *filename,
+ const char *funcname,
+ size_t linenr,
+ virErrorPtr err);
+
void virReportErrorHelper(int domcode, int errcode,
const char *filename,
const char *funcname,
@@ -165,6 +170,9 @@ void virReportOOMErrorFull(int domcode,
virReportErrorHelper(VIR_FROM_THIS, code, __FILE__, \
__FUNCTION__, __LINE__, __VA_ARGS__)
+# define virReportErrorObject(obj) \
+ virRaiseErrorObject(__FILE__, __FUNCTION__, __LINE__, obj)
+
int virSetError(virErrorPtr newerr);
void virDispatchError(virConnectPtr conn);
const char *virStrerror(int theerrno, char *errBuf, size_t errBufLen);
diff --git a/src/util/virfirewall.c b/src/util/virfirewall.c
index b536912..cd7afa5 100644
--- a/src/util/virfirewall.c
+++ b/src/util/virfirewall.c
@@ -156,7 +156,6 @@ static int
virFirewallValidateBackend(virFirewallBackend backend)
{
VIR_DEBUG("Validating backend %d", backend);
-#if WITH_DBUS
if (backend == VIR_FIREWALL_BACKEND_AUTOMATIC ||
backend == VIR_FIREWALL_BACKEND_FIREWALLD) {
int rv = virDBusIsServiceRegistered(VIR_FIREWALL_FIREWALLD_SERVICE);
@@ -180,16 +179,6 @@ virFirewallValidateBackend(virFirewallBackend backend)
backend = VIR_FIREWALL_BACKEND_FIREWALLD;
}
}
-#else
- if (backend == VIR_FIREWALL_BACKEND_AUTOMATIC) {
- VIR_DEBUG("DBus support disabled, trying direct backend");
- backend = VIR_FIREWALL_BACKEND_DIRECT;
- } else if (backend == VIR_FIREWALL_BACKEND_FIREWALLD) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("firewalld firewall backend requested, but DBus support disabled"));
- return -1;
- }
-#endif
if (backend == VIR_FIREWALL_BACKEND_DIRECT) {
const char *commands[] = {
@@ -755,7 +744,6 @@ virFirewallApplyRuleDirect(virFirewallRulePtr rule,
}
-#ifdef WITH_DBUS
static int
virFirewallApplyRuleFirewallD(virFirewallRulePtr rule,
bool ignoreErrors,
@@ -764,13 +752,13 @@ virFirewallApplyRuleFirewallD(virFirewallRulePtr rule,
const char *ipv = virFirewallLayerFirewallDTypeToString(rule->layer);
DBusConnection *sysbus = virDBusGetSystemBus();
DBusMessage *reply = NULL;
- DBusError error;
+ virError error;
int ret = -1;
if (!sysbus)
return -1;
- dbus_error_init(&error);
+ memset(&error, 0, sizeof(error));
if (!ipv) {
virReportError(VIR_ERR_INTERNAL_ERROR,
@@ -792,7 +780,7 @@ virFirewallApplyRuleFirewallD(virFirewallRulePtr rule,
rule->args) < 0)
goto cleanup;
- if (dbus_error_is_set(&error)) {
+ if (error.level == VIR_ERR_ERROR) {
/*
* As of firewalld-0.3.9.3-1.fc20.noarch the name and
* message fields in the error look like
@@ -820,11 +808,9 @@ virFirewallApplyRuleFirewallD(virFirewallRulePtr rule,
*/
if (ignoreErrors) {
VIR_DEBUG("Ignoring error '%s': '%s'",
- error.name, error.message);
+ error.str1, error.message);
} else {
- virReportError(VIR_ERR_INTERNAL_ERROR,
- _("Unable to apply rule '%s'"),
- error.message);
+ virReportErrorObject(&error);
goto cleanup;
}
} else {
@@ -835,12 +821,11 @@ virFirewallApplyRuleFirewallD(virFirewallRulePtr rule,
ret = 0;
cleanup:
- dbus_error_free(&error);
+ virResetError(&error);
if (reply)
dbus_message_unref(reply);
return ret;
}
-#endif
static int
virFirewallApplyRule(virFirewallPtr firewall,
@@ -862,12 +847,10 @@ virFirewallApplyRule(virFirewallPtr firewall,
if (virFirewallApplyRuleDirect(rule, ignoreErrors, &output) < 0)
return -1;
break;
-#if WITH_DBUS
case VIR_FIREWALL_BACKEND_FIREWALLD:
if (virFirewallApplyRuleFirewallD(rule, ignoreErrors, &output) < 0)
return -1;
break;
-#endif
default:
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Unexpected firewall engine backend"));
diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c
index 3eea5c2..6de265b 100644
--- a/src/util/virsystemd.c
+++ b/src/util/virsystemd.c
@@ -252,8 +252,8 @@ int virSystemdCreateMachine(const char *name,
VIR_DEBUG("Attempting to create machine via systemd");
if (virAtomicIntGet(&hasCreateWithNetwork)) {
- DBusError error;
- dbus_error_init(&error);
+ virError error;
+ memset(&error, 0, sizeof(error));
if (virDBusCallMethod(conn,
NULL,
@@ -280,21 +280,20 @@ int virSystemdCreateMachine(const char *name,
"Before", "as", 1, "libvirt-guests.service") < 0)
goto cleanup;
- if (dbus_error_is_set(&error)) {
+ if (error.level == VIR_ERR_ERROR) {
if (STREQ_NULLABLE("org.freedesktop.DBus.Error.UnknownMethod",
- error.name)) {
+ error.str1)) {
VIR_INFO("CreateMachineWithNetwork isn't supported, switching "
"to legacy CreateMachine method for systemd-machined");
- dbus_error_free(&error);
+ virResetError(&error);
virAtomicIntSet(&hasCreateWithNetwork, 0);
/* Could re-structure without Using goto, but this
* avoids another atomic read which would trigger
* another memory barrier */
goto fallback;
}
- virReportError(VIR_ERR_DBUS_SERVICE,
- _("CreateMachineWithNetwork: %s"),
- error.message ? error.message : _("unknown error"));
+ virReportErrorObject(&error);
+ virResetError(&error);
goto cleanup;
}
} else {
--
2.1.0
9 years, 11 months
Re: [libvirt] Live Migration with Pass-through Devices proposal
by Izumi, Taku
Hi Chen-san,
> Hi all,
>
> backgrond:
> Live migration is one of the most important features of virtualization
> technology.
> With regard to recent virtualization techniques, performance of network
> I/O is critical.
> Current network I/O virtualization (e.g. Para-virtualized I/O, VMDq) has
> a significant
> performance gap with native network I/O. Pass-through network devices
> have near
> native performance, however, they have thus far prevented live
> migration. No existing
> methods solve the problem of live migration with pass-through devices
> perfectly.
>
> There was an idea to solve the problem in website:
> https://www.kernel.org/doc/ols/2008/ols2008v2-pages-261-267.pdf
> Please refer to above document for detailed information.
>
> So I think this problem maybe could be solved by using the combination
> of existing
> technology. the attached was the architecture of migration with
> passthrough device
> we proposed. and the following steps are we considering to implement:
>
> - before boot VM, we anticipate to specify two NICs for creating
> bonding device
> (one plugged and one virtual NIC) in XML. here we can specify
> the NIC's mac addresses
> in XML, which could facilitate qemu-guest-agent to find the
> network interfaces in guest.
>
> - when boot VM, we monitor the qemu-guest-agent process in guest
> OS that
> when qemu-guest-agent is available, sending command to
> qemu-guest-agent to
> let it create the bonding device at once according to the XML
> configuration.
> here netcf maybe a good tool to create bonding device easily.
If I understand correctly, in your scenario, bonding device (bondX) is created
by qemu-guest agent dynamicaly at every boot time. Is that right ?
If so, I think it's hard for a guest administrator to configure bonding device
(such as IP address). How about creating configuration file like
/etc/sysconfig/network-scripts/ifcfg-bond0 (in Red Hat environment)
to persistent boinding device ?
> - if need to do migration, checking the bonding's virtual NIC
> whether able to
> access the plugged NIC's LAN. otherwise, when the passthroughed
> NIC is unplugged,
> the network would be broken.
I think this check should be done before enslaving each NIC.
By the way, how do you check whether both NICs are connected to the same network
segment? I wonder if it's difficult ...
> - during migration, unplug the passthroughed NIC. then do native
> magration.
>
> - on destination side, check whether need to hotplug new NIC
> according to XML.
> then hotplug the deivce according the source node in XML, tell
> qemu-guest-agent
> to switch the hotplugged NIC activities.
>
> Thanks,
> Chen
Sincrely,
Taku Izumi
9 years, 11 months
[libvirt] [RFC PATCH 00/12] qemu: add support to hot-plug/unplug cpu device
by Zhu Guihua
If you apply the folowing patchset
[PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support
https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01552.html,
and [PATCH v2 00/11] cpu: add i386 cpu hot remove support
https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg01557.html,
qemu can support hotplug and hot-unplug cpu device.
So this patch series will make libvirt support hotplug and hot-unplug cpu
device for qemu driver, and now only supports one cpu driver which is
'qemu64-x86_64-cpu'.
The cpu device's xml like this:
<cpu driver='qemu64-x86_64-cpu' apic_id='3'>
Zhu Guihua (12):
domain_conf: allocate cpu's apic id dynamically
domain_conf: add support for cpu device configuration in XML
domain_conf: introduce cpu def helpers
domain_conf: introduce cpu device hotplug helpers
qemu_driver: implement cpu device hotplug on config level
qemu_command: introduce a func for cpu device alias assignment
qemu: implement support for qemu64-x86_64-cpu
qemu: introduce qemuBuildCPUDeviceStr
qemu: implement cpu device hotplug on live level
qemu: implement cpu device hotunplug on live level
qemu_monitor_json: sort JSON array of cpu info
qemu_driver: detect threads corresponding to Vcpus
src/conf/domain_conf.c | 188 +++++++++++++++++++++++++++
src/conf/domain_conf.h | 35 +++++
src/libvirt_private.syms | 6 +
src/qemu/qemu_capabilities.c | 3 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 83 +++++++++++-
src/qemu/qemu_command.h | 8 ++
src/qemu/qemu_driver.c | 296 ++++++++++++++++++++++++-------------------
src/qemu/qemu_driver.h | 8 ++
src/qemu/qemu_hotplug.c | 129 +++++++++++++++++++
src/qemu/qemu_hotplug.h | 11 ++
src/qemu/qemu_monitor_json.c | 31 ++++-
src/util/virbitmap.c | 2 +-
src/util/virbitmap.h | 2 +
14 files changed, 668 insertions(+), 135 deletions(-)
--
1.9.3
9 years, 11 months
[libvirt] LSN-2015-0001: CVE-2015-0236 snapshots and save images leak VNC passwords
by Eric Blake
Libvirt Security Notice: LSN-2015-0001
======================================
Summary: snapshots and save images leak VNC passwords
Reported on: 20150120
Published on: 20150122
Fixed on: 20150122
Reported by: Luyao Huang <lhuang(a)redhat.com>
Patched by: Peter Krempa <pkrempa(a)redhat.com>
See also: CVE-2015-0236
Description
-----------
The two interfaces virDomainSnapshotGetXMLDesc and
virDomainSaveImageGetXMLDesc would accept the VIR_DOMAIN_XML_SECURE
flag in situations where virDomainGetXMLDesc did not, when
fine-grained access control lists (ACL) are in use. As a result, a
client can use a snapshot or save image to bypass restrictions and
gain access to the secured information.
Impact
------
A client using a read-write connection, and which has the
'domain:read' ACL privilege while lacking 'domain:secure_read', can
trigger an information leak of data by using VIR_DOMAIN_XML_SECURE
with the affected interfaces. Fortunately, the only data in this
category is the value of an optional VNC password.
Workaround
----------
VNC passwords are notoriously weak (they are capped at an 8 byte
maximum length; the VNC protocol sends them in plaintext over the
network; and FIPS mode execution prohibits the use of a VNC
password), so it is recommended that users not create domains with a
VNC password in the first place. Domains that do not use VNC
passwords do not suffer from information leaks; the use of SPICE
connections is recommended not only because it avoids the leak, but
also because SPICE provides better features than VNC for a guest
graphics device. Furthermore, the leak is only possible when
fine-grained ACLs are in use; read-only clients cannot trigger the
issue. Therefore, the problem is avoided if no user is granted the
'read' ACL privilege without also having the 'read_secure'
privilege. Another mitigation is that the information leak can only
occur if a snapshot or save image exists; a user that is denied
'read_secure' is typically also unable to create such an image, so
the leak depends on a more privileged user making use of that
feature.
Affected product
----------------
Name: libvirt
Repository: git://libvirt.org/git/libvirt.git
http://libvirt.org/git/?p=libvirt.git
Branch: master
Broken in: v1.1.0
Broken in: v1.1.1
Broken in: v1.1.2
Broken in: v1.1.3
Broken in: v1.1.4
Broken in: v1.2.0
Broken in: v1.2.1
Broken in: v1.2.2
Broken in: v1.2.3
Broken in: v1.2.4
Broken in: v1.2.5
Broken in: v1.2.6
Broken in: v1.2.7
Broken in: v1.2.8
Broken in: v1.2.9
Broken in: v1.2.10
Broken in: v1.2.11
Fixed in: v1.2.12
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 03c3c0c874c84dfa51ef17556062b095c6e1c0a3
Fixed by: b1674ad5a97441b7e1bd5f5ebaff498ef2fbb11b
Branch: v1.1.0-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: a976724f9a10730e1339628482a283653efdb72c
Fixed by: c4c824ec818ce85de049ed5546fa8ce3c8b76e32
Branch: v1.1.1-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 9a2728e1b28b67a682e55d8dd3c0d79e21f0ad37
Fixed by: 2c6fc46d987911e310d30621cd6fc195af102fee
Branch: v1.1.2-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 6eec2b830a752c95fc2d971d3daf7626f9701290
Fixed by: 947c969fc248c2324e565b5e4f80a3d11733f12b
Branch: v1.1.3-maint
Broken in: v1.1.3.1
Broken in: v1.1.3.2
Broken in: v1.1.3.3
Broken in: v1.1.3.4
Broken in: v1.1.3.5
Broken in: v1.1.3.6
Broken in: v1.1.3.7
Broken in: v1.1.3.8
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: ca840e9c827fefadae2e00875b4a552b990b959f
Fixed by: 76d6cc3f24ab545694e77e2eafa981d861b965a4
Branch: v1.1.4-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 43d16684c2018c20db1fba35542eb1d52ecb8d7a
Fixed by: 17defce9159c5111e7011e575ba72803a9418086
Branch: v1.2.0-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 9475a25c86f3748e2069af67db69d79864b707b9
Fixed by: 8abca887b19600b6652654a01a78455afd4d8294
Branch: v1.2.1-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: f7c70c20530954c2c1a2ce0d192d01a8f71c0093
Fixed by: 1f348188e0698ef2535c81d5a779189531c5df99
Branch: v1.2.2-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: e99c25ca63c695a63b4c9b91ee956be4fb660772
Fixed by: 8107c1e3694ba4685960ec09868076379718f037
Branch: v1.2.3-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 4edae3cb9600132e875a5b97cf31089a6c8f4cb2
Fixed by: 94d18e8f6dbe3afdc72b6df13e3eaa8861874a14
Branch: v1.2.4-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: d406f0858e7e3a6199788d3c64217c69d7702032
Fixed by: 4700507a484aec43b02724893cbed931e52f86e0
Branch: v1.2.5-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: b0b5e885f05a80d63e8a457031ea884e867244ad
Fixed by: 6b78ba5a15fb1077cee88cc30f1e5ba16485cd83
Branch: v1.2.6-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 9b056d8daf68b6357ca05adbfddb53a85d077a1d
Fixed by: b87f3f835a5c88625d9514aae9a2ddf30bc64319
Branch: v1.2.7-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: cc0cc987a53f5e3825c7d972e219e08688d4480b
Fixed by: aeb505814531d505f4d7718a10a96dd6dea14457
Branch: v1.2.8-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: c0f3e664a68509a3d842bdc3fd126257da46d0c0
Fixed by: cef411296b2513ffd80dbf9cab1f54bd0c68fe6a
Branch: v1.2.9-maint
Broken in: v1.2.9.1
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 19f8fec02d9b0a8de877d872c5b59597bd878a8d
Fixed by: 295f3c88ce71b8e83a489cb0d48431e124c12081
Branch: v1.2.10-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: c379b17e259db4f07843c2a7a883fda1a1bd043f
Fixed by: d6e10847e0cd2bd7fc1824ad65fe859987715881
Branch: v1.2.11-maint
Broken by: e341435e5090677c67a0d3d4ca0393102054841f
Fixed by: 41358b7e91a20c9a89b03202b8c4139f92dd1953
Fixed by: 7195a5fa4718d915b28bb6e3380255eb1fbf994a
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
9 years, 11 months
[libvirt] nodeinfo test cases for x86_64 AMD CPUs
by Steffen Persvold
Hi,
Lately we’ve been puzzled by the nodeinfo returned for AMD 63xx based platforms so I checked out libvirt from Git and checked out the testcases in test/nodeinfodata.
Currently you have 3 AMD test cases there :
linux-x86_64-test3 :
AMD 6172 2.1 GHz (MCM, 12 cores per package/socket, 2 numa nodes per package/socket, 1 thread/core)
4 Sockets, 8 NUMA nodes, 48 CPU cores total.
linux-x86_64-test7 :
AMD 6174 2.2 GHz (MCM, 12 cores per package/socket, 2 numa nodes per package/socket, 1 thread/core)
2 Sockets, 4 NUMA nodes, 24 CPU cores total.
linux-x86_64-test8 :
AMD 6282 SE 2.6 GHz (MCM, 8 CU(core) per package/socket, 2 numa nodes per package/socket, 2 threads/CU(core))
4 Sockets, 8 NUMA nodes, 64 CPU cores total.
However, the “expected” output from each of these are wrong I believe :
% ~/libvirt/tests/nodeinfodata$ cat linux-x86_64-test{3,7,8}.expected
CPUs: 48/48, MHz: 2100, Nodes: 8, Sockets: 1, Cores: 6, Threads: 1
CPUs: 24/24, MHz: 2200, Nodes: 1, Sockets: 1, Cores: 24, Threads: 1
CPUs: 64/64, MHz: 2593, Nodes: 1, Sockets: 1, Cores: 64, Threads: 1
In my opinion it should have been :
CPUs: 48/48, MHz: 2100, Nodes: 8, Sockets: 4, Cores: 12, Threads: 1
CPUs: 24/24, MHz: 2200, Nodes: 4, Sockets: 2, Cores: 12, Threads: 1
CPUs: 64/64, MHz: 2593, Nodes: 8, Sockets: 4, Cores: 8, Threads: 2
Atleast that’s more in line with what tools like “lscpu” and “lstopo” would report.
For example, I have a dual-socket AMD 6376 based system. lscpu reports :
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 2
NUMA node(s): 4
Vendor ID: AuthenticAMD
CPU family: 21
Model: 2
Stepping: 0
CPU MHz: 2299.820
BogoMIPS: 4600.03
Virtualization: AMD-V
L1d cache: 16K
L1i cache: 64K
L2 cache: 2048K
L3 cache: 6144K
NUMA node0 CPU(s): 0-7
NUMA node1 CPU(s): 8-15
NUMA node2 CPU(s): 16-23
NUMA node3 CPU(s): 24-31
virsh nodeinfo however :
CPU model: x86_64
CPU(s): 32
CPU frequency: 2299 MHz
CPU socket(s): 1
Core(s) per socket: 32
Thread(s) per core: 1
NUMA cell(s): 1
Memory size: 49448656 KiB
Looking more closely at the code in src/nodeinfo.c:linuxNodeInfoCPUPopulate() I believe it makes some false assumptions.
When iterating over the NUMA nodes, it expects that NUMA nodes can contain more than one socket, whereas on AMD systems atleast it’s the other way around (Sockets can contain more than 1 socket). Hence, the topology check at the end goes all wrong and libvirt uses just a flat topology :
if ((nodeinfo->nodes *
nodeinfo->sockets *
nodeinfo->cores *
nodeinfo->threads) != (nodeinfo->cpus + offline)) {
nodeinfo->nodes = 1;
nodeinfo->sockets = 1;
nodeinfo->cores = nodeinfo->cpus + offline;
nodeinfo->threads = 1;
}
If instead the “fallback” mechanism is used, which iterates over /sys/devices/system/cpu/cpu%d and finds sockets/cores/threads is used, *and* you leave nodeinfo->nodes out of the equation then it all makes sense. Iterating over entries in /sys/devices/system/node/node%d would then only be used to find nodeinfo->nodes.
I have limited insight into how this would work on say an S390 system, so if my assumptions here are completely wrong please do tell :)
Cheers,
--
Steffen Persvold
Chief Architect NumaChip, Numascale AS
Tel: +47 23 16 71 88 Fax: +47 23 16 71 80 Skype: spersvold
9 years, 11 months
[libvirt] (no subject)
by akrowiak＠linux.vnet.ibm.com
From: Tony Krowiak <akrowiak(a)linux.vnet.ibm.com>
This patch set provides the code to synchonize some macvtap device
modes when the values are changed on the guest's network device. The
following modes will by synchronized:
* PROMISC
* MULTICAST
* ALLMULTI
I noticed something while testing this patch set that did not occur prior
to installing more recent kernel and Qemu distributions. It seems that
the VLAN table always has an entry for VLAN ID 0 when the rxfilter is
queried during processing of the NIC_RX_FILTER_CHANGED event. That means
that the PROMISC flag for macvtap0 will be set. I don't know if this
will cause problems, but I thought I'd make note of it in case anybody
wants to comment on that.
Tony Krowiak (2):
util: Functions for getting/setting device options
qemu: change macvtap device options in response to
NIC_RX_FILTER_CHANGED
9 years, 11 months
[libvirt] [PATCH 0/2] fix two issues found by clang
by Pavel Hrdina
Pavel Hrdina (2):
xenapi_driver: fix copy-paste typo
esx_vi: fix possible segfault
src/esx/esx_vi.c | 3 ++-
src/xenapi/xenapi_driver.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
--
2.0.5
9 years, 11 months
[libvirt] [PATCH 0/8] Enable NIC reporting to systemd
by Daniel P. Berrange
This series enables the QEMU and LXC drivers to report the
network interface backends they use to systemd. This gets
then shown to the user in
# machinectl status lxc-shell
lxc-shell(95449419f969d649d9962566ec42af7d)
Since: Fri 2015-01-16 16:53:37 GMT; 3s ago
Leader: 28085 (sh)
Service: libvirt-lxc; class container
Iface: vnet0
Address: fe80::216:3eff:fe00:c317%124
OS: Fedora 21 (Twenty One)
Unit: machine-lxc\x2dshell.scope
└─28085 /bin/sh
but most fun is that if you add nss-mymachines to the
/etc/nsswitch.conf, the machine names can now be used
as hostnames.
eg if your guest is 'lxc-shell' this lets you just do
'ssh lxc-shell' and it'll use the detected link local
address to connect.
Daniel P. Berrange (8):
qemu: report TAP device indexes to systemd
systemd: don't report an error if the guest is already terminated
lxc: don't build pidfile string multiple times
lxc: re-arrange startup synchronization sequence with controller
lxc: only write XML once for lxc controller
lxc: delay setup of cgroup until we have the init pid
lxc: more logging during startup paths
lxc: report veth device indexes to systemd
src/conf/domain_conf.c | 2 +-
src/conf/domain_conf.h | 5 ++
src/lxc/lxc_cgroup.c | 15 +++---
src/lxc/lxc_cgroup.h | 5 +-
src/lxc/lxc_container.c | 8 +++
src/lxc/lxc_controller.c | 116 ++++++++++++++++++++++++++++++++++++----
src/lxc/lxc_process.c | 134 +++++++++++++++++++++++++++--------------------
src/qemu/qemu_cgroup.c | 13 +++--
src/qemu/qemu_cgroup.h | 4 +-
src/qemu/qemu_command.c | 27 ++++++++--
src/qemu/qemu_command.h | 7 ++-
src/qemu/qemu_driver.c | 7 ++-
src/qemu/qemu_hotplug.c | 4 +-
src/qemu/qemu_process.c | 9 +++-
src/util/virsystemd.c | 25 +++++++--
tests/qemuxml2argvtest.c | 5 +-
tests/qemuxmlnstest.c | 6 ++-
17 files changed, 288 insertions(+), 104 deletions(-)
--
2.1.0
9 years, 11 months
[libvirt] [PATCH] network: verify proper address family in updates to <host> and <range>
by Laine Stump
By specifying parentIndex in a call to virNetworkUpdate(), it was
possible to direct libvirt to add a dhcp range or static host of a
non-matching address family to the <dhcp> element of an <ip>. For
example, given:
<ip address='192.168.122.1' netmask='255.255.255.0'/>
<ip family='ipv6' address='2001:db6:ca3:45::1' prefix='64'/>
you could provide a static host entry with an IPv4 address, and
specify that it be added to the 2nd <ip> element (index 1):
virsh net-update default add ip-dhcp-host --parent-index 1 \
'<host mac="52:54:00:00:00:01" ip="192.168.122.45"/>'
This would be happily added with no error (and no concern of any
possible future consequences).
This patch checks that any dhcp range or host element being added to a
network ip's <dhcp> subelement has addresses of the same family as the
ip element they are being added to.
This problem was noticed when looking at the reproduction case for
https://bugzilla.redhat.com/show_bug.cgi?id=1182486 (but is not a
solution to that bug).
---
src/conf/network_conf.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index 23ec369..15501ec 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -1,7 +1,7 @@
/*
* network_conf.c: network XML handling
*
- * Copyright (C) 2006-2014 Red Hat, Inc.
+ * Copyright (C) 2006-2015 Red Hat, Inc.
* Copyright (C) 2006-2008 Daniel P. Berrange
*
* This library is free software; you can redistribute it and/or
@@ -3285,6 +3285,14 @@ virNetworkDefUpdateIPDHCPHost(virNetworkDefPtr def,
&host, partialOkay) < 0)
goto cleanup;
+ if (VIR_SOCKET_ADDR_FAMILY(&ipdef->address)
+ != VIR_SOCKET_ADDR_FAMILY(&host.ip)) {
+ virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+ _("the address family of a host entry IP must match "
+ "the address family of the dhcp element's parent"));
+ goto cleanup;
+ }
+
if (command == VIR_NETWORK_UPDATE_COMMAND_MODIFY) {
/* search for the entry with this (ip|mac|name),
@@ -3422,6 +3430,14 @@ virNetworkDefUpdateIPDHCPRange(virNetworkDefPtr def,
if (virSocketAddrRangeParseXML(def->name, ctxt->node, &range) < 0)
goto cleanup;
+ if (VIR_SOCKET_ADDR_FAMILY(&ipdef->address)
+ != VIR_SOCKET_ADDR_FAMILY(&range.start)) {
+ virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+ _("the address family of a dhcp range must match "
+ "the address family of the dhcp element's parent"));
+ goto cleanup;
+ }
+
/* check if an entry with same name/address/ip already exists */
for (i = 0; i < ipdef->nranges; i++) {
if (virSocketAddrEqual(&range.start, &ipdef->ranges[i].start) &&
--
1.9.3
9 years, 11 months
[libvirt] [PATCH v3 1/2] qemu: output error when try to hotplug unsupport console
by Luyao Huang
https://bugzilla.redhat.com/show_bug.cgi?id=1164627
When using 'virsh attach-device' to hotplug an unsupported console type
into a qemu guest, the attachment will erroneously allows the
attachment. This patch will check to ensure that only the support target
types are used for a running guest. NB, Although a guest can be defined
with an improper target, startup will cause failure.
Signed-off-by: Luyao Huang <lhuang(a)redhat.com>
---
src/qemu/qemu_command.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index c041ee7..df87e1e 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -10067,13 +10067,17 @@ qemuBuildConsoleChrDeviceStr(char **deviceStr,
break;
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL:
+ break;
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_NONE:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_XEN:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_UML:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LXC:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_OPENVZ:
case VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_LAST:
- break;
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("unsupported console target type %s"),
+ NULLSTR(virDomainChrConsoleTargetTypeToString(chr->targetType)));
+ goto cleanup;
}
ret = 0;
--
1.8.3.1
9 years, 11 months
