Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

        }

Rescue a Virtual Machine

Instance rescue provides a mechanism for access, even if an image renders the instance inaccessible. Two rescue modes are currently provided.

Ephemeral Virtual Machine

...

titleIMPORTANT WARNING

...

The steps needed to rescue an inaccessible ephemeral virtual machine on ADA Cloud are:

Step 0.

  • Create a rescuer virtual machine with a new key pair. Although this is not a fixed rule, it is suggested to create the rescuer machine using an image with same OS as the one on the inaccessible machine (same version or newer).
  • Login to the rescuer and update it. As an example, for Ubuntu virtual machines:

    Code Block
    languagebash
    sudo apt update
    sudo apt upgrade
  • Logout the rescuer and create a snapshot image of this virtual machine.

Step 1.

  • Select the instance you want to rescue and from the drop-down menu on the right select "rescue instance":
    • In the menu that appears, select the image you just created from the rescuer machine.
  • Login via ssh to the broken machine using the rescuer username/key 
  • Check that the boot of the machine has been correctly executed using the command

    Code Block
    languagebash
    lsblk

    you should see the rescuer machine (/dev/vda1) mounted and the inaccessible machine on the device /dev/vdb1

  • Mount such device /dev/vdb1 

    Code Block
    languagebash
    sudo mkdir /mnt/inaccessible_vm
    sudo mount /dev/sdb1 /mnt/inaccessible_vm
  • Now you can access the files in the inaccessible machine to fix the problems (lsblk, fsck, xfs_repair, chroot, etc.) or backup important data
  • Once the operation is done, logout the virtual machine and from the Dashboard select "unrescue".

Virtual Machine booted from a Bootable Volume

...

titleIMPORTANT WARNING

...

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.

...

  • To do this check, execute the command "openstack server show <id-vm-to-be-rescued>", have a look in the field "volumes_attached" and check that all the volumes listed have the property "delete_on_terminations='False' ". 
  • NB: In case you don't have access to the OpenStack CLI, please contact superc@cineca.it

...

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.

Resize a VM (a.k.a. change its flavor) 

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: 

...

  • 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:

    Code Block
    languagebash
    openstack server list --all | grep <VM_name>
    openstack server show < vm_ID > | grep flavor
  • Identify the ID of the new flavor the VM needs:

    Code Block
    languagebash
    openstack flavor list
    Warning
    • In the case of an Ephemeral VM, check the size of root disk of the original VM. Don't resize the VM if the new flavor has a disk smaller than the current one.

    • In the case of a VM with a Bootable Disk, the resize will affect only VCPUs number and RAM. The bootable disk will not be changed by the operation.

  • Perform the resize, remembering to alert the user of the VM's temporary shutdown during the operation.

    Code Block
    languagebash
    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:

    Code Block
    languagebash
    openstack server resize confirm <vm_ID>
    Warning

    Issue the resize confirmation in a separate command, since the option --confirm  on the command openstack server resize  is deprecated.

  • Verify the success of the operation. Since the Dashboard can have visualization bugs, it is best to check via CLI:

    Code Block
    languagebash
    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:

    Code Block
    languagebash
    cat /proc/cpuinfo
    free -g