Start of an upstream discussion to determine what this should look like:

https://www.redhat.com/archives/libvir-list/2011-January/msg00092.html

A patch has been posted upstream:

https://www.redhat.com/archives/libvir-list/2011-January/msg00521.html

In this version, the setting will look like this:



<domain>
  ...
  <interface ... >
    ...
    <model type='virtio'/>
    <driver name='vhost|qemu'/>
    ...
  </interface>

vhost == 'use vhost mode or fail the guest startup'
qemu == 'don't use vhost even if it's available'
nothing specified == 'use vhost if you can, otherwise fall back to user mode'

Can we have a flag to specify
'use vhost if you can, otherwise fall back to user mode'
?
This way there's a way to force this behaviour even if libvirt
default changes.

A newer version of the above patch was committed upstream, and has been posted to rhvirt-patches:

commit 175077fd707db6ad87d6e2a079e82bc290ac2421
Author: Laine Stump <laine>
Date:   Tue Jan 11 23:18:49 2011 -0500

    Add XML config switch to enable/disable vhost-net support
    
    The existing libvirt support for the vhost-net backend to the virtio
    network driver happens automatically - if the vhost-net device is
    available, it is always enabled, otherwise the standard userland
    virtio backend is used.
    
    This patch makes it possible to force whether or not vhost-net is used
    with a bit of XML. Adding a <driver> element to the interface XML, eg:
    
         <interface type="network">
           <model type="virtio"/>
           <driver name="vhost"/>
    
    will force use of vhost-net (if it's not available, the domain will
    fail to start). if driver name="qemu", vhost-net will not be used even
    if it is available.
    
    If there is no <driver name='xxx'/> in the config, libvirt will revert
    to the pre-existing automatic behavior - use vhost-net if it's
    available, and userland backend if vhost-net isn't available.

I suspect that currently, libvirt cannot allow testing vhost to non-vhost migration. That has to wait for vswitch or whatever that's called, right?

To Comment 5: why not?
qemu allows  vhost to non-vhost migration so why not libvirt?

Michael is correct - there should be nothing stopping a vhost to non-vhost migration, as long as qemu (and the vhost-net module) allows it. That is, as long as the XML hasn't set it explicitly on (in which case it will fail if the destination host doesn't have vhost enabled). As long as you leave it at the default (nothing specified), vhost will be used if available on migration, otherwise not.

(In reply to comment #9 and comment 6)
What I meant in comment 5 is that (I suspect that) you cannot specify that if you use vhost-net at the source, you cannot disable it at the destination (unless the destination's admin removes the kernel module). If that's enough for Michael, I'm good.

Verified it on RHEL6 server with the following components:
libvirt-0.8.7-2.el6
qemu-kvm-0.12.1.2-2.129.el6
kernel-2.6.32-94.el6

1 define a guest with the following xml:
...
    <interface type='network'>
      <mac address='52:54:00:1e:8e:ab'/>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='vhost'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
...

2 check vhost-net mod
# lsmod|grep vhost

3 start the guest
# virsh start rhel6
error: Failed to start domain rhel6
error: unsupported configuration: vhost-net was requested for an interface, but is unavailable

4 enable vhost-net
# modprobe vhost-net

# lsmod|grep vhost
vhost_net              28555  1 
macvtap                 7867  1 vhost_net
tun                    16953  3 vhost_net

5 start the guest
# virsh start rhel6
Domain rhel6 started

6 check qemu command line option
# ps -edf|grep qemu
qemu     27725     1 14 17:04 ?        00:00:00 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6 -uuid 816605ff-d6b2-db24-57a1-bf872f4c40d5 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/rhel6.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/rhel6-1.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1e:8e:ab,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

7 shutdown the guest and using the following xml:
    <interface type='network'>
      <mac address='52:54:00:1e:8e:ab'/>
      <source network='default'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <driver name='qemu'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

8 start the guest
# virsh start rhel6
Domain rhel6 started

9 check qemu command line option
# ps -edf|grep qemu
qemu     27304     1 12 16:59 ?        00:00:27 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6 -uuid 816605ff-d6b2-db24-57a1-bf872f4c40d5 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/rhel6.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/rhel6-1.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=24,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:1e:8e:ab,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

To comment 10
To be more exact: if you force vhost on with vhost=on,
this means 'run with vhost or fail'.
Then you can not run if vhost-net module is not loaded.
And since this is the guest property,
then an attempt to migrate to another box which does not
have the vhost-net module loaded will also fail.

Unfortunately, this patch is incomplete - bug 683276 points out that we forgot to hook up <driver name='vhost'/> handling during hot-plug.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html