[FIXED] Volatile SWAP disk not initialized in 5.0.2

Community Support
1

Hello,

some of my VM templates have a second volatile disk of type swap. This used to work in 4.14 - the Linux contextualization package recognized the swap disk on a newly deployed machine and enabled swapping on it. I have discovered that it does not work anymore on my ONe 5.0.2, but I can’t tell when exactly it stopped working: maybe after upgrade to 5.x, maybe after moving the system datastore to CEPH, I don’t know. The problem is that the volatile disk is created and attached, but one-context-linux (/etc/one-context.d/04-mount-swap) does not enable it. 04-mount-swap calls blkid -t TYPE=swap -o device, which does not return anything. I tried to run

dd if=/dev/vdb count=4 | hexdump

and got all-zeros. So this means the volatile disk is not properly initialized. After running mkswap /dev/vdb from the inside of the VM, the volatile disk is correctly recognized and activated as swap during next reboot. After the undeploy/deploy cycle, the initialization is lost again.

I am not sure whether the volatile disk should be mkswapped by ONe, or labeled as swap in context.sh, but my context.sh does not contain anything remotely related to this volatile disk except maybe the DISK_ID='2' variable.

FWIW, the related part from the template is this:

DISK = [
  DEV_PREFIX = "vd",
  SIZE = "2048",
  TYPE = "swap" ]

I run ONe 5.0.2 with the variable quotation patch mentioned here: Incorrect attribute quotation (works in 4.14, broken in 5.0) , my system datastore is of type CEPH.

Do volatile swap disks work for you in ONe 5? Thanks,

-Yenya

2

Hi,

Most probably the mkswap command is failing in /var/lib/one/remotes/tm/ceph/mkimage.

Kind Regards,
Anton Todorov

3

Anton, you were right!

The reason is the missing entry for mkswap in /etc/sudoers.d/opennebula. This is probably not needed in non-CEPH datastores, because the volatile image there is an ordinary file created by oneadmin user. Under CEPH, the image is created by rbd(8) command, then mapped to a (root-owned) block device, and mkswap(8) is run on top of that device. Maybe the process of initializing a RBD image should be modified so that it does not need to map the RBD volume to the block device (after all qemu does not need it as well and accesses the volume directly).

I have created the following issue in the bug tracker (a simple patch is attached there):
http://dev.opennebula.org/issues/4870

-Yenya

1 Like
4

Hi Yenya,

Actually you forced me to check our addon driver against 5.2 beta and I fixed a bug there too :slight_smile:.

Kind Regards,
Anton Todorov

5

Anyway, I wonder where the stderr of failing sudo or failing mkswap gets lost, because it is not visible in the VM log file.

-Yenya