[virt-tools-list] Error when emulating SandyBridge on i3-2310M host

Cole Robinson crobinso at redhat.com
Wed Jan 28 14:16:51 UTC 2015


On 01/28/2015 12:04 AM, Gizmo Chicken wrote:
> 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.
> 

Editing this is definitely not recommended, can only cause confusion if you
have future bug reports.

> 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.
> 

You can do it with modern virt-manager as well as of 1.1.0, just enter the
value host-passthrough in the CPU model box in the UI. We hide it because it's
not the recommended libvirt mode and can cause migration incompatibilities,
but if the VM never leaves your host machine it's fine.

Also with the virt-xml tool, you can do this in one shot from the command line
like:

virt-xml $vmname --edit --cpu host-passthrough,clearxml=yes --confirm

> 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.
> 

Thanks for the suggestion, but I don't think we will add that to the UI.
Adding 'advanced mode' like this, while convenient for people that know what
they are doing, has a user confusion cost for everyone else. And it isn't much
to ask advanced users to just open a terminal and do the advanced bits by hand.

The other thing to look at is the virt-xml tool (part of the
virt-manager/virt-install suite). It's goal is to allow changing every XML
value via the command line.

- Cole




More information about the virt-tools-list mailing list