Persistent attribute isn't correctly handled

[gbonfiglio]

/!\ To report a security issue please follow this procedure: [https://github.com/OpenNebula/one/wiki/Vulnerability-Management-Process]

Description I think there is a regression in how the "persistent" flag is handled, happened sometime between 6.0 and 6.4.

To Reproduce I have an image + template named "Debian TPL" which I use to spin up my Debian instances. On this image the flag persistent is set to no. Before 6.4, when instantiating a VM from this template this was the result: a - if in "Instantiate" tab persistent flag = yes -> end result is a copy of the image, with the persistent flag set at "yes" b - if in "Instantiate" tab persistent flag = no -> end result is a VM pulling from original image with persistent flag set to "no"

In 6.4, with the image "Debian TPL" still having persistent=no, on instantiate this is what I get: 1a - on Instantiate, persistent = no -> VM uses the image of Debian TPL itself, non persistent 1b - on Instantiate, persistent = yes -> VM clones the image, but on the new image the persistent flag is still "no" -> data loss on shutdown

I though the solution was to set persistent=yes in the image used for the main template, but this has downsides too: 2a - on Instantiate, persistent = no -> VM uses the image of Debian TPL itself, in persistent mode 2b - on Instantiate, persistent = yes -> VM clones the image, on the new image persistent=yes

Expected behavior [see above]

Details

• Affected Component: Scheduler
• Hypervisor: KVM
• Version: 6.4

Additional context Add any other context about the problem here.

Progress Status

• [ ] Code committed
• [ ] Testing - QA
• [ ] Documentation (Release notes - resolved issues, compatibility, known issues)

[tinova]

have you checked the default image persistent flag?

https://github.com/OpenNebula/one/blob/master/share/etc/oned.conf#L361

closing as not sure what the wrong behaviour is, will reopen when that's clear.

[gbonfiglio]

Maybe let's start from use cases: as an user I want to have a single template for a given operating system and being able to instantiate it both in persistent and ephemeral options.

For persistent, I expect the template to be cloned along with the images. Images should be thus flagged as "persistent". For ephemeral, I expect VMs to be spinned up from this template with ephemeral volumes.

In previous versions (I said the regression happened after 6.0 but now I've found a misconfigured VM created while the host was on 6.0), I was using a template such as:

TEMPLATE 82 INFORMATION                                                         
ID             : 82                  
NAME           : TPL - Debian 11     
USER           : oneadmin            
GROUP          : oneadmin            
LOCK           : None                
REGISTER TIME  : 07/13 09:47:06      

PERMISSIONS                                                                     
OWNER          : um-                 
GROUP          : ---                 
OTHER          : ---                 

TEMPLATE CONTENTS                                                               
CONTEXT=[
  NETWORK="YES",
  SSH_PUBLIC_KEY="$USER[SSH_PUBLIC_KEY]" ]
CPU="1"
CPU_MODEL=[
  MODEL="host-passthrough" ]
DISK=[
  IMAGE_ID="126" ]
GRAPHICS=[
  LISTEN="127.0.0.1",
  TYPE="VNC" ]
HYPERVISOR="kvm"
INPUTS_ORDER=""
LOGO="images/logos/debian.png"
MEMORY="1024"
MEMORY_UNIT_COST="MB"
OS=[
  ARCH="x86_64",
  BOOT="" ]
VCPU="2"

And an image like:

IMAGE 126 INFORMATION                                                           
ID             : 126                 
NAME           : TPL - Debian 11     
USER           : oneadmin            
GROUP          : oneadmin            
LOCK           : None                
DATASTORE      : templates           
TYPE           : OS                  
REGISTER TIME  : 07/13 09:47:06      
PERSISTENT     : No                 
SOURCE         : /var/lib/one/datastores/103/18cf8240e76923d64c39d891dde8ad48
PATH           : https://marketplace.opennebula.io/appliance/8e015603-3dc2-4147-a25e-f58dced23e52/download/0
FORMAT         : qcow2               
SIZE           : 2G                  
STATE          : rdy                 
RUNNING_VMS    : 0                   

PERMISSIONS                                                                     
OWNER          : um-                 
GROUP          : ---                 
OTHER          : ---                 

IMAGE TEMPLATE                                                                  
DEV_PREFIX="vd"
FROM_APP="286"
FROM_APP_MD5="18b3d13191d65b939bfd7d5af94ab949"
FROM_APP_NAME="Debian 11"

By instantiating this template as persistent, the result was a new template and a new image, with PERSISTENT : Yes. By istantiating it as non persistent, the result was an instance with the template image mounted as non persistent.

Now, the behaviour changed and it seems whatever is the value for the "persistent" attribute in the template image will be carried over. So by creating a "persistent" VM from the image/tpl above, I get as a result an instance with "non persistent" storage.

Am I getting something wrong?

[tinova]

thanks for the detailed explanation.

Can you also share the oned.conf you are using in 6.4?

[gbonfiglio]

Here you are: https://gist.github.com/gbonfiglio/f00594097a8d2b4245bdad27f186aa37

[tinova]

In order to default to non persistent images in newly registered images, you can set the following to NO:

DEFAULT_IMAGE_PERSISTENT_NEW = "NO"

For clones images:

DEFAULT_IMAGE_PERSISTENT = "NO"

Remember to restart OpenNebula each time you modify oned.conf

[gbonfiglio]

This is the first thing I checked, since the name rang a bell. I luckily had the configuration backups, and this value was not changed between 5.12 (where things were working as intended) and 6.4 (where things don't).

Did something else change? Ie the default applied? This value has always been commented out in my config.

[paczerny]

I think this could be affected by #5386

If the values DEFAULT_IMAGE_PERSISTENT_NEW and DEFAULT_IMAGE_PERSISTENT are commented out, the new image inherits the persistence flag from the original image.

For me the behavior described in the first post make sense.

[gbonfiglio]

Yes! Thanks for spotting it @paczerny, that seems to be what I believe is a regression. This inheritance makes it impossible to have the distinct behaviours required when instantiating persistent and non persistent VMs - assume to have a template with persistent = no:

• Non Persistent Launch: image from template with persistent = no is used
• Persistent Launch: image is cloned from template and the new one is set persistent = yes

Looking at the comments in 5.12's oned.conf, #5386 restores what should have been the behaviour according to comments:

#  DEFAULT_IMAGE_PERSISTENT: Control the default value for the PERSISTENT
#  attribute on image creation (oneimage clone, onevm disk-saveas). If blank
#  images will inherit the persistent attribute from the base image.
#
#  DEFAULT_IMAGE_PERSISTENT_NEW: Control the default value for the PERSISTENT
#  attribute on image creation (oneimage create). By default images are no
#  persistent if not set.

...but it breaks the fairly important use case of directly instantiating persistent and non persistent VMs without having to go back and change the flags manually.

If a decision is taken not to revert #5386, at least the change in behaviour should be documented. I guess the solution to my issue is to set DEFAULT_IMAGE_PERSISTENT = "YES", since instantiating persistent involves a clone?

[feldsam]

Hello, I can confirm this problem. But there is another related. I am on 6.2 version and when I use instantiate as persistent, oned creates new image using datastore/clone, but wrongly calls tm/clone instead of tm/ln. I think, it is because CLONE=YES in VM template.

[atodorov-storpool]

Same behaviour on 6.4 too. The description of the "Instantiate as persistent" slider is as follow:

Creates a private persistent copy of the template plus any image defined in DISK, and instantiates that copy

The actual action is "Instantiate from copy": "Create a copy of the template plus any image defined in DISK, and instantiates that copy".

What is observed: if the VM template has non-persistent image defined it is copying the image in the datastore (datastore//clone) and then instantiates a VM using this template. And because the image is a copy of the primary image, the resulting VM disk is non-persistent, too (so tm//clone was called).

So, IMHO, either the text or the hint is misleading as there is no peristence at all - it is just cloning. Or, there is an issue/bug?/ in the applied logic.

[feldsam]

Hi @atodorov-storpool , DEFAULT_IMAGE_PERSISTENT = "YES" helps. But if there is disk SIZE parameter defined in template, it is ends with error. Looks like there should be post-copy adjustment in src/rm/RequestManagerVMTemplate.cc after line 97. We can set there PERSISTENT = YES on all images and we can remove DISK SIZE from VM template also.

[paczerny]

PRs:

• src
• tests

[paczerny]

1b - on Instantiate, persistent = yes -> VM clones the image, but on the new image the persistent flag is still "no" -> data loss on shutdown

This is fixed.

Now you don't need to use the DEFAULT_IMAGE_PERSISTENT = "YES" , the disk in the instantiated VM has attributes PERSISTENT=YES, CLONE=NO. So I think it should solve also issues with driver action clone/ln.

But if there is disk SIZE parameter defined in template

@feldsam Usually you don't have a disk SIZE in the template, how did you get the disk SIZE there? Manually or it was a result of some onevm save or onetemplate clone action? Maybe I'm missing some use case?

[feldsam]

Hello @paczerny, I added SIZE attr to template manually, because some images from app market are only 2GB and I want to have minimum 10GB. It works fine when running non persistent images, but would be fine, if I can run as persistent and either instantiate with it with original image size or better to change size automaticaly.

[gbonfiglio]

Just to close this off, I upgraded to 6.8.0 now and confirm the behaviour is back to what I would have expected.