[Kimchi-devel] [RFC] Shutdown VM graceful

Shu Ming shuming at linux.vnet.ibm.com
Fri Apr 11 08:18:08 UTC 2014


? 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 at 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 at ovirt.org
>>>> >http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>> >
>>> _______________________________________________
>>> Kimchi-devel mailing list
>>> Kimchi-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>>
>>>
>>
>>
>> -- 
>> Thanks and best regards!
>>
>> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
>> IBM Linux Technology Center
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140411/6b82f6bb/attachment.html>


More information about the Kimchi-devel mailing list