offline-vm-doc: fixed links to api-reference
Related to: kubevirt-incubator/api-reference#7
@@ -12,7 +12,7 @@ both types of VMs and show its statuses.
To allow building such VM management systems on top of the KubeVirt, the
OfflineVirtualMachine is introduced to provide the access to the stopped
virtual machines. When working with running virtual machines, please see
-the [Virtual Machine object documentation](). The Virtual Machine object is
+the [VirtualMachine] object documentation. The Virtual Machine object is
designed to work in tandem with the OfflineVirtualMachine and provides the
configuration and status for running virtual machines.
@@ -100,7 +100,7 @@ get the list of all OfflineVirtualMachines or get the concrete one. **DELETE**
removes the object from etcd and all its resources. If you want to update the
existing OfflineVirtualMachine object use **PUT** and if you want to change
an item inside the object use **PATCH**.
-More details on the API are in the [documentation](https://kubevirt-incubator.github.io/api-reference/content/operations.html).
+More details on the API are in the [documentation](https://kubevirt-incubator.github.io/api-reference/master/operations.html).
To data format used when communicating with the API is the JSON. The format is
set up the usual way by setting the Content-Type header to 'application/json'.
@@ -181,12 +181,11 @@ spec:
claimName: myclaim
```
-It is easy to see that it is exactly the same as [VirtualMachine](https://kubevirt-incubator.github.io/api-reference/content/index.html),
+It is easy to see that it is exactly the same as [VirtualMachine],
but it does not have a `kind` and `apiVersion`. These are implicitely added.
Thus for the complete list of supported fields in the spec.template please refer
-to the [VirtualMachine](https://kubevirt-incubator.github.io/api-reference/content/index.html)
-documentation.
+to the [VirtualMachine] documentation.
## OfflineVirtualMachine behaviour
@@ -323,3 +322,5 @@ The controller is designed to be a standalone service running in its own pod.
Since the whole KubeVirt is designed to be modular, this approach allows for
a more flexbility and less codebase in the core. Moreover it can be scaled
up separately if the need arise.
+
+[VirtualMachine]: https://kubevirt-incubator.github.io/api-reference/master/definitions.html#_v1_virtualmachine
