August 2020 - Devel - libvirt List Archives

[PATCH 0/5] remove NVDIMM auto-alignment for pSeries guests
by Daniel Henrique Barboza 10 Sep '20

10 Sep '20

Hi, In [1] Andrea proposed that we should *not* auto-align down the NVDIMM size for pSeries guests. Instead we should error out and provide users with a suggested aligned value. This patch implements it. [1] https://www.redhat.com/archives/libvir-list/2020-July/msg01471.html Daniel Henrique Barboza (5): qemu_domain.c: make qemuDomainGetMemorySizeAlignment() public qemu_validate.c: add pSeries NVDIMM size alignment validation qemu_domain.c: do not auto-align ppc64 NVDIMMs qemu_domain.c: change qemuDomainMemoryDeviceAlignSize() return type Revert "formatdomain.html.in: mention pSeries NVDIMM 'align down' mechanic" docs/formatdomain.html.in | 6 +- src/qemu/qemu_domain.c | 57 ++----------------- src/qemu/qemu_domain.h | 7 ++- src/qemu/qemu_hotplug.c | 6 +- src/qemu/qemu_validate.c | 43 ++++++++++++-- ...ory-hotplug-nvdimm-ppc64.ppc64-latest.args | 2 +- .../memory-hotplug-nvdimm-ppc64.xml | 2 +- .../memory-hotplug-nvdimm-ppc64.xml | 2 +- 8 files changed, 55 insertions(+), 70 deletions(-) -- 2.26.2

3 14

[PATCH] network: allow accept_ra == 0 when enabling ipv6 forwarding
by Ian Wienand 10 Sep '20

10 Sep '20

The checks modified here were added with 00d28a78b5d1f6eaf79f06ac59e31c568af9da37 to avoid losing routes on hosts. However, tools such as systemd-networking and NetworkManager manage RA's in userspace and thus IPv6 may be up and working on an interface even with accept_ra == 0. This modifies the check to only error if an interface's accept_ra is already set to "1"; as noted inline this seems to when it is likely that enabling forwarding may change the RA acceptance behaviour of the interface. I have noticed this because I am using the IPv6 NAT features enabled with 927acaedec7effbe67a154d8bfa0e67f7d08e6c7. I am using this on my laptop which switches between wired and wireless connections; both of which are configured in an unremarkable way by Fedora's NetworkManager and get configured for IPv6 via SLAAC and whatever NetworkManager magic it does. With this I can define and start a libvirt network with <nat ipv6="yes"> and <ip family='ipv6' address='fc00:abcd:ef12:34::' prefix='64'> and it seems to "just work" for guests. Signed-off-by: Ian Wienand <iwienand(a)redhat.com> --- src/util/virnetdevip.c | 41 +++++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 14 deletions(-) diff --git a/src/util/virnetdevip.c b/src/util/virnetdevip.c index 409f062c5c..de27cacfc9 100644 --- a/src/util/virnetdevip.c +++ b/src/util/virnetdevip.c @@ -496,7 +496,7 @@ virNetDevIPGetAcceptRA(const char *ifname) } struct virNetDevIPCheckIPv6ForwardingData { - bool hasRARoutes; + bool hasKernelRARoutes; /* Devices with conflicting accept_ra */ char **devices; @@ -552,15 +552,26 @@ virNetDevIPCheckIPv6ForwardingCallback(struct nlmsghdr *resp, if (!ifname) return -1; - accept_ra = virNetDevIPGetAcceptRA(ifname); - VIR_DEBUG("Checking route for device %s (%d), accept_ra: %d", ifname, ifindex, accept_ra); - if (accept_ra != 2 && virNetDevIPCheckIPv6ForwardingAddIF(data, &ifname) < 0) + accept_ra = virNetDevIPGetAcceptRA(ifname); + /* 0 = do no accept RA + * 1 = accept if forwarding disabled + * 2 = ovveride and accept RA when forwarding enabled + * + * When RA is managed by userspace (systemd-networkd or + * NetworkManager) accept_ra is unset and we don't need to + * worry about it. If it is 1, enabling forwarding might + * change the behaviour so the user needs to be warned. + */ + if (accept_ra == 0) + return 0; + + if (accept_ra == 1 && virNetDevIPCheckIPv6ForwardingAddIF(data, &ifname) < 0) return -1; - data->hasRARoutes = true; + data->hasKernelRARoutes = true; return 0; } @@ -590,11 +601,13 @@ virNetDevIPCheckIPv6ForwardingCallback(struct nlmsghdr *resp, VIR_DEBUG("Checking multipath route nexthop device %s (%d), accept_ra: %d", ifname, nh->rtnh_ifindex, accept_ra); - if (accept_ra != 2 && virNetDevIPCheckIPv6ForwardingAddIF(data, &ifname) < 0) - return -1; + if (accept_ra == 1) { + if (virNetDevIPCheckIPv6ForwardingAddIF(data, &ifname) < 0) + return -1; + data->hasKernelRARoutes = true; + } VIR_FREE(ifname); - data->hasRARoutes = true; len -= NLMSG_ALIGN(nh->rtnh_len); VIR_WARNINGS_NO_CAST_ALIGN @@ -613,7 +626,7 @@ virNetDevIPCheckIPv6Forwarding(void) struct rtgenmsg genmsg; size_t i; struct virNetDevIPCheckIPv6ForwardingData data = { - .hasRARoutes = false, + .hasKernelRARoutes = false, .devices = NULL, .ndevices = 0 }; @@ -644,11 +657,11 @@ virNetDevIPCheckIPv6Forwarding(void) goto cleanup; } - valid = !data.hasRARoutes || data.ndevices == 0; + valid = !data.hasKernelRARoutes || data.ndevices == 0; /* Check the global accept_ra if at least one isn't set on a per-device basis */ - if (!valid && data.hasRARoutes) { + if (!valid && data.hasKernelRARoutes) { int accept_ra = virNetDevIPGetAcceptRA(NULL); valid = accept_ra == 2; VIR_DEBUG("Checked global accept_ra: %d", accept_ra); @@ -663,9 +676,9 @@ virNetDevIPCheckIPv6Forwarding(void) } virReportError(VIR_ERR_INTERNAL_ERROR, - _("Check the host setup: enabling IPv6 forwarding with " - "RA routes without accept_ra set to 2 is likely to cause " - "routes loss. Interfaces to look at: %s"), + _("Check the host setup: interface has accept_ra set to 1 " + "and enabling forwarding without accept_ra set to 2 is " + "likely to cause routes loss. Interfaces to look at: %s"), virBufferCurrentContent(&buf)); } -- 2.26.2

