Bug 1454673 - [RFE] Changes that require Virtual Machine restart: name
Summary: [RFE] Changes that require Virtual Machine restart: name
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.0
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ovirt-4.3.0
: 4.3.0
Assignee: Arik
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks: 1417161 1601514
TreeView+ depends on / blocked
 
Reported: 2017-05-23 09:43 UTC by Olimp Bockowski
Modified: 2021-09-09 12:20 UTC (History)
13 users (show)

Fixed In Version: ovirt-engine-4.3.0_alpha
Doc Type: Enhancement
Doc Text:
When renaming a running virtual machine, the new name is now applied immediately, even when the QEMU process is running and is set with the previous name. In this case, the user is provided with a warning that indicates that the running instance of the virtual machine uses the previous name.
Clone Of:
: 1601514 (view as bug list)
Environment:
Last Closed: 2019-05-08 12:36:48 UTC
oVirt Team: Virt
Target Upstream Version:
mavital: testing_plan_complete-


Attachments (Terms of Use)
Current warning to restart is cropped and unclear (5.52 MB, image/jpeg)
2017-06-20 20:29 UTC, Marina Kalinin
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-38447 0 None None None 2021-09-09 12:20:45 UTC
Red Hat Product Errata RHEA-2019:1085 0 None None None 2019-05-08 12:37:11 UTC
oVirt gerrit 92717 0 'None' MERGED core: add runtime name to vms 2020-09-22 17:41:10 UTC
oVirt gerrit 92718 0 'None' MERGED webadmin: indication of running vms whose name has changed 2020-09-22 17:41:10 UTC
oVirt gerrit 92732 0 'None' MERGED core: log running vms whose name changes 2020-09-22 17:41:09 UTC
oVirt gerrit 92936 0 'None' MERGED core: add runtime name to vms 2020-09-22 17:41:09 UTC
oVirt gerrit 92937 0 'None' MERGED core: log running vms whose name changes 2020-09-22 17:41:09 UTC
oVirt gerrit 92938 0 'None' MERGED webadmin: indication of running vms whose name has changed 2020-09-22 17:41:09 UTC

Description Olimp Bockowski 2017-05-23 09:43:37 UTC
Description of problem:
In RHV 4.1 rename VM  requires restart

Version-Release number of selected component (if applicable):
only RHV 4.1+ 
all previous versions didn't have any problems with this ordinary operation

How reproducible:
always

Steps to Reproduce:
1. edit VM
2. put new name
3. A dialog window appears with title "Pending Virtual Machine Changes" and message  "Changes that require Virtual Machine restart: name"

Actual results:
rename VM requires restart

Expected results:
no need for restart, it should work like in all previous RHEV/RHV versions

Additional info:
I hope it is bug, cause it would be huge regression for enterprise environments if it wasn't possible to change VM name. 
I don't see any reasons why reboot is needed, there is only different qemu-kvm parameter -name

Comment 1 Michal Skrivanek 2017-05-24 06:47:45 UTC
http://lists.ovirt.org/pipermail/users/2017-May/081892.html

It's not that it's not possible to change, but it is not possible without a QEMU restart, hence the requirement. The reboot(powercycle) is required only for getting the name reflected correctly

Comment 2 Olimp Bockowski 2017-05-24 07:05:59 UTC
It is not the matter of 'pop up window' If you change VM name it _is not_ changed, the old name is displayed but only after edit you can see the new one. I believe it shouldn't be like that. In the enterprise environment customers won't be eager to restart critical VM due to a simple rename. 
It was working in a different way for all versions before 4.1, now it isn't. I don't agree this bug is closed.

Comment 4 Martin Tessun 2017-05-26 16:34:44 UTC
Hi Olimp,

