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?

On 03/10/14 17:15, Laine Stump wrote: > On 10/03/2014 11:38 AM, lejeczek 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 > 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?

> _______________________________________________ libvirt-users mailing list libvirt-users(a)redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users

On 10/08/2014 03:35 AM, lejeczek wrote: > On 03/10/14 17:15, Laine Stump wrote: >> On 10/03/2014 11:38 AM, lejeczek 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 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: This does not show the details of your network. For that, you would need to get the output of "virsh net-dumpxml passpool-enp2s0f0". If, as you have indicated in your next message, the guest sees the same hardware type as what is physically on the host, then you are using <forward mode='hostdev'> in your network (and no, libvirt would not "do that for you", you or someone else would have needed to configure the network "passpool-enp2s0f0" in that way).

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