Description of problem:
After setting customer properties for pools, after clicking to OK button, it does not save the configuration.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Create a pool of RHEL vdi's on which we need to set a custom property for framebuffer size so that the VM's can support high resolution screens, dual and quad setups. Whenever we set a custom property, it appears to save OK, but after closing the settings window, nothing is saved and if reopening the settings window the option is gone.
Settings not saved.
settings must be saved.
For me it looks like an UI issue that when loading the edit pool dialog, this value is not shown in the dialog.
Other than that, the custom properties seem to be set. You could check it by going to the Virtual Machines main tab and check any VM which belongs to the pool if they have the custom properties.
Please note that the custom properties (same as nearly any other pool properties) can be set only during pool creation and can not be updated.
If it does not work, a possible workaround is to set the custom properties up on the template you want to base your pool on, so the pool will inherit them.
Is it possible to have this be fixed in 3.5 too?
well, there are no more oVirt 3.5.z planned...
Is the behavior as described in comment 2? e.g. if you go to the VMs list and pick one of the VMs from the pool and click "edit", you can see the actual "custom properties" correctly set?
When I edit one of the vms in the pool I cannot see the property set, and I cannot add it either.
I also attempted to add it to the template, but it did not save to the template. I believe the template was created on ver 3.4.5 though.
When I created and increased the pool size I made sure to add it in the edit pool dialog. The property was then set on each vm.
However we had maintenance last weekend where I edited the pool to set the number of pre-running vms to 0 to allow them to stay down during the maintenance, and this removed the custom property from all the vms.
On 3.5.5 the problem seems to be slightly different - the edit pool dialog always takes the values for the custom properties from the template on which this pool is based on.
There is a simple workaround which worked for me which is setting the custom properties on the template. This way the edit pool dialog always picks them up.
If the setting of the custom properties does not work for you on a template, you could try to do it using REST API.
Did this work for you?
I see the custom property set when I edit the pool after adding the custom property to the template in 3.5.5. However it does not populate to the existing VMs in the pool. I also tried editing the pool, making sure the custom property was set in the pool properties, and saving the pool. The VMs in the pool does not get updated adding the custom property.
Even though it managed to remove the custom property on the existing VMs when I edited and saved the pool without having the custom property in the template. I have also tried to shut down a VM after I added the custom property to the template and the pool, however the custom property is never populated back into the existing VMs.
I did try adding the custom property on the template earlier on 3.4.5, but the custom properties on the template did not save. In fact, the custom property was set on the source VM where the template was created from, however they we're not included in the template, and I could not save then if I edited the template either.
So how can I re-apply the custom property to the existing VMs in the pool on 3.5.5?
@Sigbjorn: Im afraid that in 3.5 no nice way. Only thing I can think of is to hack them directly into the database (table: vm_static, columns: userdefined_properties, predefined_properties)
You can set up this properties to some temporary VM to see how you want this two fields to look like and than copy them to the VMs belonging to the pool...
(In reply to Tomas Jelinek from comment #11)
> @Sigbjorn: Im afraid that in 3.5 no nice way. Only thing I can think of is
> to hack them directly into the database (table: vm_static, columns:
> userdefined_properties, predefined_properties)
> You can set up this properties to some temporary VM to see how you want this
> two fields to look like and than copy them to the VMs belonging to the
Thank you for the suggestion. I'm not too keen on hacking the database directly in a production environment. We will wait for a fix in 3.6 and use other workarounds until then.
Verified with rhevm-3.6.2-0.1.el6.noarch
1. Add custom properties on vm pool creation. Result - properties are saved and appear in the edit pool menu and on each of the pool's vm menu as expected.
2. Create a vm pool based on a template with custom properties. - same result.
3. Edit vm pool -> change template to a template with custom properties - same result.
Behaviour is as expected.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.