..and raise HotplugError inside VerifyHotplugSupport(). This way disk hot-add is not supported only if chroot or user/pool security model is used AND QMP does not support add-fd command (QEMU versions < 1.7) OR fdsend python module is missing.
Signed-off-by: Dimitris Aragiorgis <[email protected]> --- doc/design-hotplug.rst | 2 +- lib/hypervisor/hv_kvm/__init__.py | 10 +++++++--- man/gnt-instance.rst | 13 +++++++------ 3 files changed, 15 insertions(+), 10 deletions(-) diff --git a/doc/design-hotplug.rst b/doc/design-hotplug.rst index 1a52229..45f0862 100644 --- a/doc/design-hotplug.rst +++ b/doc/design-hotplug.rst @@ -239,7 +239,7 @@ pool we can let the hypervisor code temporarily ``chown()`` the device before the actual hotplug. Still this is insufficient in case of chroot. In this case, we need to ``mknod()`` the device inside the chroot. Both workarounds can be avoided, if we make use of the ``add-fd`` qemu -monitor command, that was introduced in version 1.3. This command is the +monitor command, that was introduced in version 1.7. This command is the equivalent of NICs' `get-fd`` for disks and will allow disk hotplug in every case. So, if the qemu monitor does not support the ``add-fd`` command, we will not allow disk hotplug for chroot and uid security diff --git a/lib/hypervisor/hv_kvm/__init__.py b/lib/hypervisor/hv_kvm/__init__.py index f639809..e6620e0 100644 --- a/lib/hypervisor/hv_kvm/__init__.py +++ b/lib/hypervisor/hv_kvm/__init__.py @@ -1844,17 +1844,21 @@ class KVMHypervisor(hv_base.BaseHypervisor): """Verifies that hotplug is supported. Hotplug is *not* supported in case of: - - security models and chroot (disk hotplug) - - fdsend module is missing (nic hot-add) + - fdsend module is missing (hot-add) + - add-fd qmp command is not supported and + chroot or some security model is used @raise errors.HypervisorError: in one of the previous cases """ + with QmpConnection(self._InstanceQmpMonitor(instance.name)) as qmp: + qmp_supports_add_fd = fdsend and "add-fd" in qmp.supported_commands + if dev_type == constants.HOTPLUG_TARGET_DISK: hvp = instance.hvparams security_model = hvp[constants.HV_SECURITY_MODEL] use_chroot = hvp[constants.HV_KVM_USE_CHROOT] - if action == constants.HOTPLUG_ACTION_ADD: + if action == constants.HOTPLUG_ACTION_ADD and not qmp_supports_add_fd: if use_chroot: raise errors.HotplugError("Disk hotplug is not supported" " in case of chroot.") diff --git a/man/gnt-instance.rst b/man/gnt-instance.rst index 96e2cee..181dc97 100644 --- a/man/gnt-instance.rst +++ b/man/gnt-instance.rst @@ -1376,12 +1376,13 @@ during this operation are ignored. If ``--hotplug`` is given any disk and NIC modifications will take effect without the need of actual reboot. Please note that this feature is currently supported only for KVM hypervisor and there are some -restrictions: a) KVM versions >= 1.0 support it b) instances with chroot -or uid pool security model do not support disk hotplug c) RBD disks with -userspace access mode can not be hotplugged (yet) d) if hotplug fails -(for any reason) a warning is printed but execution is continued e) -for existing NIC modification interactive verification is needed unless -``--force`` option is passed. +restrictions: a) NIC/Disk hot-remove should work for QEMU versions >= 1.0 +b) instances with chroot or pool/user security model support disk +hot-add only for QEMU version > 1.7 where add-fd QMP command exists c) For +the previous case as well as for NIC hot-add, python-fdsend package must +be installed d) if hotplug fails (for any reason) a warning is printed +but execution is continued e) for existing NIC modification interactive +verification is needed unless ``--force`` option is passed. If ``--hotplug-if-possible`` is given then ganeti won't abort in case hotplug is not supported. It will continue execution and modification -- 1.7.10.4
