diff --git a/source/administration/sharding.txt b/source/administration/sharding.txt
index 0430b686de0..b4d32b34f03 100644
--- a/source/administration/sharding.txt
+++ b/source/administration/sharding.txt
@@ -548,7 +548,17 @@ However, you may want to migrate chunks manually in a few cases:
 - If the balancer in an active cluster cannot distribute chunks within
   the balancing window, then you will have to migrate chunks manually.
 
-To migrate chunks, use the :dbcommand:`moveChunk` command.
+To migrate chunks, use the :dbcommand:`moveChunk` command. 
+
+.. note::
+
+   To return a list of shards, use the :dbcommand:`listshards`
+   command.
+
+   Specify shard names using the :dbcommand:`addShard` command
+   using the ``name`` argument. If you do not specify a name in the
+   :dbcommand:`addShard` command, MongoDB will assign a name
+   automatically.
 
 The following example assumes that the field ``username`` is the
 :term:`shard key` for a collection named ``users`` in the ``myapp``
@@ -572,15 +582,17 @@ block until the migration is complete.
    :term:`secondary` members have replicated operations before allowing
    new chunk migrations.
 
-.. note::
+.. warning::
 
-   To return a list of shards, use the :dbcommand:`listshards`
-   command.
+   The :dbcommand:`moveChunk` command may produce an error message:
 
-   Specify shard names using the :dbcommand:`addShard` command
-   using the ``name`` argument. If you do not specify a name in the
-   :dbcommand:`addShard` command, MongoDB will assign a name
-   automatically.
+   .. code-block:: none
+
+      The collection's metadata lock is already taken.
+
+   when there are open :term:`cursors <cursor>` accessing the chunk to
+   be moved. To fix this situation, either wait until the cursors
+   complete their operation or remove the cursors.
 
 .. index:: balancing; operations
 .. _sharding-balancing-operations:
diff --git a/source/faq/sharding.txt b/source/faq/sharding.txt
index 0d9b35db7c6..19824ce8353 100644
--- a/source/faq/sharding.txt
+++ b/source/faq/sharding.txt
@@ -331,3 +331,15 @@ the hash of a key with an ascending value. While you can compute a
 hashed value in your application and include this value in your
 documents for use as a shard key, the :issue:`SERVER-2001` issue will
 implement this capability within MongoDB.
+
+What does "ERROR: moveChunk commit failed: version is at X|Y instead of A|B" and "ERROR: TERMINATING" mean? What happened?
+--------------------------------------------------------------------------------------------------------------------------
+
+During a :ref:`chunk migration <sharding-chunk-migration>`, the
+:term:`shard` could not connect to the :term:`config database` to update
+chunk information. If the shard cannot update the config database
+after :dbcommand:`moveChunk`, the shard cluster will have an
+inconsistent view of all chunks. For this situation, the shard will
+terminate itself to prevent data inconsistency and produce this error.
+
+Please contact MongoDB support directly for help in resolving this situation.
diff --git a/source/reference/glossary.txt b/source/reference/glossary.txt
index df5884570f4..826ab9a6f8c 100644
--- a/source/reference/glossary.txt
+++ b/source/reference/glossary.txt
@@ -836,3 +836,9 @@ Glossary
       availability, and partition tolerance, a distributed computing
       system can provide any two of these features, but never all
       three.
+
+   cursor
+      In MongoDB, a cursor is a pointer to the result set of a
+      :term:`query`, that can be iterated through to retrieve
+      results. By default, cursors will timeout after 10 minutes of
+      inactivity.