Impossible to change VM configuration - Storage attribute

Community Support
1

Hi,

I would like to change GLUSTER_HOST parameter on already deployed VM and I’am unable to change it even in advanced VM configuration when VM is off. Parameter will rewrite to previous value if I edit it. Can someone tell me how can I change this ?

I just need to enter localhost instead node1.

36
Screen Shot 2017-08-30 at 16.43.36.png968×599 45.8 KB

Versions of the related components and OS (frontend, hypervisors, VMs):
5.0.2
Steps to reproduce:
Change disk parameter in VM advanced config.

2

with the command “onevm updateconf” you can set/edit some parameters, but to change the value you want, I’m afraid you’ll have to shutdown/delete it, adjust the template, redeploy the VM.

source: onevm(1) - manages OpenNebula virtual machines

updateconf vmid [file] Updates the configuration of a VM. The VM cannot be in an active (running) state, valid states are: pending, failure, poweroff, undeploy, hold or cloning.

This command accepts a template file or opens an editor, the full list of
configuration attributes are:

OS = [“ARCH”, “MACHINE”, “KERNEL”, “INITRD”, “BOOTLOADER”, “BOOT”]
FEATURES = [“ACPI”, “PAE”, “APIC”, “LOCALTIME”, “HYPERV”, “GUEST_AGENT”]
INPUT = [“TYPE”, “BUS”]
GRAPHICS = [“TYPE”, “LISTEN”, “PASSWD”, “KEYMAP” ]
RAW = [“DATA”, “DATA_VMX”, “TYPE”]
CONTEXT (any value, variable substitution will be made)

3

This is really bad situation. I dont mind to turn off VMs but this setting should be changeable, imagine I want to rename Gluster host, or change hostname to IP address or something like that.

Deleting VMs and redeploying them from new template and overwriting disks with old data is ridiculous. I am running production environment with more than 70 VMs. I can’t imagine doing this process with all VMs only because I am unable to change 1 exact value in deployment file.

Maybe someone else know another workround or solution ?

@VURoland do you think there is possibility to change this value somewhere in MySQL database backend ?

4

the end result is basically the same, right ?

  1. You shutdown/delete the VM
  2. Edit the template with whatever change you need
  3. Start the VM again

For the user perspective, that takes as much time as a reboot.
So using the template you basically redeploy the VM, and you can edit and prepare the template before you shutdown/delete the VM to replace it. With persistent disks nothing will change on the disk of the VM.

5

The result is not same even close. Imagine my situation. I have production environment running with many many VMs.
Steps I have to done in order to change this certain DISK attribute :

    1. shutdown VM
    1. backup disk of nonpersistent VM because after deleting nonpersistent VM disk get deleted also
    1. delete nonpersistent VM - (this step will delete VM disks also)
    1. create new VM from template (new correct DISK attribute value will be assigned from template)
    1. overwrite new VM disk with previously mentioned backuped disk
    1. boot VM with data

Rinse and repeat manually for all VMs in Opennebula Infrastructure.
There should be another workround or solution.

BR,

6

Hi,

Did you try editing the DB entries? The procedure for 5.0.2 should be:

  1. Stop opennebula service (oned must not be running)
  2. Edit the DB - find the VM row the vm_pool table and update the body entry with the relevant changes.
  3. Start opennebula service again.

The procedure could be even scripted IMO.

Then the VM XML will be updated on any VM action that is recreating the deployment.X like undeploy/deploy for example (if I am not wrong).

Best Regards,
Anton Todorov

1 Like
7

Hi,

till now I am only deciding what to do but I will probably have to go with changing DB entries.
I will try to do that. Are you sure that I have to stop oned ?

(Just asking for my own understading to know how database works in relation to oned daemon)

8

Yes because it is flushing the entries periodically and reads the relevant info only on start. I am not aware of another way to force oned to re-read from the database.

I’ve created a scripts to do disk resize on pre-5.4 that in the process is altering the DB which you can find here(resize.sh and resize.py):

Best Regards,
Anton

9

Thanks a lot for explanation, I will write here if modification of database was successful and how it was made.

10

Been thinking about this, and maybe there is another way, although I am not sure it would work for non-persistent disks. In the folder /var/lib/one/vms/(vm-id) there are the deployment files. You could edit those files with the changes you need, then use the “delete and recreate” option on a VM.
This will be just a reboot, AFAIK using those deployment.X files.

Will the “delete” of delete&recreate also delete the disk changes if it was mounted non-persistent ?

11

Yes. AFAIK it is like “reset to factory default”.

Best Regards,
Anton Todorov

12

So this is not solution because it will delete disks of non-presistent VM.

13

It is not possible with recover -> delete-recreate.

The procedure with editing the DB should work.

BR,
Anton

14

This can only be changed by editing the DB information. Since 5.4 there is
a tool (onedb change-body) to update generic values from object metadata

15

So when I will upgrade to 5.4 I will be able to change this value without custom handmade modification with SQL command ? Great.

16

Is this feature now available in the latest releases?

Can most if not all parameters be edited via the template function / screen? Would be very handy to edit all parameters after VM’s are instantiated so operations have multitude of options with which to fix various issues. At the same time, the values could be verified via the UI.

Thx,
TK