On CentOS:
You will need to install a few packages that are not available in the standard CentOS repository. So, you must enable the EPEL repo:
yum install epel-release -y
- Install FUSE (Filesystem in USEr space) and SSHFS packages
yum install fuse sshfs
- Load the FUSE module
modprobe fuse
- Confirm that the FUSE module is loaded
lsmod | grep fuse
fuse 84368 2
- Optionally, make sure the FUSE module is loaded upon a reboot
echo "modprobe fuse" >> /etc/rc.local
- Using SSHFS. Once the FUSE module is loaded, you can mount your remote partition using SSHFS:
sshfs user@remote_host:/remote_directory /local_mount_partition
If you have configured the login via ssh key authorization, you can use the following command:
sshfs user@remote_host:/remote_directory /local_mount_partition -o IdentityFile=<absolute-path-with-key>
Note: If appear the following error
fuse: bad mount point `/local_mount_partition': Transport endpoint is not connected
execute: sudo fusermount -u /local_mount_partition
On Ubuntu:
First you have to install FUSE and SSHFS packages with the apt-get comand:
apt-get install fuse
apt-get install sshfs
Once the FUSE module is loaded, you can mount your remote partition using SSHFS:
sshfs user@remote_host:/remote_directory /local_mount_partition
If you have configured the login via ssh key authorization, you can use the following command:
sshfs user@remote_host:/remote_directory /local_mount_partition -o IdentityFile=<absolute-path-with-key>
Note: If appear the following error
fuse: bad mount point `/local_mount_partition': Transport endpoint is not connected
execute : sudo fusermount -u /local_mount_partition
To use Docker in your virtual machine please set the MTU value at 1400 in the file /etc/docker/daemon.json. More in particular edit the file /etc/docker/daemon.json and then set
{
"mtu" : 1400
}
Instance rescue provides a mechanism for access, even if an image renders the instance inaccessible. Two rescue modes are currently provided.
If the virtual machine has encrypted LUKS VOLUMES attached, it is mandatory to detach them before starting the rescue operation. |
The steps needed to rescue an inaccessible ephemeral virtual machine on ADA Cloud are:
Step 0.
Login to the rescuer and update it. As an example, for Ubuntu virtual machines:
sudo apt update sudo apt upgrade |
Step 1.
Check that the boot of the machine has been correctly executed using the command
lsblk |
you should see the rescuer machine (/dev/vda1) mounted and the inaccessible machine on the device /dev/vdb1
Mount such device /dev/vdb1
sudo mkdir /mnt/inaccessible_vm sudo mount /dev/sdb1 /mnt/inaccessible_vm |
If the virtual machine has encrypted LUKS VOLUMES attached, it is mandatory to detach them before starting the rescue operation. |
The steps needed to rescue an inaccessible VM instantiated from a bootable volume on ADA Cloud are:
Step 0.
Shutdown the instance.
In the tab "Volumes", track which secondary volumes are attached to the VM to be rescued and detach them.
IMPORTANT: verify that the bootable volume won't be erased when deleting the VM!
Keep track of the Flavor, Security Groups and FIP associated with the VM (FIP in particular if there is a DNS association).
Delete the instance.
Step 1.
Create a throwaway VM, attach the bootable volume to rescue as a secondary volume and associate a FIP to such VM.
Login via ssh to the throwaway VM and execute all the needed operations on the volume to rescue (lsblk, fsck, xfs_repair, chroot, etc.).
Once the volume has been recovered, exit the throwaway VM and detach the secondary volume that has been rescued.
Restart the VM from the rescued bootable volume, reattaching the secondary volumes, FIP, and check the problem has been solved.
Users are able to resize autonomously their VM, but, since there is a bug in current version the OpenStack Horizon in ADA cloud, this operation can be done only via OpenStack CLI.
Before to perform the resize operation:
If there are encrypted LUKS VOLUMES attached to the virtual machine, it is mandatory that the user:
Unmount the volumes from the VM
Detach the volumes from the Openstack Dashboard
To resize a VM, it is necessary to:
Identify the VM ID:
openstack server list --all | grep <VM_name> openstack server show < vm_ID > | grep flavor |
Identify the ID of the new flavor the VM needs:
openstack flavor list |
|
Perform the resize, remembering to alert the user of the VM's temporary shutdown during the operation.
openstack server resize --flavor <new_flavor_ID> --wait <vm_ID> |
Wait then the operation to "Complete"; at the same time, on the Openstack Dashboard the message "Confirm" will appear next to the server name. Then use the command:
openstack server resize confirm <vm_ID> |
Issue the resize confirmation in a separate command, since the option |
Verify the success of the operation. Since the Dashboard can have visualization bugs, it is best to check via CLI:
openstack server show < vm_ID > | grep flavor |
Ask the user to confirm the success of the operation. To do that they will need to boot the VM, login, and verify the VCPUs number and Memory size are correct with the following commands:
cat /proc/cpuinfo free -g |