Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
---
tools/virsh.pod | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 5f72e11dec..5fc8201893 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -599,7 +599,13 @@ incompatibility will be printed out.
=item B<cpu-models> I<arch>
-Print the list of CPU models known for the specified architecture.
+Print the list of CPU models known by libvirt for the specified architecture.
+Whether a specific hypervisor is able to create a domain which uses any of
+the printed CPU models is a separate question which can be answered by
+looking the domain capabilities XML returned by B<domcapabilities> command.
+Moreover, for some architectures libvirt does not know any CPU models and
+the usable CPU models are only limited by the hypervisor. This command will
+print that all CPU models are accepted for these architectures.
=item B<echo> [I<--shell>] [I<--xml>] [I<arg>...]
--
2.17.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 05/16/2018 04:39 AM, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark <jdenemar@redhat.com> > --- > tools/virsh.pod | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/tools/virsh.pod b/tools/virsh.pod > index 5f72e11dec..5fc8201893 100644 > --- a/tools/virsh.pod > +++ b/tools/virsh.pod > @@ -599,7 +599,13 @@ incompatibility will be printed out. > > =item B<cpu-models> I<arch> > > -Print the list of CPU models known for the specified architecture. > +Print the list of CPU models known by libvirt for the specified architecture. > +Whether a specific hypervisor is able to create a domain which uses any of > +the printed CPU models is a separate question which can be answered by > +looking the domain capabilities XML returned by B<domcapabilities> command. > +Moreover, for some architectures libvirt does not know any CPU models and > +the usable CPU models are only limited by the hypervisor. This command will > +print that all CPU models are accepted for these architectures. > > =item B<echo> [I<--shell>] [I<--xml>] [I<arg>...] > > Reviewed-by: Collin Walling <walling@linux.ibm.com> -- Respectfully, - Collin Walling -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 16, 2018 at 10:39:23AM +0200, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark <jdenemar@redhat.com> > --- > tools/virsh.pod | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/tools/virsh.pod b/tools/virsh.pod > index 5f72e11dec..5fc8201893 100644 > --- a/tools/virsh.pod > +++ b/tools/virsh.pod > @@ -599,7 +599,13 @@ incompatibility will be printed out. > > =item B<cpu-models> I<arch> > > -Print the list of CPU models known for the specified architecture. > +Print the list of CPU models known by libvirt for the specified architecture. > +Whether a specific hypervisor is able to create a domain which uses any of > +the printed CPU models is a separate question which can be answered by > +looking the domain capabilities XML returned by B<domcapabilities> command. s/looking the/looking at the/ > +Moreover, for some architectures libvirt does not know any CPU models and > +the usable CPU models are only limited by the hypervisor. Wonder if it is worth adding a small example for the above. > This command will > +print that all CPU models are accepted for these architectures. s/CPU models are accepted/CPU models that are accepted/ > > =item B<echo> [I<--shell>] [I<--xml>] [I<arg>...] > With the nits addresed: Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> -- /kashyap -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 23, 2018 at 13:08:51 +0200, Kashyap Chamarthy wrote: > On Wed, May 16, 2018 at 10:39:23AM +0200, Jiri Denemark wrote: > > Signed-off-by: Jiri Denemark <jdenemar@redhat.com> > > --- > > tools/virsh.pod | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/tools/virsh.pod b/tools/virsh.pod > > index 5f72e11dec..5fc8201893 100644 > > --- a/tools/virsh.pod > > +++ b/tools/virsh.pod > > @@ -599,7 +599,13 @@ incompatibility will be printed out. > > > > =item B<cpu-models> I<arch> > > > > -Print the list of CPU models known for the specified architecture. > > +Print the list of CPU models known by libvirt for the specified architecture. > > +Whether a specific hypervisor is able to create a domain which uses any of > > +the printed CPU models is a separate question which can be answered by > > +looking the domain capabilities XML returned by B<domcapabilities> command. > > s/looking the/looking at the/ Oops. > > > +Moreover, for some architectures libvirt does not know any CPU models and > > +the usable CPU models are only limited by the hypervisor. > > Wonder if it is worth adding a small example for the above. An example for what exactly? > > This command will > > +print that all CPU models are accepted for these architectures. > > s/CPU models are accepted/CPU models that are accepted/ It's certainly possible my wording was not perfect, but this change would make it wrong. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 23, 2018 at 02:43:23PM +0200, Jiri Denemark wrote: > On Wed, May 23, 2018 at 13:08:51 +0200, Kashyap Chamarthy wrote: > > On Wed, May 16, 2018 at 10:39:23AM +0200, Jiri Denemark wrote: > > > Signed-off-by: Jiri Denemark <jdenemar@redhat.com> > > > --- > > > tools/virsh.pod | 8 +++++++- > > > 1 file changed, 7 insertions(+), 1 deletion(-) [...] > > > +Moreover, for some architectures libvirt does not know any CPU models and > > > +the usable CPU models are only limited by the hypervisor. > > > > Wonder if it is worth adding a small example for the above. > > An example for what exactly? I meant an example of a usable CPU model that libvirt doesn't know for the said architecture(s). Maybe it's not worth it; not quite sure. > > > This command will > > > +print that all CPU models are accepted for these architectures. > > > > s/CPU models are accepted/CPU models that are accepted/ > > It's certainly possible my wording was not perfect, but this change > would make it wrong. Err, sorry, I misread that sentence; please disregard the above. [...] -- /kashyap -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 23, 2018 at 16:53:37 +0200, Kashyap Chamarthy wrote: > On Wed, May 23, 2018 at 02:43:23PM +0200, Jiri Denemark wrote: > > On Wed, May 23, 2018 at 13:08:51 +0200, Kashyap Chamarthy wrote: > > > On Wed, May 16, 2018 at 10:39:23AM +0200, Jiri Denemark wrote: > > > > Signed-off-by: Jiri Denemark <jdenemar@redhat.com> > > > > --- > > > > tools/virsh.pod | 8 +++++++- > > > > 1 file changed, 7 insertions(+), 1 deletion(-) > > [...] > > > > > +Moreover, for some architectures libvirt does not know any CPU models and > > > > +the usable CPU models are only limited by the hypervisor. > > > > > > Wonder if it is worth adding a small example for the above. > > > > An example for what exactly? > > I meant an example of a usable CPU model that libvirt doesn't know for > the said architecture(s). Maybe it's not worth it; not quite sure. The usable models are all models accepted by hypervisor for that architecture. So, e.g., libvirt won't list any CPU model for aarch64 when you call "virsh cpu-models aarch64", it will just print "all CPU models are accepted" and "virsh domcapabilities --arch aarch64" will show a very long list of CPU models libvirt would actually accept. Similarly for s390x. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 23, 2018 at 09:09:28PM +0200, Jiri Denemark wrote:
> On Wed, May 23, 2018 at 16:53:37 +0200, Kashyap Chamarthy wrote:
> > On Wed, May 23, 2018 at 02:43:23PM +0200, Jiri Denemark wrote:
> > > On Wed, May 23, 2018 at 13:08:51 +0200, Kashyap Chamarthy wrote:
> > > > On Wed, May 16, 2018 at 10:39:23AM +0200, Jiri Denemark wrote:
> > > > > Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
> > > > > ---
> > > > > tools/virsh.pod | 8 +++++++-
> > > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > [...]
> >
> > > > > +Moreover, for some architectures libvirt does not know any CPU models and
> > > > > +the usable CPU models are only limited by the hypervisor.
> > > >
> > > > Wonder if it is worth adding a small example for the above.
> > >
> > > An example for what exactly?
> >
> > I meant an example of a usable CPU model that libvirt doesn't know for
> > the said architecture(s). Maybe it's not worth it; not quite sure.
>
> The usable models are all models accepted by hypervisor for that
> architecture. So, e.g., libvirt won't list any CPU model for aarch64
> when you call "virsh cpu-models aarch64", it will just print "all CPU
> models are accepted" and "virsh domcapabilities --arch aarch64" will
> show a very long list of CPU models libvirt would actually accept.
> Similarly for s390x.
Ah, that is clearer; thank you. So if you think it is worth it, maybe
adjust your doc patch to a variant of the following:
Moreover, for some architectures libvirt does not know any CPU
models and the usable CPU models are only limited by the hypervisor
(e.g. to enumerate a list of acceptable CPU models for AArch64, use
`virsh domcapabilities --arch aarch64`; likewise for 's390x').
--
/kashyap
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, May 24, 2018 at 11:05:08 +0200, Kashyap Chamarthy wrote:
> On Wed, May 23, 2018 at 09:09:28PM +0200, Jiri Denemark wrote:
> > On Wed, May 23, 2018 at 16:53:37 +0200, Kashyap Chamarthy wrote:
> > > On Wed, May 23, 2018 at 02:43:23PM +0200, Jiri Denemark wrote:
> > > > On Wed, May 23, 2018 at 13:08:51 +0200, Kashyap Chamarthy wrote:
> > > > > On Wed, May 16, 2018 at 10:39:23AM +0200, Jiri Denemark wrote:
> > > > > > Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
> > > > > > ---
> > > > > > tools/virsh.pod | 8 +++++++-
> > > > > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > [...]
> > >
> > > > > > +Moreover, for some architectures libvirt does not know any CPU models and
> > > > > > +the usable CPU models are only limited by the hypervisor.
> > > > >
> > > > > Wonder if it is worth adding a small example for the above.
> > > >
> > > > An example for what exactly?
> > >
> > > I meant an example of a usable CPU model that libvirt doesn't know for
> > > the said architecture(s). Maybe it's not worth it; not quite sure.
> >
> > The usable models are all models accepted by hypervisor for that
> > architecture. So, e.g., libvirt won't list any CPU model for aarch64
> > when you call "virsh cpu-models aarch64", it will just print "all CPU
> > models are accepted" and "virsh domcapabilities --arch aarch64" will
> > show a very long list of CPU models libvirt would actually accept.
> > Similarly for s390x.
>
> Ah, that is clearer; thank you. So if you think it is worth it, maybe
> adjust your doc patch to a variant of the following:
>
> Moreover, for some architectures libvirt does not know any CPU
> models and the usable CPU models are only limited by the hypervisor
> (e.g. to enumerate a list of acceptable CPU models for AArch64, use
> `virsh domcapabilities --arch aarch64`; likewise for 's390x').
So how about
Print the list of CPU models known by libvirt for the specified
architecture. Whether a specific hypervisor is able to create a
domain which uses any of the printed CPU models is a separate
question which can be answered by looking at the domain capabilities
XML returned by B<domcapabilities> command. Moreover, for some
architectures libvirt does not know any CPU models and the usable
CPU models are only limited by the hypervisor. This command will
print that all CPU models are accepted for these architectures and
the actual list of supported CPU models can be checked in the domain
capabilities XML.
Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, May 25, 2018 at 11:36:21AM +0200, Jiri Denemark wrote: > On Thu, May 24, 2018 at 11:05:08 +0200, Kashyap Chamarthy wrote: [...] > > Ah, that is clearer; thank you. So if you think it is worth it, maybe > > adjust your doc patch to a variant of the following: > > > > Moreover, for some architectures libvirt does not know any CPU > > models and the usable CPU models are only limited by the hypervisor > > (e.g. to enumerate a list of acceptable CPU models for AArch64, use > > `virsh domcapabilities --arch aarch64`; likewise for 's390x'). > > So how about > > Print the list of CPU models known by libvirt for the specified > architecture. Whether a specific hypervisor is able to create a > domain which uses any of the printed CPU models is a separate > question which can be answered by looking at the domain capabilities > XML returned by B<domcapabilities> command. Moreover, for some > architectures libvirt does not know any CPU models and the usable > CPU models are only limited by the hypervisor. This command will > print that all CPU models are accepted for these architectures and > the actual list of supported CPU models can be checked in the domain > capabilities XML. Yep, clear and to the point. Thanks. Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> -- /kashyap -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 16, 2018 at 10:39:23AM +0200, Jiri Denemark wrote: >Signed-off-by: Jiri Denemark <jdenemar@redhat.com> >--- > tools/virsh.pod | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > >diff --git a/tools/virsh.pod b/tools/virsh.pod >index 5f72e11dec..5fc8201893 100644 >--- a/tools/virsh.pod >+++ b/tools/virsh.pod >@@ -599,7 +599,13 @@ incompatibility will be printed out. > > =item B<cpu-models> I<arch> > >-Print the list of CPU models known for the specified architecture. >+Print the list of CPU models known by libvirt for the specified architecture. >+Whether a specific hypervisor is able to create a domain which uses any of >+the printed CPU models is a separate question which can be answered by >+looking the domain capabilities XML returned by B<domcapabilities> command. >+Moreover, for some architectures libvirt does not know any CPU models and >+the usable CPU models are only limited by the hypervisor. This command will >+print that all CPU models are accepted for these architectures. > > =item B<echo> [I<--shell>] [I<--xml>] [I<arg>...] > with the 'at' added: Reviewed-by: Ján Tomko <jtomko@redhat.com> Jano -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.