[libvirt] [PATCH 2/2] qemuDomainChangeNet: Forbid changing MTU

Laine Stump laine at laine.org
Thu Jun 8 14:43:13 UTC 2017


On 06/08/2017 07:50 AM, Michal Privoznik wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1447618
> 
> Currently, any attempt to change MTU on an interface that is
> plugged to a running domain is silently ignored. We should either
> do what's asked or error out. Well, we can update the host side
> of the interface, but we cannot change 'host_mtu' attribute for
> the virtio-net device. Therefore we have to error out.

Interesting conundrum. There's nothing to stop a user from intervening
directly in the guest and changing the guest's MTU from there. So if we
allowed changing the mtu of the tap device this way, at least it would
be *possible* to modify the MTU of an active interface. But if we did
that, then behavior would be inconsistent between startup/hotplug time
and runtime.

So for now at least, ACK. Better to not allow something than to have it
behave inconsistently.


> 
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>

Reviewed-by: Laine Stump <laine at laine.org>

> ---
>  src/qemu/qemu_hotplug.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
> index 8066acae3..d46956d98 100644
> --- a/src/qemu/qemu_hotplug.c
> +++ b/src/qemu/qemu_hotplug.c
> @@ -3138,6 +3138,12 @@ qemuDomainChangeNet(virQEMUDriverPtr driver,
>      /* vlan can be modified, and will be checked later */
>      /* linkstate can be modified */
>  
> +    if (olddev->mtu != newdev->mtu) {
> +        virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
> +                       _("cannot modify MTU"));
> +        goto cleanup;
> +    }
> +
>      /* allocate new actual device to compare to old - we will need to
>       * free it if we fail for any reason
>       */
> 




More information about the libvir-list mailing list