9:23 a.m.
On 13.11.2015 14:09, Daniel Henrique Barboza wrote:
Hi,
The backend for this feature is almost completed and the API is
defined, so let's
talk about the UI.
This is the API (note: the upstream version is outdated, will be
updated in an
incoming patch):
**URI:** /plugins/kimchi/vms/*:name*
* **POST**: *See Virtual Machine Actions*
**Actions (POST):**
* migrate: Migrate a virtual machine to a remote server, only support
live
mode without block migration.
* remote_host: IP address or hostname of the remote server.
* user *(optional)*: User to log on at the remote server.
* password *(optional)*: password of the user in the remote server
This API will return a task ID for the UI to track its progress,
pretty much
like it is done with the 'clone' feature.
This is how I imagine the UI:
- a button called "migrate" at the same submenu as clone VM.
- when pressed, a new window appears with the following content:
--------
"Disclaimer: this process cannot be stopped after started, can take a
long time
to complete and will turn off this current VM when it is over."
I would
propose to change the wording: will turn off this current VM
when it is over. into something like: will turn off the VM on this
Hypervisor when it is sucessfully migrated to the remote destination.
Sorry, but I don't remember if we allow static migration as well ? If we
do, then we may have to display a different text for the static migration.
* textfield to input the remote_server, name "remote server"
* checkbox with text: "Delete this VM when the migration is completed"
Typically the VM definition, and I guess this is what the checkbox is
reffering to, is migrated to the remote host as well in order to allow
full management of this VM on the remote host (like changing its
configuration). I'm aware that we are not doing such actions in this
first release. However migrating the VM definition has a sideeffect we
may want to consider in this scope: it makes sure that you can not have
multiple instances of the VM running on different hosts. This aspect is
releveant only if starting the VM multiple times is causing a conflict
on a resource like: the same SCSI disk as boot device.
I'm wondering that if the user doesn't select the above checkbox we
should put out a warning like: "Restarting the VM locally may cause
resource conflicts with the migrated instance"
Text: "The following fields are optional. Fill them if you want Kimchi to
setup a password-less ssh session between the localhost and the
remote host. The setup process will only be successful if the user
has 'SUDO ALL' permission in the remote machine"
* textfield to input the username of the remote host
* password field to input the password of the user in the remote host
* "Cancel" and "Start" buttons at the bottom
-------------
This is the workflow/behavior I would expect of it:
- clicking "Cancel" at any time will dismiss the window and nothing
happens;
- clicking "Start" without remote_host field will issue an error
"remote host field
cannot be blank" or something like that
- clicking "Start" with a remote host field will start the process
- clicking "Start" with remote host and only one of the user or
password filled
will raise an error "both user and password fields must be filled".
- if, **and only if **, the user checks the checkbox "Delete VM
....", the UI will
delete the VM after the migration process is completed by using the
proper API
(I believe it is DELETE /vms/name).
This is all I have for the UI for this feature ATM. I'll update this
RFC if required.
Please provide comments and suggestions. The final backend for this
feature
will be submitted to the ML at the start of the next week.
Let me know if there's any doubts about how Kimchi's live migration
backend
works.
Daniel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel