Signed-off-by: Dimitris Aragiorgis <[email protected]>
---
Hi,

this is the interdiff which includes all the latest additions
after our discussions with Guido, Vangelis and Sascha.

Once it is applied on master, I will proceed with implementation patches.

Thanks,
dimara

 doc/design-hotplug.rst |   38 +++++++++++++++++++++++++++++++++-----
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/doc/design-hotplug.rst b/doc/design-hotplug.rst
index ff4ff95..75dc928 100644
--- a/doc/design-hotplug.rst
+++ b/doc/design-hotplug.rst
@@ -7,7 +7,9 @@ Hotplug
 This is a design document detailing the implementation of device
 hotplugging in Ganeti. The logic used is hypervisor agnostic but still
 the initial implementation will target the KVM hypervisor. The
-implementation adds ``python-fdsend`` as a new dependency.
+implementation adds ``python-fdsend`` as a new dependency. In case
+it is not installed hotplug will not be possible and the user will
+be notified with a warning.
 
 
 Current state and shortcomings
@@ -70,8 +72,8 @@ Design decisions
 Which should be each device ID? Currently KVM does not support arbitrary
 IDs for devices; supported are only names starting with a letter, max 32
 chars length, and only including '.' '_' '-' special chars.
-We use the device pci slot and name it after <device type>-pci-<slot>
-(for debugging purposes we could add a part of uuid as well).
+For debugging purposes and in order to be more informative, device will be
+named after: <device type>-<part of uuid>-pci-<slot>.
 
 Who decides where to hotplug each device? As long as this is a
 hypervisor specific matter, there is no point for the master node to
@@ -185,7 +187,7 @@ all other hypervisors, backend will raise an Exception case 
hotplug is
 requested.
 
 
-NIC hotplug
+NIC Hotplug
 +++++++++++
 
 The user can add/modify/remove NICs either with hotplugging or not. If a
@@ -203,7 +205,7 @@ well.
  gnt-instance modify --net 1:remove --hotplug test
 
 
-Disk hotplug
+Disk Hotplug
 ++++++++++++
 
 The user can add and remove disks with hotplugging or not. QEMU monitor
@@ -215,6 +217,32 @@ support only disk addition/deletion.
  gnt-instance modify --disk add:size=1G --hotplug test
  gnt-instance modify --net 1:remove --hotplug test
 
+
+Dealing with chroot and uid pool
+--------------------------------
+
+The design so far covers all issues that arise without addressing the
+case where the kvm process will not run with root privileges.
+Specifically:
+
+- in case of chroot, the kvm process cannot see the newly created device
+
+- in case of uid pool security model, the kvm process is not allowed
+  to access the device
+
+For NIC hotplug we address this problem by using the ``getfd`` monitor
+command and passing the file descriptor to the kvm process over the
+monitor socket using SCM_RIGHTS. For disk hotplug and in case of uid
+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
+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
+model and notify the user with the corresponding warning.
+
 .. vim: set textwidth=72 :
 .. Local Variables:
 .. mode: rst
-- 
1.7.10.4

Attachment: signature.asc
Description: Digital signature

Reply via email to