On 08/10/14 08:35, lejeczek wrote:
On 03/10/14 17:15, Laine Stump wrote:
hi everybody
I'd presume virsh makes the best possible choice, right? It is that just seems bit... odd having realtek in guest and Intel's VF on host, no? This can safely be ignored - in the case of an SRIOV VF
On 10/03/2014 11:38 AM, lejeczek wrote: that is assigned to the guest using PCI passthrough device assignment, the "model" attribute is meaningless, but libvirt will always fill in the default value (which is rtl8139) in the XML to prevent surprises if the default emulated NIC model ever changes.
(I am assuming that you're using either <interface type='hostdev'> or <interface type='network'> pointint to a network that has <forward mode='hostdev'>. If you are instead using "type='direct'" or a network with "<forward mode='bridge|passthrough|vepa'>" then the model *does* matter, and you probably want to set it to "virtio", which is *not* the default because not all guest OSes have a virtio network driver by default (e.g. MS Windows)) I don't use forward (unless libvirt does that for me) but I have a pool like this one: <interface type='network'> <mac address='52:54:00:51:af:0e'/> <source network='passpool-enp2s0f0'/> <model type='rtl8139'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> In a win 2008 guest OS is missing drivers for this device and I wonder what is that it gets?
answering my own question a line above - seems guest needs driver of the host's real device, in my case Intel's.
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users