- Devel - libvirt List Archives

[libvirt] [PATCH] conf: Make really sure we don't access non-existing vCPUs again
by Daniel P. Berrange 13 Jul '16

13 Jul '16

From: Martin Kletzander <mkletzan(a)redhat.com> MinGW complained that we might be dereferencing a NULL pointer. While that can't be true, the logic certainly allows for that. ../../src/conf/domain_conf.c: In function 'virDomainDefPostParse': ../../src/conf/domain_conf.c:4224:18: error: potential null pointer dereference [-Werror=null-dereference] if (!vcpu->online && vcpu->cpumask) { ~~~~^~~~~~~~ Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- Pushed as build fix src/conf/domain_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index db1a0ff..1fd826d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -4221,7 +4221,7 @@ virDomainDefRemoveOfflineVcpuPin(virDomainDefPtr def) for (i = 0; i < virDomainDefGetVcpusMax(def); i++) { vcpu = virDomainDefGetVcpu(def, i); - if (!vcpu->online && vcpu->cpumask) { + if (vcpu && !vcpu->online && vcpu->cpumask) { virBitmapFree(vcpu->cpumask); vcpu->cpumask = NULL; -- 2.7.4

1 0

[libvirt] [PATCH] libvirt.spec.in: require systemd-container on >= f24
by Daniel P. Berrange 13 Jul '16

13 Jul '16

The systemd-machined tools libvirt uses were split into a systemd-container RPM. Without depending on this, libvirt may silently fallback to the non-systemd cgroup impl which is not desirable. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- libvirt.spec.in | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index 2b98836..8ebfea5 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -619,6 +619,9 @@ Requires: gzip Requires: bzip2 Requires: lzop Requires: xz +%if 0%{?fedora} > 23 +Requires: systemd-container +%endif %description daemon-driver-qemu The qemu driver plugin for the libvirtd daemon, providing @@ -634,6 +637,9 @@ Group: Development/Libraries Requires: libvirt-daemon = %{version}-%{release} # There really is a hard cross-driver dependency here Requires: libvirt-daemon-driver-network = %{version}-%{release} +%if 0%{?fedora} > 23 +Requires: systemd-container +%endif %description daemon-driver-lxc The LXC driver plugin for the libvirtd daemon, providing -- 2.7.4

2 1

[libvirt] [PATCH] qemu: command: Fix awkward formatting
by Andrea Bolognani 13 Jul '16

13 Jul '16