3 8

[libvirt] [PATCH-for-4.2] hw/mips: Deprecate the r4k machine
by Philippe Mathieu-Daudé 10 Sep '20

10 Sep '20

The r4k machine was introduced in 2005 (6af0bf9c7) and its last logical change was in 2005 (9542611a6). After we can count 164 maintenance commits (QEMU API changes) with the exception of 1 fix in 2015 (memory leak, commit 3ad9fd5a). This machine was introduced as a proof of concept to run a MIPS CPU. 2 years later, the Malta machine was add (commit 5856de80) modeling a real platform. Note also this machine has no specification except 5 lines in the header of this file: * emulates a simple machine with ISA-like bus. * ISA IO space mapped to the 0x14000000 (PHYS) and * ISA memory at the 0x10000000 (PHYS, 16Mb in size). * All peripherial devices are attached to this "bus" with * the standard PC ISA addresses. It is time to deprecate this obsolete machine. Users are recommended to use the Malta board, which hardware is well documented. Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- qemu-deprecated.texi | 5 +++++ hw/mips/mips_r4k.c | 1 + MAINTAINERS | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 4b4b7425ac..05265b43c8 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -266,6 +266,11 @@ The 'scsi-disk' device is deprecated. Users should use 'scsi-hd' or @section System emulator machines +@subsection mips r4k platform (since 4.2) + +This machine type is very old and unmaintained. Users should use the 'malta' +machine type instead. + @subsection pc-0.12, pc-0.13, pc-0.14 and pc-0.15 (since 4.0) These machine types are very old and likely can not be used for live migration diff --git a/hw/mips/mips_r4k.c b/hw/mips/mips_r4k.c index 70024235ae..0b79ad26cb 100644 --- a/hw/mips/mips_r4k.c +++ b/hw/mips/mips_r4k.c @@ -294,6 +294,7 @@ void mips_r4k_init(MachineState *machine) static void mips_machine_init(MachineClass *mc) { + mc->deprecation_reason = "use malta machine type instead"; mc->desc = "mips r4k platform"; mc->init = mips_r4k_init; mc->block_default_type = IF_IDE; diff --git a/MAINTAINERS b/MAINTAINERS index 5e5e3e52d6..3b3a88e264 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -972,7 +972,7 @@ F: hw/net/mipsnet.c R4000 M: Aurelien Jarno <aurelien(a)aurel32.net> R: Aleksandar Rikalo <aleksandar.rikalo(a)rt-rk.com> -S: Maintained +S: Obsolete F: hw/mips/mips_r4k.c Fulong 2E -- 2.21.0

8 21

[PATCH] disk storage: fix allocation size for pool format dos
by Sebastian Mitterle 09 Sep '20

09 Sep '20

The changed condition was always false because the function was always called with boundary values 0. Use the free extent's start value to get its start offset from the cylinder boundary and determine if the needed size for allocation needs to be expanded too in case the offset doesn't fit within extra bytes for alignment. This fixes an issue where vol-create-from will call qemu-img convert to create a destination volume of same capacity as the source volume and qemu-img will error 'Cannot grow device files' due to the partition being too small for the source although both destination partition and source volume have the same capacity. Signed-off-by: Sebastian Mitterle <smitterl(a)redhat.com> --- src/storage/storage_backend_disk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index a6d4e41220..ec0679d353 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -691,7 +691,7 @@ virStorageBackendDiskPartBoundaries(virStoragePoolObjPtr pool, if (def->source.format == VIR_STORAGE_POOL_DISK_DOS) { /* align to cylinder boundary */ neededSize += extraBytes; - if ((*start % cylinderSize) > extraBytes) { + if ((dev->freeExtents[i].start % cylinderSize) > extraBytes) { /* add an extra cylinder if the offset can't fit within the extra bytes we have */ neededSize += cylinderSize; -- 2.25.2

2 2

[PATCH] doc: add some examples for IPv6 NAT configuration
by Ian Wienand 09 Sep '20

09 Sep '20

Add some expanded examples for the nat ipv6 introduced with 927acaedec7effbe67a154d8bfa0e67f7d08e6c7. Unfortunately while for IPv4 it's well-known what addresses ranges are useful for NAT, with IPv6 unless you enjoy digging through RFC's going back-and-forth over unique local addresses and the meaning of the word "site" it's generally much less obvious. I've tried to add some details on choosing a range inline with RFC 4193 and then some pointers for when it maybe doesn't work in the guest as you first expect despite you doing what the RFC's say! Signed-off-by: Ian Wienand <iwienand(a)redhat.com> --- docs/formatnetwork.html.in | 47 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index fb740111b1..94a4cab4d1 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -1209,6 +1209,53 @@ </ip> </network></pre> + <h3><a id="examplesNATv6">IPv6 NAT based network</a></h3> + + <p> + Below is a variation for also providing IPv6 NAT. This can be + especially useful when using multiple interfaces where some, + such as WiFi cards, can not be bridged (usually on a laptop), + making it difficult to provide end-to-end IPv6 routing. + </p> + + <pre> +<network> + <name>default6</name> + <bridge name="virbr0"/> + <forward mode="nat"> + <nat ipv6='yes'> + <port start='1024' end='65535'/> + </nat> + + <ip address="192.168.122.1" netmask="255.255.255.0"> + <dhcp> + <range start="192.168.122.2" end="192.168.122.254"/> + </dhcp> + </ip> + <ip family="ipv6" address="fdXX:XXXX:XXXX:NNNN:: prefix="64"/> + </ip> +</network></pre> + + <p>IPv6 NAT addressing has some caveats over the more straight + forward IPv4 case. + <a href="https://tools.ietf.org/html/rfc4193">RFC 4193</a> + defines the address range <tt>fd00::/8</tt> for <tt>/48</tt> IPv6 + private networks. It should be concatenated with a random 40-bit + string (i.e. 10 random hexadecimal digits replacing the <tt>X</tt> + values above, RFC 4193 provides + an <a href="https://tools.ietf.org/html/rfc4193#section-3.2.2">algorithm</a> + if you do not have a source of sufficient randomness). This + leaves <tt>0</tt> through <tt>ffff</tt> for subnets (<tt>N</tt> + above) which you can use at will.</p> + + <p>Many operating systems will not consider these addresses as + preferential to IPv4, due to some practial history of these + addresses being present but unroutable and causing networking + issues. On many Linux distributions, you may need to + override <tt>/etc/gai.conf</tt> with values + from <a href="https://www.ietf.org/rfc/rfc3484.txt">RFC 3484</a> + to have your IPv6 NAT network correctly preferenced over IPv4.</p> + <h3><a id="examplesRoute">Routed network config</a></h3> <p> -- 2.26.2

2 2

[PATCH] client: fix memory leak in client msg
by Hao Wang 09 Sep '20

09 Sep '20

>From 3ad3fae4f2562a11bef8dcdd25b6a7e0b00d4e2c Mon Sep 17 00:00:00 2001 From: Hao Wang <wanghao232(a)huawei.com> Date: Sat, 18 Jul 2020 15:43:30 +0800 Subject: [PATCH] client: fix memory leak in client msg When closing client->waitDispatch in virNetClientIOEventLoopRemoveAll or virNetClientIOEventLoopRemoveDone, VIR_FREE() is called to free call->msg directly, resulting in leak of the memory call->msg->buffer points to. Use virNetMessageFree(call->msg) instead of VIR_FREE(call->msg). Signed-off-by: Hao Wang <wanghao232(a)huawei.com> --- src/rpc/virnetclient.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c index 441f1502a6..f899493b64 100644 --- a/src/rpc/virnetclient.c +++ b/src/rpc/virnetclient.c @@ -1519,7 +1519,7 @@ static bool virNetClientIOEventLoopRemoveDone(virNetClientCallPtr call, if (call->expectReply) VIR_WARN("Got a call expecting a reply but without a waiting thread"); virCondDestroy(&call->cond); - VIR_FREE(call->msg); + virNetMessageFree(call->msg); VIR_FREE(call); } @@ -1546,7 +1546,7 @@ virNetClientIOEventLoopRemoveAll(virNetClientCallPtr call, VIR_DEBUG("Removing call %p", call); virCondDestroy(&call->cond); - VIR_FREE(call->msg); + virNetMessageFree(call->msg); VIR_FREE(call); return true; } -- 2.23.0

3 2

[RFC PATCH 0/3] qemu: Propagate cluster size to new qcow2 images
by Peter Krempa 08 Sep '20

08 Sep '20

Cluster size may have performatnce implications. Propagate the cluster size used by the original image to any copy or overlay. Peter Krempa (3): qemu: monitor: Detect image cluster size from 'query-named-block-nodes' qemu: block: Allow specifying cluster size when using 'blockdev-create' qemuBlockStorageSourceCreateDetectSize: Propagate cluster size for 'qcow2' src/qemu/qemu_block.c | 6 ++++++ src/qemu/qemu_monitor.h | 3 +++ src/qemu/qemu_monitor_json.c | 3 +++ src/util/virstoragefile.h | 1 + 4 files changed, 13 insertions(+) -- 2.26.2

2 5

[PATCH v2 00/13] resolve hangs/crashes on libvirtd shutdown
by Nikolay Shirokovskiy 07 Sep '20

07 Sep '20

I keep qemu VM event loop exiting synchronously but add code to avoid deadlock that can be caused by this approach. I guess it is worth having synchronous exiting of threads in this case to avoid crashes. Patches that are already positively reviewed has appropriate 'Reviewed-by' lines. Changes from v1: - rename stateShutdown to state stateShutdownPrepare - introduce net daemon shutdown callbacks - make some adjustments in terms of qemu per VM's event loop thread finishing - factor out net server shutdown facilities into distinct patch - increase shutdown timeout from 15s to 30s Nikolay Shirokovskiy (13): libvirt: add stateShutdownPrepare/stateShutdownWait to drivers util: always initialize priority condition util: add stop/drain functions to thread pool rpc: don't unref service ref on socket behalf twice rpc: add virNetDaemonSetShutdownCallbacks rpc: add shutdown facilities to netserver rpc: finish all threads before exiting main loop qemu: don't shutdown event thread in monitor EOF callback vireventthread: exit thread synchronously on finalize qemu: avoid deadlock in qemuDomainObjStopWorker qemu: implement driver's shutdown/shutdown wait methods rpc: cleanup virNetDaemonClose method util: remove unused virThreadPoolNew macro scripts/check-drivername.py | 2 + src/driver-state.h | 8 ++++ src/libvirt.c | 42 ++++++++++++++++ src/libvirt_internal.h | 2 + src/libvirt_private.syms | 4 ++ src/libvirt_remote.syms | 2 +- src/qemu/qemu_domain.c | 18 +++++-- src/qemu/qemu_driver.c | 32 +++++++++++++ src/qemu/qemu_process.c | 3 -- src/remote/remote_daemon.c | 6 +-- src/rpc/virnetdaemon.c | 109 ++++++++++++++++++++++++++++++++++++------ src/rpc/virnetdaemon.h | 8 +++- src/rpc/virnetserver.c | 8 ++++ src/rpc/virnetserver.h | 1 + src/rpc/virnetserverservice.c | 1 - src/util/vireventthread.c | 1 + src/util/virthreadpool.c | 65 +++++++++++++++++-------- src/util/virthreadpool.h | 6 +-- 18 files changed, 267 insertions(+), 51 deletions(-) -- 1.8.3.1

3 29

[PATCH v1 00/34] Rework building of domain's namespaces
by Michal Privoznik 03 Sep '20

03 Sep '20

There are couple of things happening in this series. The first patch fixes a bug. We are leaking /dev/mapper/control in QEMU. See the patch for detailed info. The second patch then cleans up code a bit. The third patch moves namespace handling code into a separate file. Patches 4 - 15 then prepare the code for switch to different approach in populating the namespace. Patches 16 - 26 then do the switch and finally, the rest of the patches drops and deduplicates some code. You can fetch the patches from here too: https://gitlab.com/MichalPrivoznik/libvirt/-/commits/dm_namespace/ Michal Prívozník (34): virDevMapperGetTargetsImpl: Close /dev/mapper/control in the end virDevMapperGetTargets: Don't ignore EBADF qemu: Separate out namespace handling code qemu_domain_namespace: Rename qemuDomainCreateNamespace() qemu_domain_namespace: Drop unused @cfg argument qemu_domain_namespace: Check for namespace enablement earlier qemuDomainNamespaceSetupHostdev: Create paths in one go qemuDomainAttachDeviceMknodHelper: Don't leak data->target qemu_domain_namespace.c: Rename qemuDomainAttachDeviceMknodData qemuDomainAttachDeviceMknodRecursive: Isolate bind mounted devices condition qemuDomainAttachDeviceMknodHelper: Create more files in a single go qemuDomainNamespaceMknodPaths: Create more files in one go qemuDomainNamespaceMknodPaths: Turn @paths into string list qemuDomainSetupDisk: Accept @src qemu_domain_namespace: Repurpose qemuDomainBuildNamespace() qemuDomainBuildNamespace: Populate basic /dev from daemon's namespace qemuDomainBuildNamespace: Populate disks from daemon's namespace qemuDomainBuildNamespace: Populate hostdevs from daemon's namespace qemuDomainBuildNamespace: Populate memory from daemon's namespace qemuDomainBuildNamespace: Populate chardevs from daemon's namespace qemuDomainBuildNamespace: Populate TPM from daemon's namespace qemuDomainBuildNamespace: Populate graphics from daemon's namespace qemuDomainBuildNamespace: Populate inputs from daemon's namespace qemuDomainBuildNamespace: Populate RNGs from daemon's namespace qemuDomainBuildNamespace: Populate loader from daemon's namespace qemuDomainBuildNamespace: Populate SEV from daemon's namespace qemu_domain_namespace: Drop unused functions qemuDomainDetachDeviceUnlink: Unlink paths in one go qemuDomainNamespaceUnlinkPaths: Turn @paths into string list qemuDomainNamespaceTeardownHostdev: Unlink paths in one go qemuDomainNamespaceTeardownMemory: Deduplicate code qemuDomainNamespaceTeardownChardev: Deduplicate code qemuDomainNamespaceTeardownRNG: Deduplicate code qemuDomainNamespaceTeardownInput: Deduplicate code po/POTFILES.in | 1 + src/qemu/Makefile.inc.am | 2 + src/qemu/qemu_cgroup.c | 2 +- src/qemu/qemu_conf.c | 1 + src/qemu/qemu_domain.c | 1848 +----------------------------- src/qemu/qemu_domain.h | 57 - src/qemu/qemu_domain_namespace.c | 1610 ++++++++++++++++++++++++++ src/qemu/qemu_domain_namespace.h | 86 ++ src/qemu/qemu_driver.c | 1 + src/qemu/qemu_hotplug.c | 1 + src/qemu/qemu_process.c | 23 +- src/qemu/qemu_security.c | 1 + src/util/virdevmapper.c | 4 +- 13 files changed, 1727 insertions(+), 1910 deletions(-) create mode 100644 src/qemu/qemu_domain_namespace.c create mode 100644 src/qemu/qemu_domain_namespace.h -- 2.26.2

4 74

[PATCH] rpm: Fix conditional for defining %_vpath_builddir for RHEL <= 7
by Neal Gompa 02 Sep '20

02 Sep '20

The conditional was incorrectly overriding %_vpath_builddir when %rhel is not defined, which led to surprising behavior when the global %_vpath_builddir path is set on Fedora already. Signed-off-by: Neal Gompa <ngompa13(a)gmail.com> --- libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index bb74443484..4b9e04ae61 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -32,7 +32,7 @@ %endif # On RHEL 7 and older macro _vpath_builddir is not defined. -%if 0%{?rhel} <= 7 +%if 0%{?rhel} && 0%{?rhel} <= 7 %define _vpath_builddir %{_target_platform} %endif -- 2.26.2

2 2