VM Best Practices
|This site replaces the former Compute Canada documentation site, and is now being managed by the Digital Research Alliance of Canada. |
Ce site remplace l'ancien site de documentation de Calcul Canada et est maintenant géré par l'Alliance de recherche numérique du Canada.
Parent page: Cloud
This page provides some guidance based on user experiences with Compute Canada's cloud instances. Your mileage may vary.
Updating packages is often a safe operation and is recommended for security reasons. Upgrading from one major version of an operating system to the next is also a good security measure, however performing a major operating system upgrade can often cause problems. Before doing any major operating system upgrades (e.g. ubuntu 20.0 to ubuntu 22.0) create a backup of your VM so that if the process fails for some reason, you will be able to recover from it.
It is very difficult to expand a root volume, so for any VM which does not have bounded storage requirements, consider creating a second volume for data. If more space is needed, and your allocation has enough remaining volume storage, it is fairly straightforward to expand the data volume using OpenStack and then to expand the logical volume, if any, and filesystem within your VM.
Maximum volumes per VM
Avoid attaching more than three volumes to a VM. This has been observed to lead to kernel timeouts which can affect any disk operations on those volumes and may have a cascading effect, and can render the VM effectively inoperative. While using a data volume is advisable in some cases (see above), use only one and you can carve it up into multiple filesystems inside your VM, and expand it as necessary.
This has been observed on Arbutus (arbutus.cloud.computecanada.ca) by multiple users, although it may be somewhat dependent on volume size. In one case, 3 x 100GB volumes attached to a p4-6gb VM caused kernel timeouts whenever disk operations of any magnitude were attempted. It was very difficult to copy more than 500MB of data between two filesystems, for example.
Test of a similar situation was performed on East cloud and with 4 x 100GB data volumes (along with the root volume), the same OS and a similar VM flavour, the issue did not occur. This VM had more memory (15 GB instead of 6 GB) but high memory usage was not observed in the Arbutus case and this isn't believed to be a factor.