[RFC] Shutdown VM graceful
Currently, stopping guests in Kimchi is not graceful in the sense that the guest becomes 'shut down' immediately. This could be be problematic because guest file systems could become corrupted. Perhaps a warning should be added before a guest is immediately stopped or reset. kimchi can does not support shutdown by agent, so we can not guarantee we can shutdown graceful. User should install agent manully We can use acpi shutdown a VM. But not all guest os will shutdown the VM even it receive acpi shutdown. So I have 2 proposal: 1. only one shutdown API and one shutdown button for UI. when user click shutdown, the backend will try to shutdown VM by acpi. if 1 minutes timeout, kimchi will destroy the VM forcefully. 2. support ACPI shutdown and destroy two APIs. support "force off" and "shutdown" 2 buttons in UI. "shutdown" means ACPI shutdown. but we can not guarantee it can shutdown the VM. If the user find the VM is not shutdown for some time, he can try to force power off the VM -- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
I would recommend option 2: "shutdown" and "power off" On 4/8/2014 11:21 AM, Sheldon wrote:
Currently, stopping guests in Kimchi is not graceful in the sense that the guest becomes 'shut down' immediately. This could be be problematic because guest file systems could become corrupted. Perhaps a warning should be added before a guest is immediately stopped or reset.
kimchi can does not support shutdown by agent, so we can not guarantee we can shutdown graceful. User should install agent manully
We can use acpi shutdown a VM. But not all guest os will shutdown the VM even it receive acpi shutdown.
So I have 2 proposal:
1. only one shutdown API and one shutdown button for UI. when user click shutdown, the backend will try to shutdown VM by acpi. if 1 minutes timeout, kimchi will destroy the VM forcefully.
2. support ACPI shutdown and destroy two APIs. support "force off" and "shutdown" 2 buttons in UI. "shutdown" means ACPI shutdown. but we can not guarantee it can shutdown the VM. If the user find the VM is not shutdown for some time, he can try to force power off the VM
-- Adam King <rak@linux.vnet.ibm.com> IBM C&SI
My vote is for option 2 too On 04/08/2014 12:57 PM, Adam King wrote:
I would recommend option 2: "shutdown" and "power off"
On 4/8/2014 11:21 AM, Sheldon wrote:
Currently, stopping guests in Kimchi is not graceful in the sense that the guest becomes 'shut down' immediately. This could be be problematic because guest file systems could become corrupted. Perhaps a warning should be added before a guest is immediately stopped or reset.
kimchi can does not support shutdown by agent, so we can not guarantee we can shutdown graceful. User should install agent manully
We can use acpi shutdown a VM. But not all guest os will shutdown the VM even it receive acpi shutdown.
So I have 2 proposal:
1. only one shutdown API and one shutdown button for UI. when user click shutdown, the backend will try to shutdown VM by acpi. if 1 minutes timeout, kimchi will destroy the VM forcefully.
2. support ACPI shutdown and destroy two APIs. support "force off" and "shutdown" 2 buttons in UI. "shutdown" means ACPI shutdown. but we can not guarantee it can shutdown the VM. If the user find the VM is not shutdown for some time, he can try to force power off the VM
+1 for option 2 -- Paulo Ricardo Paz Vital <pvital@linux.vnet.ibm.com> IBM Linux Technology Center On Tue, 2014-04-08 at 15:00 -0300, Aline Manera wrote:
My vote is for option 2 too
On 04/08/2014 12:57 PM, Adam King wrote:
I would recommend option 2: "shutdown" and "power off"
On 4/8/2014 11:21 AM, Sheldon wrote:
Currently, stopping guests in Kimchi is not graceful in the sense that the guest becomes 'shut down' immediately. This could be be problematic because guest file systems could become corrupted. Perhaps a warning should be added before a guest is immediately stopped or reset.
kimchi can does not support shutdown by agent, so we can not guarantee we can shutdown graceful. User should install agent manully
We can use acpi shutdown a VM. But not all guest os will shutdown the VM even it receive acpi shutdown.
So I have 2 proposal:
1. only one shutdown API and one shutdown button for UI. when user click shutdown, the backend will try to shutdown VM by acpi. if 1 minutes timeout, kimchi will destroy the VM forcefully.
2. support ACPI shutdown and destroy two APIs. support "force off" and "shutdown" 2 buttons in UI. "shutdown" means ACPI shutdown. but we can not guarantee it can shutdown the VM. If the user find the VM is not shutdown for some time, he can try to force power off the VM
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Then about the API. define one API but with a filter parameters as follow: --- a/docs/API.md +++ b/docs/API.md @@ -102,7 +102,9 @@ the following general conventions: **Actions (POST):** * start: Power on a VM -* stop: Power off forcefully +* stop: Power off a VM + * grace *(optional)*: If 'true', Power off a VM gracefully, + or Power off a VM forcefully. * connect: Prepare the connection for spice or vnc ### Sub-resource: Virtual Machine Screenshot or add a new rest API for acpi shutdown? --- a/docs/API.md +++ b/docs/API.md @@ -103,6 +103,8 @@ the following general conventions: * start: Power on a VM * stop: Power off forcefully +* shutdown: Shutdown a VM gracefully. + Note that the guest OS may ignore the request. * connect: Prepare the connection for spice or vnc ### Sub-resource: Virtual Machine Screenshot On 04/09/2014 03:54 AM, Paulo Ricardo Paz Vital wrote:
+1 for option 2 -- Paulo Ricardo Paz Vital <pvital@linux.vnet.ibm.com> IBM Linux Technology Center On Tue, 2014-04-08 at 15:00 -0300, Aline Manera wrote:
My vote is for option 2 too
On 04/08/2014 12:57 PM, Adam King wrote:
I would recommend option 2: "shutdown" and "power off"
On 4/8/2014 11:21 AM, Sheldon wrote:
>Currently, stopping guests in Kimchi is not graceful in the sense >that the guest becomes 'shut down' immediately. This could be be >problematic because guest file systems could become corrupted. >Perhaps a warning should be added before a guest is immediately >stopped or reset. > >kimchi can does not support shutdown by agent, so we can not >guarantee we can shutdown graceful. >User should install agent manully > >We can use acpi shutdown a VM. But not all guest os will shutdown the >VM even it receive acpi shutdown. > >So I have 2 proposal: > >1. only one shutdown API and one shutdown button for UI. >when user click shutdown, the backend will try to shutdown VM by acpi. >if 1 minutes timeout, kimchi will destroy the VM forcefully. > >2. support ACPI shutdown and destroy two APIs. support "force off" >and "shutdown" 2 buttons in UI. >"shutdown" means ACPI shutdown. but we can not guarantee it can >shutdown the VM. >If the user find the VM is not shutdown for some time, he can try to >force power off the VM > >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
On 04/09/2014 06:56 AM, Sheldon wrote:
Then about the API. define one API but with a filter parameters as follow:
--- a/docs/API.md +++ b/docs/API.md @@ -102,7 +102,9 @@ the following general conventions: **Actions (POST):**
* start: Power on a VM -* stop: Power off forcefully +* stop: Power off a VM + * grace *(optional)*: If 'true', Power off a VM gracefully, + or Power off a VM forcefully. * connect: Prepare the connection for spice or vnc
### Sub-resource: Virtual Machine Screenshot
or add a new rest API for acpi shutdown? --- a/docs/API.md +++ b/docs/API.md @@ -103,6 +103,8 @@ the following general conventions:
* start: Power on a VM * stop: Power off forcefully +* shutdown: Shutdown a VM gracefully. + Note that the guest OS may ignore the request. * connect: Prepare the connection for spice or vnc
how about: stop (for shutdown graceful) and forceoff
### Sub-resource: Virtual Machine Screenshot
On 04/09/2014 03:54 AM, Paulo Ricardo Paz Vital wrote:
+1 for option 2 -- Paulo Ricardo Paz Vital <pvital@linux.vnet.ibm.com> IBM Linux Technology Center On Tue, 2014-04-08 at 15:00 -0300, Aline Manera wrote:
My vote is for option 2 too
On 04/08/2014 12:57 PM, Adam King wrote:
I would recommend option 2: "shutdown" and "power off"
On 4/8/2014 11:21 AM, Sheldon wrote: >>Currently, stopping guests in Kimchi is not graceful in the sense >>that the guest becomes 'shut down' immediately. This could be be >>problematic because guest file systems could become corrupted. >>Perhaps a warning should be added before a guest is immediately >>stopped or reset. >> >>kimchi can does not support shutdown by agent, so we can not >>guarantee we can shutdown graceful. >>User should install agent manully >> >>We can use acpi shutdown a VM. But not all guest os will shutdown the >>VM even it receive acpi shutdown. >> >>So I have 2 proposal: >> >>1. only one shutdown API and one shutdown button for UI. >>when user click shutdown, the backend will try to shutdown VM by acpi. >>if 1 minutes timeout, kimchi will destroy the VM forcefully. >> >>2. support ACPI shutdown and destroy two APIs. support "force off" >>and "shutdown" 2 buttons in UI. >>"shutdown" means ACPI shutdown. but we can not guarantee it can >>shutdown the VM. >>If the user find the VM is not shutdown for some time, he can try to >>force power off the VM >> >>
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
On 04/09/2014 08:34 PM, Aline Manera wrote:
On 04/09/2014 06:56 AM, Sheldon wrote:
Then about the API. define one API but with a filter parameters as follow:
--- a/docs/API.md +++ b/docs/API.md @@ -102,7 +102,9 @@ the following general conventions: **Actions (POST):**
* start: Power on a VM -* stop: Power off forcefully +* stop: Power off a VM + * grace *(optional)*: If 'true', Power off a VM gracefully, + or Power off a VM forcefully. * connect: Prepare the connection for spice or vnc
### Sub-resource: Virtual Machine Screenshot
or add a new rest API for acpi shutdown? --- a/docs/API.md +++ b/docs/API.md @@ -103,6 +103,8 @@ the following general conventions:
* start: Power on a VM * stop: Power off forcefully +* shutdown: Shutdown a VM gracefully. + Note that the guest OS may ignore the request. * connect: Prepare the connection for spice or vnc
how about: stop (for shutdown graceful) and forceoff ACK.
### Sub-resource: Virtual Machine Screenshot
On 04/09/2014 03:54 AM, Paulo Ricardo Paz Vital wrote:
+1 for option 2 -- Paulo Ricardo Paz Vital <pvital@linux.vnet.ibm.com> IBM Linux Technology Center On Tue, 2014-04-08 at 15:00 -0300, Aline Manera wrote:
My vote is for option 2 too
On 04/08/2014 12:57 PM, Adam King wrote:
>I would recommend option 2: "shutdown" and "power off" > >On 4/8/2014 11:21 AM, Sheldon wrote: > >>Currently, stopping guests in Kimchi is not graceful in the sense > >>that the guest becomes 'shut down' immediately. This could be be > >>problematic because guest file systems could become corrupted. > >>Perhaps a warning should be added before a guest is immediately > >>stopped or reset. > >> > >>kimchi can does not support shutdown by agent, so we can not > >>guarantee we can shutdown graceful. > >>User should install agent manully > >> > >>We can use acpi shutdown a VM. But not all guest os will shutdown the > >>VM even it receive acpi shutdown. > >> > >>So I have 2 proposal: > >> > >>1. only one shutdown API and one shutdown button for UI. > >>when user click shutdown, the backend will try to shutdown VM by acpi. > >>if 1 minutes timeout, kimchi will destroy the VM forcefully. > >> > >>2. support ACPI shutdown and destroy two APIs. support "force off" > >>and "shutdown" 2 buttons in UI. > >>"shutdown" means ACPI shutdown. but we can not guarantee it can > >>shutdown the VM. > >>If the user find the VM is not shutdown for some time, he can try to > >>force power off the VM > >> > >> >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
-- Thanks and best regards! Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
? 2014/4/9 20:34, Aline Manera ??:
On 04/09/2014 06:56 AM, Sheldon wrote:
Then about the API. define one API but with a filter parameters as follow:
--- a/docs/API.md +++ b/docs/API.md @@ -102,7 +102,9 @@ the following general conventions: **Actions (POST):**
* start: Power on a VM -* stop: Power off forcefully +* stop: Power off a VM + * grace *(optional)*: If 'true', Power off a VM gracefully, + or Power off a VM forcefully. * connect: Prepare the connection for spice or vnc
### Sub-resource: Virtual Machine Screenshot
or add a new rest API for acpi shutdown? --- a/docs/API.md +++ b/docs/API.md @@ -103,6 +103,8 @@ the following general conventions:
* start: Power on a VM * stop: Power off forcefully +* shutdown: Shutdown a VM gracefully. + Note that the guest OS may ignore the request. * connect: Prepare the connection for spice or vnc
how about: stop (for shutdown graceful) and forceoff
Shutdown may be better. Because word 'stop' is something like the 'halt' command in UNIX like system, 'halt' mean stopping the OS but not power off. Here, we are expecting the system can be stopped and power offed with the graceful operation tough, so shutdown is better.
### Sub-resource: Virtual Machine Screenshot
On 04/09/2014 03:54 AM, Paulo Ricardo Paz Vital wrote:
+1 for option 2 -- Paulo Ricardo Paz Vital <pvital@linux.vnet.ibm.com> IBM Linux Technology Center On Tue, 2014-04-08 at 15:00 -0300, Aline Manera wrote:
My vote is for option 2 too
On 04/08/2014 12:57 PM, Adam King wrote:
>I would recommend option 2: "shutdown" and "power off" > >On 4/8/2014 11:21 AM, Sheldon wrote: > >>Currently, stopping guests in Kimchi is not graceful in the sense > >>that the guest becomes 'shut down' immediately. This could be be > >>problematic because guest file systems could become corrupted. > >>Perhaps a warning should be added before a guest is immediately > >>stopped or reset. > >> > >>kimchi can does not support shutdown by agent, so we can not > >>guarantee we can shutdown graceful. > >>User should install agent manully > >> > >>We can use acpi shutdown a VM. But not all guest os will shutdown the > >>VM even it receive acpi shutdown. > >> > >>So I have 2 proposal: > >> > >>1. only one shutdown API and one shutdown button for UI. > >>when user click shutdown, the backend will try to shutdown VM by acpi. > >>if 1 minutes timeout, kimchi will destroy the VM forcefully. > >> > >>2. support ACPI shutdown and destroy two APIs. support "force off" > >>and "shutdown" 2 buttons in UI. > >>"shutdown" means ACPI shutdown. but we can not guarantee it can > >>shutdown the VM. > >>If the user find the VM is not shutdown for some time, he can try to > >>force power off the VM > >> > >> >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
on 2014/04/08 23:21, Sheldon wrote:
Currently, stopping guests in Kimchi is not graceful in the sense that the guest becomes 'shut down' immediately. This could be be problematic because guest file systems could become corrupted. Perhaps a warning should be added before a guest is immediately stopped or reset.
kimchi can does not support shutdown by agent, so we can not guarantee we can shutdown graceful. User should install agent manully
We can use acpi shutdown a VM. But not all guest os will shutdown the VM even it receive acpi shutdown.
So I have 2 proposal:
1. only one shutdown API and one shutdown button for UI. when user click shutdown, the backend will try to shutdown VM by acpi. if 1 minutes timeout, kimchi will destroy the VM forcefully.
2. support ACPI shutdown and destroy two APIs. support "force off" and "shutdown" 2 buttons in UI. "shutdown" means ACPI shutdown. but we can not guarantee it can shutdown the VM. If the user find the VM is not shutdown for some time, he can try to force power off the VM
I'd prefer option 2. Only the user knows what's inside the VM, and we should not force a power off. Furthermore, option 1 makes the back-end complicated. Option 2 is better, because it's up to the user to determine what to do. In real world computers, pressing the power button once sends an ACPI shutdown signal to the OS. If the OS hangs, the user can keep pressing the power button till the computer power off. We should mimic this behavior. We can have two buttons, "Gracefully Shutdown" and "Hard Stop". -- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
2014/4/9 10:13, Zhou Zheng Sheng:
on 2014/04/08 23:21, Sheldon wrote:
Currently, stopping guests in Kimchi is not graceful in the sense that the guest becomes 'shut down' immediately. This could be be problematic because guest file systems could become corrupted. Perhaps a warning should be added before a guest is immediately stopped or reset.
kimchi can does not support shutdown by agent, so we can not guarantee we can shutdown graceful. User should install agent manully
We can use acpi shutdown a VM. But not all guest os will shutdown the VM even it receive acpi shutdown.
So I have 2 proposal:
1. only one shutdown API and one shutdown button for UI. when user click shutdown, the backend will try to shutdown VM by acpi. if 1 minutes timeout, kimchi will destroy the VM forcefully.
2. support ACPI shutdown and destroy two APIs. support "force off" and "shutdown" 2 buttons in UI. "shutdown" means ACPI shutdown. but we can not guarantee it can shutdown the VM.
That bring another idea to my head. As to emulate the real world as possible as we can, we can have only one button in the UI, say 'power' button. The user can click the 'power' button in the first try to see if the vm can be shutdown gracefully. If that fails, the user can click and hold the button for a while to force the system off.
If the user find the VM is not shutdown for some time, he can try to force power off the VM
I'd prefer option 2. Only the user knows what's inside the VM, and we should not force a power off. Furthermore, option 1 makes the back-end complicated. Option 2 is better, because it's up to the user to determine what to do. In real world computers, pressing the power button once sends an ACPI shutdown signal to the OS. If the OS hangs, the user can keep pressing the power button till the computer power off. We should mimic this behavior. We can have two buttons, "Gracefully Shutdown" and "Hard Stop".
participants (6)
-
Adam King -
Aline Manera -
Paulo Ricardo Paz Vital -
Sheldon -
Shu Ming -
Zhou Zheng Sheng