Bug 1496366

Created attachment 1331339 [details]
engine log

Same for case where memory size is not correct like: 3433

(In reply to Israel Pinto from comment #0)
> Created attachment 1331338 [details]
> memory_size screenshot
> 
> Description of problem:
> The Memory size in edit vm dialog is not updated after failing hotplug the
> 17th device.
> Hotplug memory with 16 devices to check hotplug limitation 
> it failed to hot plug 17 device which is as expected.
> But the memory size text box is not reporting the correct memory size
> (define memory in general tab), It still with the total memory size with the
> 17th device.
> The unplug on the memory is not updating the size also. 
> 
> 
> Version-Release number of selected component (if applicable):
> Software version:4.2.0-0.0.master.20170917124606.gita804ef7.el7.centos
> 
> 
> Steps to Reproduce:
> 1. Create VM run it 
> 2. hot plug memory device 16 times
> 3. hot plug the 17th device - should failed to hot plug
> Error message:
> Failed to hot set memory to VM VM_with_UI. Underlying error message: Cannot
> hot set memory VM. Exceeded maximum number of available memory slots: 16.
> 4. Check that the memory size in edit dialog is update back to current memory

the memory size shows the "next run" part, not the current one. So this part is correct.

> 5. Check that with hot unplug memory is updating the size also.

this looks like a bug, @Jakub?

> 
> Actual results:
> The memory size is not updated
> 
> Expected results:
> 1. The memory size updated to current size after failing adding the 17th
> device
> 2. The memory size updated to unplug size

It's semi-expected behavior. There is a logic [1] saying that if during the memory hot unplug operation value of next-run memory is not equal current memory, the next-run memory is not updated. The idea behind is that if user tweaks the next-run memory separately, he/she probably does that intentionally and we don't want to overwrite such value.

The problem is that during hot plug of 17. dimm hot plug itself fails but UpdateVmCommand as whole does not (intentionally, Arik knows details). This causes that next-run memory and running memory goes out of sync and consequently next-run memory is not updated during hot unplugs.

If user manually put these values to sync, i.e. decrements value of memory in edit vm dialog to size shown at "General" VM tab, then next-run memory value is again being updated during hot unplugs.

[1]: https://github.com/oVirt/ovirt-engine/blob/7cd4715e415f6ef37e9c6126c59a88c60f3965d9/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/HotUnplugMemoryCommand.java#L169

this is an expected behavior, turning it into doc bug - this unplug behavior should be documented.

Hi Israel, Tomas,

Thank you for raising and providing some more detail about this bug.

I will move this over to the RHV documentation queue where it can be addressed in the documentation there.

Assigning to Tahlia for review.

Tahlia - a summary of the issue can be found in the 'doc text' field.

Kind regards,

Andrew

Just to confirm, does this occur in 4.1 as well, or just 4.2?

It reproduce also in 4.1, checked with version: 4.1.7.3-0.1.el7

> > 3. hot plug the 17th device - should failed to hot plug
> > Error message:
> > Failed to hot set memory to VM VM_with_UI. Underlying error message: Cannot
> > hot set memory VM. Exceeded maximum number of available memory slots: 16.
> > 4. Check that the memory size in edit dialog is update back to current memory
> 
> the memory size shows the "next run" part, not the current one. So this part
> is correct.

Does this mean that even though the 17th hot plug fails, the memory increase will still be applied when the VM is restarted? 
If so, that seems worth documenting also. 
(For reference, here's the current hot plug doc: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/virtual_machine_management_guide/hot_plugging_virtual_memory)

AFAIK, memory hot unplug is still unsupported for 4.1, so the unplug behaviour only applies to 4.2, right? 

So, that makes my action items: 

* 4.1: Add a note about the next run behaviour after the 17th hot plug fails.
* 4.2: Add a note about the next run behaviour after the 17th hot plug fails, and include the hot unplug behaviour as well. 

Have I got that right?

(In reply to Tahlia Richardson from comment #11)
> > > 3. hot plug the 17th device - should failed to hot plug
> > > Error message:
> > > Failed to hot set memory to VM VM_with_UI. Underlying error message: Cannot
> > > hot set memory VM. Exceeded maximum number of available memory slots: 16.
> > > 4. Check that the memory size in edit dialog is update back to current memory
> > 
> > the memory size shows the "next run" part, not the current one. So this part
> > is correct.
> 
> Does this mean that even though the 17th hot plug fails, the memory increase
> will still be applied when the VM is restarted? 

yes, correct

> If so, that seems worth documenting also. 
> (For reference, here's the current hot plug doc:
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/
> html/virtual_machine_management_guide/hot_plugging_virtual_memory)
> 
> AFAIK, memory hot unplug is still unsupported for 4.1, so the unplug
> behaviour only applies to 4.2, right? 

yes

> 
> So, that makes my action items: 
> 
> * 4.1: Add a note about the next run behaviour after the 17th hot plug fails.

maybe not mentioning the 17 as a number. Just mention, that if the hotplug fails for example due to running out of available slots.

> * 4.2: Add a note about the next run behaviour after the 17th hot plug
> fails, and include the hot unplug behaviour as well. 

yes. But, it is not only if the hotplug fails. It is, if the amount of memory the current VM has differs from the amount scheduled for next run, the unplug does not change the next run. You can get to this state either by the failure to hotplug, or, by deliberately changing the VM memory and choosing to "apply it later".

> 
> Have I got that right?

I'll use this bug to make the update for 4.1. Hot unplug isn't documented yet (still in the planning phase for 4.2 docs), so I'll add the info about unplug to the docs bug for the hot unplug feature (BZ#1502671).

Hi Tomas,
This came up on another bug, so I'd like to clarify here: 
Will the pending (next run) changes be applied on reboot (from inside the VM), or only on restart (from the Admin/User Portal or API)?

only from outside (e.g. pressing the reboot button in webadmin or doing the corresponding action from REST API).

The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

(In reply to Tomas Jelinek from comment #16)
> only from outside (e.g. pressing the reboot button in webadmin or doing the
> corresponding action from REST API).

Im sorry, I have been pointed out that also the reboot from inside of the guest will apply the next run snapshot.

(In reply to Tomas Jelinek from comment #18)
> (In reply to Tomas Jelinek from comment #16)
> > only from outside (e.g. pressing the reboot button in webadmin or doing the
> > corresponding action from REST API).
> 
> Im sorry, I have been pointed out that also the reboot from inside of the
> guest will apply the next run snapshot.

Cool, thanks for confirming.

Reviewed and merged.

4.1 changes published at https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/virtual_machine_management_guide/hot_plugging_virtual_memory