(In reply to Olimp Bockowski from comment #2)
> It is not the matter of 'pop up window' If you change VM name it _is not_
> changed, the old name is displayed but only after edit you can see the new
> one. I believe it shouldn't be like that. In the enterprise environment
> customers won't be eager to restart critical VM due to a simple rename. 

I agree here, but this would require some indepth changes up to the qemu layer.
The problem that arises here is mostly for support. We can of course rename/display the new name for the VM, but the running VM will still be recognized with the old name.

Just giving you a virsh example of renaming a running domain:
[root@hv ~]# virsh domrename mtessun-win-AD mtessun-win-AD1
error: Requested operation is not valid: cannot rename active domain
[root@hv ~]# 

So the behaviour requesting the restart is correct, and I think for support reasons we need to display the old name at least somewhere so that support is able to get the link between the name and the "real name" of the VM. Also marking that VM as "restart needed" is totally correct.

> It was working in a different way for all versions before 4.1, now it isn't.
> I don't agree this bug is closed.

I haven't tested this, but it looks like this has been a bug and may have been an issue for support as well.

Still as it worked, and customers expect that it works without a reboot, I would tend calling this a regression.
While I agree that we should somehow fix this, I don't agree with reverting this change, as it does the right thing.

Reopening this bug for further discussion about how to solve this.
Some possible approaches that comes to mind would be, e.g.:

- Display the "new" name by default, but display the "current" name on mouse over as a popup.
- Display the new name, and have an additional fied showing "running name" which is hidden by default, but can be used/displayed if needed.
- Removing the warning and the yellow triangle from the VM and instead add a symbol to the name that shows the "running" name in case of mouse over.

There are probably more, these are just the ones that come to mind.
@Olimp/Michal: Comments or suggestions?

Comment 6 Olimp Bockowski 2017-05-26 20:00:01 UTC
Hello, 

Thank you for the comprehensive explanation. If 'rename' was a new feature, I would look at it in a different way but my approach was obscured due to previous versions. Indeed, it was working but it could lead to some other issues - now I understand this fact and I agree we can't revert.

Regarding solution:
I think users don't need to know those technical dependencies. I believe we should change 'rename' operation somehow. I would even say that "display" part could be handled like in previous versions but internal implementation for 'rename' operation could be changed. I am not sure what @Michal thinks about it and is it possible. 
Your idea looks good:
Display the "new" name by default, but display the "current" name on mouse over as a popup.'
Moreover, I wouldn't display anything alarming. Any kind of popup window with warning/any special icon makes users frightened. They shouldn't be concerned.

Comment 9 Sergio Lopez 2017-05-31 14:04:46 UTC
Hi,

While I agree on the usefulness from user's perspective of being able to change the VM name without rebooting, IMHO being able to do it partially (in the sense of being changed by pending on a reboot) is not good UX. Users tend to expect that their actions will either succeed immediately or fail.

On the other hand, as an alternative to extending libvirt/QEMU to support dynamic name changes, perhaps the option of decoupling the human readable name for the VM in RHV, with the domain name in libVirt.

That is, for every VM created, an internal, immutable name/UUID would be assigned, with a tuple in the DB establishing the relationship between this one, and the user provided, human readable name.

I think this is something similar to what's already being done with VM disks.

Sergio.

Comment 13 Marina Kalinin 2017-06-05 14:54:46 UTC
Hi all,

First, I believe, we should change this bug to RFE, since the functionality never existed. Here is an older bug, showing that this never worked properly and was never propagating the information back to libvirt and qemu. bz#1375379.

Second, I suggest we open RFEs for qemu-kvm and libvirt and track them as dependencies of this bug. Once they are implemented, we can proceed with the change in RHV (engine and vdsm).

Comment 14 Marina Kalinin 2017-06-05 15:06:00 UTC
(In reply to Sergio Lopez from comment #9)
> 
> That is, for every VM created, an internal, immutable name/UUID would be
> assigned, with a tuple in the DB establishing the relationship between this
> one, and the user provided, human readable name.
Michal, what do you think about this one?
This way, we may avoid intervention with qemu and libvirt.

Comment 15 Michal Skrivanek 2017-06-05 15:20:20 UTC
(In reply to Marina from comment #14)
> (In reply to Sergio Lopez from comment #9)
> > 
> > That is, for every VM created, an internal, immutable name/UUID would be
> > assigned, with a tuple in the DB establishing the relationship between this
> > one, and the user provided, human readable name.
> Michal, what do you think about this one?
> This way, we may avoid intervention with qemu and libvirt.

There already is a UUID, it's the same level of effort as in comment #3, it's just so many places to change. The problem with using a mapping and capturing it in logcollector is that we end up in the similar state as with disks/storage paths. Sure the mapping is stored somewhere, but it's not easy/impossible to get it from partial logs, and it's tiring to work with them in any kind of troubleshooting.
I doubt a dynamic change in libvirt/qemu is feasible without heavy changes. E.g. the name is on a QEMU command line which can't really be changed. If we go with UUIDs there then we're back to the above troubleshooting complications.

comment #8 to find a place where a new name is shown is the most easy one.

Comment 18 Marina Kalinin 2017-06-20 20:29:55 UTC
Created attachment 1289844 [details]
Current warning to restart is cropped and unclear

Comment 22 Martin Tessun 2017-06-28 14:37:05 UTC
Hi Olimp,

after discussing the possible solutions and performance impacts, the most feasible solution (with the least performance impact) would be as follows:

1. Have the "Config has changed" triangle still added to the VM
2. Have the VM details show the Current and Next run name (not as a tooltip, as this would hit performance).

Just let me know, if that is an acceptable solution.

Thanks!
Martin

Comment 25 Martin Tessun 2017-07-05 13:11:00 UTC
After further discussion with Olimp on this issue, the proposal from Comment #22 is acceptable.

Comment 33 Michal Skrivanek 2018-04-26 13:51:07 UTC
1. make the rename immediate in DB
2. flag the VM with pending change - this needs to be one-off as it would need a new db field just for this. We can either use the triangle or "!" next to the VM with a warning that name has changed. "!" is easier.
3. need to show the old(running) name somewhere - could be in "!" pop-up

this way searches would work too
I wonder if it's needed then to still show old name in Details page

Comment 35 Martin Tessun 2018-05-23 14:39:17 UTC
(In reply to Michal Skrivanek from comment #33)
> 1. make the rename immediate in DB
> 2. flag the VM with pending change - this needs to be one-off as it would
> need a new db field just for this. We can either use the triangle or "!"
> next to the VM with a warning that name has changed. "!" is easier.
> 3. need to show the old(running) name somewhere - could be in "!" pop-up
> 
> this way searches would work too
> I wonder if it's needed then to still show old name in Details page

Can you work on that solution, as I can understand that a rename should show up immediately for the customer.

We should try getting this done for 4.2.z (next or the one after).

Thanks!
Martin

Comment 39 Arik 2018-07-16 17:27:06 UTC
oops..

Comment 40 meital avital 2019-01-21 18:43:10 UTC
Verified on version : 4.3.0-0.8.master.20190115203932.gitaafcce1.el7

Verification steps:
1) Edit VM1.
2) Change the VM name to VM2.

The VM name changed and '!' appears with this pop up window - 'VM was started with a different name: VM1'

Comment 42 errata-xmlrpc 2019-05-08 12:36:48 UTC
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.

https://access.redhat.com/errata/RHEA-2019:1085


Note You need to log in before you can comment on or make changes to this bug.