cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stock, Alexander" <Alexander.St...@itelligence.de>
Subject AW: KVM Custom CPU-Model
Date Tue, 30 Oct 2018 16:00:00 GMT
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 <andrija.panic@gmail.com> 
Gesendet: Dienstag, 30. Oktober 2018 13:30
An: users <users@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ć
Mime
View raw message