cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrija Panic <andrija.pa...@gmail.com>
Subject Re: KVM Custom CPU-Model
Date Tue, 30 Oct 2018 12:29:36 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message