Hi Cole,
Thanks much for the reply. Much appreciated!
Following the leads that you provided, I found that definitions that
you mentioned in /usr/share/libvirt/cpu_map.xml
Just for kicks, I edited the definition for SandyBridge to reads as follows:
<model name='SandyBridge'>
<model name='Nehalem'/>
<feature name='pclmuldq'/>
<feature name='x2apic'/>
<feature name='tsc-deadline'/>
<feature name='xsave'/>
<feature name='avx'/>
<feature name='rdtscp'/>
</model>
That is, I substituted "Nehalem" in place of "Westmere" to result in a
new definition SandyBridge definition that is identical to the
previous definition, except that it no longer has aes support.
Surprisingly, the new definition seems to work pretty well with my
CPU.
Even so, now that I think more about it, what I really want (but
didn't realize at the time that I sent my first email) is something
more like the "-cpu host" command used when working directly with
QEMU.
After a little more digging, I stumbled onto the "virsh edit" command
and used it to configure my cpu, replacing the relevant portions with
the following:
<cpu mode='host-passthrough'>
<topology sockets='1' cores='2' threads='2'/>
</cpu>
After the edit, my VMs now now see the host CPU, as I intended. (Note
that "host-passthrough' isn't an option in my version of
Virt-Manager.)
Although I was eventually able to accomplish what I wanted to
accomplish using the "virsh edit" command, the process is far from
user-friendly.
I notice that you work at Red Hat. I have a feature request that I
hope you'll pass along to your team.
FEATURE REQUEST:
I realize that this would require significant coding, but someday I'd
like to see an "advanced" mode added to Virt-Manager, such that, next
to some of the pull down menus would be check-boxes that, when a
check-box is selected, would open a editable text-box containing the
virsh code associated with whatever can be selected via the associated
pull-down menu. I could then edit the virsh code directly (in a
friendly environment) using the existing code as a starting point.
This way, I could add features (such as host-passthrough, vfio
options, and so forth) that aren't currently selectable in
Virt-Manager. But, if I messed up, I could simply uncheck the box,
and select again from an available option.
Thanks again for the help. And please let me know if I can expand on
any of the above.
Best regards,
GizmoChicken
On Tue, Jan 27, 2015 at 1:09 PM, Cole Robinson <crobinso@xxxxxxxxxx> wrote:
> On 01/26/2015 05:11 PM, Gizmo Chicken wrote:
>> I'm not sure if this is a virt-tools issue or a QEMU issue, but...
>>
>> I hope to emulate a SandyBridge CPU on a host that has an Intel Core i3-2310M
>> CPU. However, whenever I attempt to create such guest VM (whether a Windows
>> guest or Linux guest) with an emulated SandyBridge CPU using virt-manager, I
>> get the following error: "Error starting domain: unsupported configuration:
>> guest and host CPU are not compatible: Host CPU does not provide required
>> features: aes" (Details below.)
>>
>> The i3-2310M CPU doesn't support AES (see link), and so I'm guessing that's
>> the problem. However, I can emulate a Nehalem CPU on my i3-2310M host without
>> any issues, which leads me to wonder: Why would aes be required for emulating
>> a SandyBridge on an i3-2310M, but not required for emulating a Nehalem on an
>> i3-2310M.
>>
>> Does this requirement (aes for emulating SandyBridge) originate from
>> virt-tools, QEMU or elsewhere? And whatever the origin, is there any
>> workaround, short of buying a new laptop?
>>
>
> Those CPU definitions come from libvirt (roughly by way of qemu). Here's the
> XML definition:
>
> <model name='Nehalem'>
> <model name='Penryn'/>
> <feature name='sse4.2'/>
> <feature name='popcnt'/>
> </model>
>
> <model name='Westmere'>
> <model name='Nehalem'/>
> <feature name='aes'/>
> </model>
>
> <model name='SandyBridge'>
> <model name='Westmere'/>
> <feature name='pclmuldq'/>
> <feature name='x2apic'/>
> <feature name='tsc-deadline'/>
> <feature name='xsave'/>
> <feature name='avx'/>
> <feature name='rdtscp'/>
> </model>
>
> So Nehalem doesn't have aes, but Westmere is Nehalem+aes, and Sandybridge is
> adds bits ontop of Westmere.
>
> KVM can't really emulate CPU features that the host doesn't support, so you
> never want to set your CPU model to something newer than roughly what your
> host provides. 'virsh capabilities' will show you what it thinks your CPU is.
>
> - Cole
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
