[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