+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1454673 +++ ====================================================================== 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 (Originally by Olimp Bockowski)
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 (Originally by michal.skrivanek)
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. (Originally by Olimp Bockowski)
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? (Originally by Martin Tessun)
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. (Originally by Olimp Bockowski)
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. (Originally by Sergio Lopez Pascual)
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). (Originally by Marina Kalinin)
(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. (Originally by Marina Kalinin)
(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. (Originally by michal.skrivanek)
Created attachment 1289844 [details] Current warning to restart is cropped and unclear (Originally by Marina Kalinin)
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 (Originally by Martin Tessun)
After further discussion with Olimp on this issue, the proposal from Comment #22 is acceptable. (Originally by Martin Tessun)
Documentation needs updating. According to https://www.ovirt.org/documentation/vmm-guide/chap-Editing_Virtual_Machines/ https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/virtual_machine_management_guide/chap-editing_virtual_machines https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2-beta/html/virtual_machine_management_guide/chap-editing_virtual_machines Changing the VM name is immediate with no restart required. (Originally by matonb)
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 (Originally by michal.skrivanek)
(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 (Originally by Martin Tessun)
Verified on version : rhv-release-4.2.5-5-001.noarch 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'
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/RHBA-2018:2318