[libvirt] [PATCH] virsh: add aliases 'boot', 'stop', and 'restart'

Peter Krempa pkrempa at redhat.com
Tue Nov 6 09:01:44 UTC 2012


On 11/06/12 09:30, Viktor Mihajlovski wrote:
> On 11/05/2012 08:59 PM, Eric Blake wrote:
>>
>> This patch documents both spellings.  An alternative would be to
>> leave the alternate spellings as hidden aliases (virsh has support
>> for that), but still mention them in virsh.pod (see how we did an
>> alias for nodedev-dettach, for reference).
> In my opinion start, stop, restart is better than the mix before and
> semantically more accurate than boot, shutdown, reboot. The latter uses
> terms that apply to the operating system inside the domain rather than
> the domain (virtual machine) itself.
> So I would even go so far to mark the latter group as legacy and
> recommend the usage of the former.
>>
>>   =item B<reboot> I<domain> [I<--mode acpi|agent>]
>> +=item B<restart> I<domain> [I<--mode acpi|agent>]
>>
>>   Reboot a domain.  This acts just as if the domain had the B<reboot>
>>   command run from the console.  The command returns as soon as it has
> Now it would be a good time to correct the documentation. In reality the
> restart/reboot is a combination of stop/shutdown followed by an in-place
> reset of the domain (at least for QEMU/KVM). Which can behave the same
> as a reboot but doesn't have to. This is one area of confusion for users
> I have observed. Restart seems to raise a lower expectation level ;-).
> For that reason I would also vote to exchange the order of appearance
> (restart first).

I agree on this point.

>> @@ -1523,6 +1524,7 @@ be hot-plugged the next time the domain is
>> booted.  As such, it must only be
>>   used with the I<--config> flag, and not with the I<--live> flag.
>>
>>   =item B<shutdown> I<domain> [I<--mode acpi|agent>]
>> +=item B<stop> I<domain> [I<--mode acpi|agent>]
>>
> Same suggestion: first line stop, second shutdown.
>

But here I think stop is less appropriate. For me stop sounds 
semantically more like what destroy does.

>

Giving the number of voices wanting this, I don't object any more.

Peter




More information about the libvir-list mailing list