--- Pushed as trivial. src/qemu/qemu_command.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 2ca6d26..fe4bb88 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -5158,9 +5158,7 @@ qemuBuildVirtioSerialPortDevStr(const virDomainDef *def, dev->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW && dev->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_S390) { /* Check it's a virtio-serial address */ - if (dev->info.type != - VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_SERIAL) - { + if (dev->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_SERIAL) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("virtio serial device has invalid address type")); goto error; -- 2.7.4

1 0

[libvirt] linux guest time synchronization
by John L. Magee 13 Jul '16

13 Jul '16

We have recently updated some servers to CentOS 7 qemu kvm hosts and have been replacing older CentOS 5 and 6 guests with new CentOS 7 guests. Somehow, I thought we no longer had to run NTP/Chrony on the guests if we had the proper timer configuration. It turns out that the guest hwclock stays up to date with the host, where we are running Chrony, but the guest system time is drifting significantly. Is there no way to keep guest system time synchronized to the hwclock? It seems like a waste of resources to run Chrony on all the guests. Please redirect me to the correct group if this is not the right one. Thanks in advance. John L Magee jlmagee(a)mageenet.net<mailto:jlmagee@mageenet.net>

1 0

[libvirt] [PATCH] Don't error when attaching security label of model "none"
by Daniel P. Berrange 13 Jul '16

13 Jul '16

If you invoke virDomainLxcEnterSecurityLabel() on security model of "none" it will report an error. Logically a "none" security model should be treated as a no-op, so we should just return success immediately, instead of an error. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/libvirt-lxc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/libvirt-lxc.c b/src/libvirt-lxc.c index 16e08e9..c487ece 100644 --- a/src/libvirt-lxc.c +++ b/src/libvirt-lxc.c @@ -257,6 +257,8 @@ virDomainLxcEnterSecurityLabel(virSecurityModelPtr model, _("Support for AppArmor is not enabled")); goto error; #endif + } else if (STREQ(model->model, "none")) { + /* nothing todo */ } else { virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, _("Security model %s cannot be entered"), -- 2.7.4

2 2

[libvirt] [PATCH] Make really sure we don't access non-existing vCPUs
by Martin Kletzander 13 Jul '16

13 Jul '16

MinGW complained that we might be dereferencing a NULL pointer. While that's most probably not going to be true (now), the logic certainly allows for that and we might actually do this a lot in the future with sparse vcpu mapping. ../../src/conf/domain_conf.c: In function 'virDomainDefGetVcpuPinInfoHelper': ../../src/conf/domain_conf.c:1545:17: error: potential null pointer dereference [-Werror=null-dereference] if (vcpu->cpumask) ~~~~^~~~~~~~~ Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- I could've pushed this as a build breaker, but I'm not really sure everyone will like this to be handled this way. I also did another fix for this where we don't do int->size_t->int casting all the time, but it's probably not worth the hassle. Also I don't know whether Peter has more stuff for this in his pockets now, so I figured I rather submit this for review. src/conf/domain_conf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 16e0736e09db..308073897880 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -1542,6 +1542,9 @@ virDomainDefGetVcpuPinInfoHelper(virDomainDefPtr def, virDomainVcpuDefPtr vcpu = virDomainDefGetVcpu(def, i); virBitmapPtr bitmap = NULL; + if (!vcpu) + continue; + if (vcpu->cpumask) bitmap = vcpu->cpumask; else if (def->placement_mode == VIR_DOMAIN_CPU_PLACEMENT_MODE_AUTO && -- 2.9.0

2 5

[libvirt] [PATCHv2 0/2] disable default gateway in IPv6 RA for isolated networks
by Maxim Perevedentsev 13 Jul '16

13 Jul '16

In case of DHCPv6 in isolated network, we start dnsmasq which sends Router Advertisements (RA). If RA containts no gateway then the link-local address of the source of RA is considered a gateway (and guest installs a corresponding default route). If a guest has two network interfaces (public and isolated network) and the user installs a default route through "public" interface, the guest will have something like default via fe80::ffff:1:1 dev eth2 metric 1024 default via fe80::5054:ff:fe0a:d808 dev eth3 proto ra metric 1024 expires 1789sec RA route metric may vary, and it is preferred. The validity of default route is controlled by "default [route] lifetime" field in RA. If it is 0, then the default gateway announced is considered invalid, and no default route is installed into guest. dnsmasq 2.67+ supports "ra-param=<interface>,<RA interval>,<default lifetime>" option. We can pass "ra-param=*,0,0" (here, RA_interval=0 means default) to disable default gateway in RA. This patchset adds detection for "ra-param" in dnsmasq and sets "ra-param=*,0,0" for isolated network if dnsmasq supports it. Maxim Perevedentsev (2): Fix message about dnsmasq BINDTODEVICE capability. dnsmasq: disable IPv6 default gateway in RA for isolated networks src/network/bridge_driver.c | 7 +++++++ src/util/virdnsmasq.c | 8 ++++++-- src/util/virdnsmasq.h | 1 + 3 files changed, 14 insertions(+), 2 deletions(-) -- 1.8.3.1

3 5

[libvirt] [PATCH] qemu: getAutoDumpPath() return value should be dumpfile not domname.
by Yan Fu 13 Jul '16

13 Jul '16

Resolves:https://bugzilla.redhat.com/show_bug.cgi?id=1354238 --- src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index f8d9afe..55a5404 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3869,7 +3869,7 @@ getAutoDumpPath(virQEMUDriverPtr driver, timestr)); virObjectUnref(cfg); - return domname; + return dumpfile; } static void -- 1.8.3.1

2 1

[libvirt] [PATCH V2] systemd: fix ready notification on abstract socket
by Jim Fehlig 12 Jul '16

12 Jul '16

At least with systemd v210, NOTIFY_SOCKET is abstact, e.g. @/org/freedesktop/systemd1/notify. sendmsg() fails on such a socket with "Connection refused". The unix(7) man page contains the following details wrt abstract socket addresses abstract: an abstract socket address is distinguished (from a pathname socket) by the fact that sun_path[0] is a null byte ('\0'). The socket's address in this namespace is given by the additional bytes in sun_path that are covered by the specified length of the address structure. (Null bytes in the name have no special significance.) So we need to be more precise about the address length, setting it to the sizeof sa_family_t + length of address copied to sun_path instead of setting it to the sizeof the entire sockaddr_un struct. Resolves: https://bugzilla.opensuse.org/show_bug.cgi?id=987668 Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- V2: Use offsetof() to calculate size of sa_family_t field of the sockaddr_un structure instead of sizeof(). src/util/virsystemd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c index 871db7e..969cd68 100644 --- a/src/util/virsystemd.c +++ b/src/util/virsystemd.c @@ -495,7 +495,6 @@ virSystemdNotifyStartup(void) }; struct msghdr mh = { .msg_name = &un, - .msg_namelen = sizeof(un), .msg_iov = &iov, .msg_iovlen = 1, }; @@ -515,6 +514,8 @@ virSystemdNotifyStartup(void) if (un.sun_path[0] == '@') un.sun_path[0] = '\0'; + mh.msg_namelen = offsetof(struct sockaddr_un, sun_path) + strlen(path); + fd = socket(AF_UNIX, SOCK_DGRAM, 0); if (fd < 0) { VIR_WARN("Unable to create socket FD"); -- 2.8.4

2 2

[libvirt] [PATCH] systemd: fix ready notification on abstract socket
by Jim Fehlig 12 Jul '16

12 Jul '16

At least with systemd v210, NOTIFY_SOCKET is abstact, e.g. @/org/freedesktop/systemd1/notify. sendmsg() fails on such a socket with "Connection refused". The unix(7) man page contains the following details wrt abstract socket addresses abstract: an abstract socket address is distinguished (from a pathname socket) by the fact that sun_path[0] is a null byte ('\0'). The socket's address in this namespace is given by the additional bytes in sun_path that are covered by the specified length of the address structure. (Null bytes in the name have no special significance.) So we need to be more precise about the address length, setting it to the sizeof sa_family_t + length of address copied to sun_path instead of setting it to the sizeof the entire sockaddr_un struct. Resolves: https://bugzilla.opensuse.org/show_bug.cgi?id=987668 Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/util/virsystemd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c index 871db7e..1b5e9fe 100644 --- a/src/util/virsystemd.c +++ b/src/util/virsystemd.c @@ -495,7 +495,6 @@ virSystemdNotifyStartup(void) }; struct msghdr mh = { .msg_name = &un, - .msg_namelen = sizeof(un), .msg_iov = &iov, .msg_iovlen = 1, }; @@ -521,6 +520,7 @@ virSystemdNotifyStartup(void) return; } + mh.msg_namelen = sizeof(sa_family_t) + strlen(path); if (sendmsg(fd, &mh, MSG_NOSIGNAL) < 0) VIR_WARN("Failed to notify systemd"); -- 2.1.4

2 2