You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by "Stock, Alexander" <Al...@itelligence.de> on 2018/10/30 11:41:43 UTC
KVM Custom CPU-Model
Hi all,
maybe someone can help me with my KVM related questions.
At the moment we want to add cpu flags to the standard qemu64 CPU-Model in a testcluster.
For this we tried the following configuration:
guest.cpu.mode=custom
guest.cpu.model=qemu64
guest.cpu.features=sse4.2 sse4.1
But ended up with the following error message:
org.libvirt.LibvirtException: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: svm
When we use kvm64 instead of qemu64 the start of the vm is working and the needed flags are available.
Has someone experience in using kvm64 over qemu64 and are there some drawbacks with it?
Also I guess the standard CPU-Model which comes from guest.cpu.mode=host-model is qemu64.
Why is it working with mode host-model and not with custom. Is there some libvirt magic involved?
Alexander Stock
Architect
Cloud Implementation
[pic23646]
itelligence Global Managed Services GmbH ▪ Philipp-Reis-Straße 2 ▪ 02625 Bautzen
phone: +49 3591 52 53 1398 ▪fax: +49 3591 52 53 9999
e-mail: alexander.stock@itelligence.com
www.itelligencegroup.com<http://www.itelligencegroup.com/>
itelligence Global Managed Services GmbH ▪ Sitz: Bautzen ▪ Handelsregister: Amtsgericht Dresden, HRB 21356
Geschäftsführer: Mirko Kruse ▪ André Walter
Re: KVM Custom CPU-Model
Posted by Andrija Panic <an...@gmail.com>.
I haven't played with host-model, but manual says (
http://docs.cloudstack.apache.org/en/4.11.1.0/installguide/hypervisor/kvm.html
)
"
host-model: libvirt will identify the CPU model in
/usr/share/libvirt/cpu_map.xml which most closely matches the host, and
then request additional CPU flags to complete the match. This should give
close to maximum functionality/performance, which maintaining good
reliability/compatibility if the guest is migrated to another host with
slightly different host CPUs
"
This makes me believe that in my case (as from previous email) it
would/should use "IvyBridge" and not qemu64 as CPU, plus some more flags..
That is easy to test - switch to that one - restart agent, and start VM
while choosing to start it on that particular host (i.e. have running VM,
stop it, and start on particular host).
Hope that helps
Andrija
On Tue, 30 Oct 2018 at 17:00, Stock, Alexander <
Alexander.Stock@itelligence.de> wrote:
> Hi Andrija,
>
> thank you for your quick answer.
> I already checked out the custom CPU-Model of our CPU generation as plan b.
> This would also work for us.
>
> The question for me was just why is qemu64 working with
> guest.cpu.mode=host-model and not working with guest.cpu.mode=custom.
>
> BR
> Alexander
>
> -----Ursprüngliche Nachricht-----
> Von: Andrija Panic <an...@gmail.com>
> Gesendet: Dienstag, 30. Oktober 2018 13:30
> An: users <us...@cloudstack.apache.org>
> Betreff: Re: KVM Custom CPU-Model
>
> Hi Alex,
>
> based on CPU_map.xml, qemu64 CPU model requires (presents to Guest) the
> SVM flag, which is the AMD things as you know (not sure why though...)
>
> Here is the info:
> root@ix1-c7-4:~# cat /usr/share/libvirt/cpu_map.xml| grep qemu64 -A36
> <model name='qemu64'>
> <!-- These are supported only by TCG. KVM supports them only if the
> host does. So we leave them out:
>
> <feature name='abm'/>
> <feature name='lahf_lm'/>
> <feature name='popcnt'/>
> <feature name='sse4a'/>
> -->
> <feature name='apic'/>
> <feature name='clflush'/>
> <feature name='cmov'/>
> <feature name='cx16'/>
> <feature name='cx8'/>
> <feature name='de'/>
> <feature name='fpu'/>
> <feature name='fxsr'/>
> <feature name='lm'/>
> <feature name='mca'/>
> <feature name='mce'/>
> <feature name='mmx'/>
> <feature name='msr'/>
> <feature name='mtrr'/>
> <feature name='nx'/>
> <feature name='pae'/>
> <feature name='pat'/>
> <feature name='pge'/>
> <feature name='pni'/>
> <feature name='pse'/>
> <feature name='pse36'/>
> <feature name='sep'/>
> <feature name='sse'/>
> <feature name='sse2'/>
> <feature name='svm'/>
> <feature name='syscall'/>
> <feature name='tsc'/>
> </model>
>
> That being said, I would suggest that you consider using latest named CPU
> model which corresponds to your CPU - I assume you have identical/same CPUs
> in the cluster - and whatever is the vCPU model of the VM - it has to be
> supported by all physical hosts (same CPU flags in general) in order to
> support Live MIgrations of VMS across hosts.
>
> For example, in my test cluster I have following CPU model Intel(R)
> Xeon(R) CPU E5-2650 v2 @ 2.60GHz - which is (check on Intel site) and
> "IvyBridge"
> code name.
>
> So in agent.properties I have following (in qemu 2.5)
>
> guest.cpu.model=IvyBridge
> guest.cpu.mode=custom
>
> But previously with Qemu 2.2 there was no support for IvyBridge named CPU
> model, so I used Sandy Bridge - so you can choose your own here and perhaps
> add some more flags if you want.
> QEmu 2.2
>
> guest.cpu.model=SandyBridge
> guest.cpu.mode=custom
>
> If you have i.e. mixed CPU models, check the "oldest one" and target that
> one in you agent.properties across all nodes.
>
> Cheers,
> Andrija
>
> On Tue, 30 Oct 2018 at 12:42, Stock, Alexander <
> Alexander.Stock@itelligence.de> wrote:
>
> > Hi all,
> >
> >
> >
> > maybe someone can help me with my KVM related questions.
> >
> > At the moment we want to add cpu flags to the standard qemu64
> > CPU-Model in a testcluster.
> >
> >
> >
> > For this we tried the following configuration:
> >
> >
> >
> > guest.cpu.mode=custom
> >
> > guest.cpu.model=qemu64
> >
> >
> > guest.cpu.features=sse4.2 sse4.1
> >
> >
> >
> > But ended up with the following error message:
> >
> > *org.libvirt.LibvirtException: unsupported configuration: guest and
> > host CPU are not compatible: Host CPU does not provide required
> > features: svm*
> >
> >
> >
> > When we use *kvm64* instead of *qemu64* the start of the vm is working
> > and the needed flags are available.
> >
> > Has someone experience in using kvm64 over qemu64 and are there some
> > drawbacks with it?
> >
> > Also I guess the standard CPU-Model which comes from
> > guest.cpu.mode=host-model is qemu64.
> >
> > Why is it working with mode host-model and not with custom. Is there
> > some libvirt magic involved?
> >
> >
> >
> > *Alexander Stock*
> >
> > Architect
> > Cloud Implementation
> >
> >
> >
> > [image: pic23646]
> >
> >
> >
> > itelligence Global Managed Services GmbH ▪ Philipp-Reis-Straße 2 ▪
> > 02625 Bautzen
> >
> > phone: +49 3591 52 53 1398 ▪fax: +49 3591 52 53 9999
> >
> > e-mail: alexander.stock@itelligence.com
> >
> >
> >
> > www.itelligencegroup.com
> >
> >
> >
> > itelligence Global Managed Services GmbH ▪ Sitz: Bautzen ▪
> > Handelsregister: Amtsgericht Dresden, HRB 21356
> >
> > Geschäftsführer: Mirko Kruse ▪ André Walter
> >
> >
> >
>
>
> --
>
> Andrija Panić
>
--
Andrija Panić
AW: KVM Custom CPU-Model
Posted by "Stock, Alexander" <Al...@itelligence.de>.
Hi Andrija,
thank you for your quick answer.
I already checked out the custom CPU-Model of our CPU generation as plan b.
This would also work for us.
The question for me was just why is qemu64 working with guest.cpu.mode=host-model and not working with guest.cpu.mode=custom.
BR
Alexander
-----Ursprüngliche Nachricht-----
Von: Andrija Panic <an...@gmail.com>
Gesendet: Dienstag, 30. Oktober 2018 13:30
An: users <us...@cloudstack.apache.org>
Betreff: Re: KVM Custom CPU-Model
Hi Alex,
based on CPU_map.xml, qemu64 CPU model requires (presents to Guest) the SVM flag, which is the AMD things as you know (not sure why though...)
Here is the info:
root@ix1-c7-4:~# cat /usr/share/libvirt/cpu_map.xml| grep qemu64 -A36
<model name='qemu64'>
<!-- These are supported only by TCG. KVM supports them only if the
host does. So we leave them out:
<feature name='abm'/>
<feature name='lahf_lm'/>
<feature name='popcnt'/>
<feature name='sse4a'/>
-->
<feature name='apic'/>
<feature name='clflush'/>
<feature name='cmov'/>
<feature name='cx16'/>
<feature name='cx8'/>
<feature name='de'/>
<feature name='fpu'/>
<feature name='fxsr'/>
<feature name='lm'/>
<feature name='mca'/>
<feature name='mce'/>
<feature name='mmx'/>
<feature name='msr'/>
<feature name='mtrr'/>
<feature name='nx'/>
<feature name='pae'/>
<feature name='pat'/>
<feature name='pge'/>
<feature name='pni'/>
<feature name='pse'/>
<feature name='pse36'/>
<feature name='sep'/>
<feature name='sse'/>
<feature name='sse2'/>
<feature name='svm'/>
<feature name='syscall'/>
<feature name='tsc'/>
</model>
That being said, I would suggest that you consider using latest named CPU model which corresponds to your CPU - I assume you have identical/same CPUs in the cluster - and whatever is the vCPU model of the VM - it has to be supported by all physical hosts (same CPU flags in general) in order to support Live MIgrations of VMS across hosts.
For example, in my test cluster I have following CPU model Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz - which is (check on Intel site) and "IvyBridge"
code name.
So in agent.properties I have following (in qemu 2.5)
guest.cpu.model=IvyBridge
guest.cpu.mode=custom
But previously with Qemu 2.2 there was no support for IvyBridge named CPU model, so I used Sandy Bridge - so you can choose your own here and perhaps add some more flags if you want.
QEmu 2.2
guest.cpu.model=SandyBridge
guest.cpu.mode=custom
If you have i.e. mixed CPU models, check the "oldest one" and target that one in you agent.properties across all nodes.
Cheers,
Andrija
On Tue, 30 Oct 2018 at 12:42, Stock, Alexander < Alexander.Stock@itelligence.de> wrote:
> Hi all,
>
>
>
> maybe someone can help me with my KVM related questions.
>
> At the moment we want to add cpu flags to the standard qemu64
> CPU-Model in a testcluster.
>
>
>
> For this we tried the following configuration:
>
>
>
> guest.cpu.mode=custom
>
> guest.cpu.model=qemu64
>
>
> guest.cpu.features=sse4.2 sse4.1
>
>
>
> But ended up with the following error message:
>
> *org.libvirt.LibvirtException: unsupported configuration: guest and
> host CPU are not compatible: Host CPU does not provide required
> features: svm*
>
>
>
> When we use *kvm64* instead of *qemu64* the start of the vm is working
> and the needed flags are available.
>
> Has someone experience in using kvm64 over qemu64 and are there some
> drawbacks with it?
>
> Also I guess the standard CPU-Model which comes from
> guest.cpu.mode=host-model is qemu64.
>
> Why is it working with mode host-model and not with custom. Is there
> some libvirt magic involved?
>
>
>
> *Alexander Stock*
>
> Architect
> Cloud Implementation
>
>
>
> [image: pic23646]
>
>
>
> itelligence Global Managed Services GmbH ▪ Philipp-Reis-Straße 2 ▪
> 02625 Bautzen
>
> phone: +49 3591 52 53 1398 ▪fax: +49 3591 52 53 9999
>
> e-mail: alexander.stock@itelligence.com
>
>
>
> www.itelligencegroup.com
>
>
>
> itelligence Global Managed Services GmbH ▪ Sitz: Bautzen ▪
> Handelsregister: Amtsgericht Dresden, HRB 21356
>
> Geschäftsführer: Mirko Kruse ▪ André Walter
>
>
>
--
Andrija Panić
Re: KVM Custom CPU-Model
Posted by Andrija Panic <an...@gmail.com>.
Hi Alex,
based on CPU_map.xml, qemu64 CPU model requires (presents to Guest) the SVM
flag, which is the AMD things as you know (not sure why though...)
Here is the info:
root@ix1-c7-4:~# cat /usr/share/libvirt/cpu_map.xml| grep qemu64 -A36
<model name='qemu64'>
<!-- These are supported only by TCG. KVM supports them only if the
host does. So we leave them out:
<feature name='abm'/>
<feature name='lahf_lm'/>
<feature name='popcnt'/>
<feature name='sse4a'/>
-->
<feature name='apic'/>
<feature name='clflush'/>
<feature name='cmov'/>
<feature name='cx16'/>
<feature name='cx8'/>
<feature name='de'/>
<feature name='fpu'/>
<feature name='fxsr'/>
<feature name='lm'/>
<feature name='mca'/>
<feature name='mce'/>
<feature name='mmx'/>
<feature name='msr'/>
<feature name='mtrr'/>
<feature name='nx'/>
<feature name='pae'/>
<feature name='pat'/>
<feature name='pge'/>
<feature name='pni'/>
<feature name='pse'/>
<feature name='pse36'/>
<feature name='sep'/>
<feature name='sse'/>
<feature name='sse2'/>
<feature name='svm'/>
<feature name='syscall'/>
<feature name='tsc'/>
</model>
That being said, I would suggest that you consider using latest named CPU
model which corresponds to your CPU - I assume you have identical/same CPUs
in the cluster - and whatever is the vCPU model of the VM - it has to be
supported by all physical hosts (same CPU flags in general) in order to
support Live MIgrations of VMS across hosts.
For example, in my test cluster I have following CPU model Intel(R) Xeon(R)
CPU E5-2650 v2 @ 2.60GHz - which is (check on Intel site) and "IvyBridge"
code name.
So in agent.properties I have following (in qemu 2.5)
guest.cpu.model=IvyBridge
guest.cpu.mode=custom
But previously with Qemu 2.2 there was no support for IvyBridge named CPU
model, so I used Sandy Bridge - so you can choose your own here and perhaps
add some more flags if you want.
QEmu 2.2
guest.cpu.model=SandyBridge
guest.cpu.mode=custom
If you have i.e. mixed CPU models, check the "oldest one" and target that
one in you agent.properties across all nodes.
Cheers,
Andrija
On Tue, 30 Oct 2018 at 12:42, Stock, Alexander <
Alexander.Stock@itelligence.de> wrote:
> Hi all,
>
>
>
> maybe someone can help me with my KVM related questions.
>
> At the moment we want to add cpu flags to the standard qemu64 CPU-Model in
> a testcluster.
>
>
>
> For this we tried the following configuration:
>
>
>
> guest.cpu.mode=custom
>
> guest.cpu.model=qemu64
>
>
> guest.cpu.features=sse4.2 sse4.1
>
>
>
> But ended up with the following error message:
>
> *org.libvirt.LibvirtException: unsupported configuration: guest and host
> CPU are not compatible: Host CPU does not provide required features: svm*
>
>
>
> When we use *kvm64* instead of *qemu64* the start of the vm is working
> and the needed flags are available.
>
> Has someone experience in using kvm64 over qemu64 and are there some
> drawbacks with it?
>
> Also I guess the standard CPU-Model which comes from guest.cpu.mode=host-model
> is qemu64.
>
> Why is it working with mode host-model and not with custom. Is there some
> libvirt magic involved?
>
>
>
> *Alexander Stock*
>
> Architect
> Cloud Implementation
>
>
>
> [image: pic23646]
>
>
>
> itelligence Global Managed Services GmbH ▪ Philipp-Reis-Straße 2 ▪ 02625
> Bautzen
>
> phone: +49 3591 52 53 1398 ▪fax: +49 3591 52 53 9999
>
> e-mail: alexander.stock@itelligence.com
>
>
>
> www.itelligencegroup.com
>
>
>
> itelligence Global Managed Services GmbH ▪ Sitz: Bautzen ▪
> Handelsregister: Amtsgericht Dresden, HRB 21356
>
> Geschäftsführer: Mirko Kruse ▪ André Walter
>
>
>
--
Andrija Panić