diff --git a/doc/content/xen-api/overview/index.md b/doc/content/xen-api/overview/index.md
index 042ef6088b..4f0b60d845 100644
--- a/doc/content/xen-api/overview/index.md
+++ b/doc/content/xen-api/overview/index.md
@@ -40,14 +40,34 @@ The next step is to query the list of "templates" on the host. Templates are spe
 
 Now that we have a snapshot of all the VM objects' field values in the memory of our client application we can simply iterate through them and find the ones that have their "`is_a_template`" set to true. At this stage let's assume that our example application further iterates through the template objects and remembers the reference corresponding to the one that has its "`name_label`" set to "Debian Etch 4.0" (one of the default Linux templates supplied with XenServer).
 
+### Choosing a Storage Repository for the VM's disks
+
+As mentioned above, templates generally embody software stored on
+virtual disk images. Creating a VM from a template thus involves, in
+particular, creating copies of the templates' disk images that will be
+available for the VM to use.
+
+These copies need to be stored somewhere and, in Xen-API
+terminology, a place where **Virtual Disk Images** (VDIs) are stored is
+called a **Storage Repository**.
+
+Just as we had to list templates in order to choose one to use as a basis
+for the VM, we need to list the available Storage Repositories and
+pick one. We do so by calling `SR.get_all_records(session)`.
+
+Let's assume this call returns a non-empty list of Storage
+Repositories and choose one of them, whose reference is stored in
+`my_sr_ref`. This reference will be used in the next step when
+specifying where to store the VM's VDIs by default.
+
 ### Installing the VM based on a template
 
 Continuing through our example, we must now install a new VM based on the template we selected. The installation process requires 4 API calls:
 
 -   First we must now invoke the API call `VM.clone(session, t_ref, "my first VM")`. This tells the server to clone the VM object referenced by `t_ref` in order to make a new VM object. The return value of this call is the VM reference corresponding to the newly-created VM. Let's call this `new_vm_ref`.
 
--   Next, we need to specify the UUID of the Storage Repository where the VM's
-    disks will be instantiated. We have to put this in the `sr` attribute in
+-   Next, we need to specify where the VM's disks will be stored by
+    default. We do so by putting `my_sr_ref` in the `sr` attribute in
     the disk provisioning XML stored under the "`disks`" key in the
     `other_config` map of the newly-created VM. This field can be updated by
     calling its getter (`other_config <- VM.get_other_config(session,
@@ -94,6 +114,8 @@ We have seen how the API can be used to install a VM from a XenServer template a
 
 -   One call to query the VM (and template) objects present on the XenServer installation: `VM.get_all_records()`. Recall that we used the information returned from this call to select a suitable template to install from.
 
+-   One call to list the Storage Repositories: `SR.get_all_records()`.
+
 -   Four calls to install a VM from our chosen template: `VM.clone()`, followed
     by the getter and setter of the `other_config` field to specify where to
     create the disk images of the template, and then `VM.provision()`.