New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persistent attribute isn't correctly handled #5916
Comments
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. |
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:
And an image like:
By instantiating this template as persistent, the result was a new template and a new image, with 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? |
thanks for the detailed explanation. Can you also share the oned.conf you are using in 6.4? |
In order to default to non persistent images in newly registered images, you can set the following to NO:
For clones images:
Remember to restart OpenNebula each time you modify oned.conf |
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. |
I think this could be affected by #5386 If the values For me the behavior described in the first post make sense. |
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
Looking at the comments in 5.12's oned.conf, #5386 restores what should have been the behaviour according to comments:
...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 |
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 |
Same behaviour on 6.4 too.
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. |
Hi @atodorov-storpool , |
This is fixed. Now you don't need to use the
@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 |
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. |
Just to close this off, I upgraded to 6.8.0 now and confirm the behaviour is back to what I would have expected. |
Description
I think there is a regression in how the "persistent" flag is handled, happened sometime between
6.0
and6.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 tono
. 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
Additional context
Add any other context about the problem here.
Progress Status
The text was updated successfully, but these errors were encountered: