I’m using the default CentOS 7 - KVM image from the MarketPlace. I have this really lame problem, but I really can’t find the culprit. On each reboot of the VM (no matter persistent or not), the root password is lost. I can see that it’s completely removed from /etc/shadow. This started happening after I re-downloaded the image about a month ago. Before that I was using the same image and didn’t have this problem, but maybe it was updated in the MarketPlace in the mean time. Maybe it’s a feature, but I’d really like to turn it off. It renders the Sunstone VNC useless since you can only login with a password in the machine and if it is in trouble during boot, then you’re toast…
My OpenNebula version is 5.4.6 if that matters.
Hello @Jacket ,
the latest version of contextualization packages, which is part of the latest Marketplace Appliances, resets the password for the contextualized user (by default
root) if no password is specified via contextualization. You have to let the contextualization to set the password, and this one will persist:
(or, via alternatives
In the next release, there will be an option to disable the password reset if no password specified:
… but it’s not possible right now.
Thank you for the answer! I just tried with CRYPTED_PASSWORD since I don’t like my password being exposed in plain text. It seems to be working on a test vm. Is there any way to update the configuration of my vms without powering them off first?
You have to power off the VMs, then you can update the configuration (context) in the OpenNebula. Unfortunately, but still better than to destroy and recreate the new VMs.
As Jacket said before, we used OpenNebula v.5.4.6.
Now we upgraded to OpenNebula v.5.4.13, but now even the CRYPTED_PASSWORD doesn’t work anymore.
We are still using CentOS 7 - KVM image from the MarketPlace.
Every time we start a VM, the root password is defaulted to the same string, although we changed it in the context section.
The methods with PASSWORD or PASSWORD_BASE64 instead of CRYPTED_PASSWORD in the context section works, but the first is in plain text and the second can be easily decoded.
Is there a way to add the root password to a template or running VMs in encrypted form?
Documentation says: “use CRYPTED_PASSWORD_BASE64 instead” .
Few minutes after I wrote this, we encoded our “CRYPTED_PASSWORD” string and I can confirm that contextualization with setting “crypted_password_base64” enabled works!