[libvirt-users] sr-vio on intel while virsh chooses rtl8139 for model type

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

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

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?

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

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

On 10/08/2014 03:35 AM, lejeczek 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
On 03/10/14 17:15, Laine Stump wrote: 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). yes, I see, that's correct, it's in network config - <forward mode='hostdev' managed='yes'> guest sees Intel 82576 Virtual Function.
On 08/10/14 15:41, Laine Stump wrote: thanks.
<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?
participants (2)
-
Laine Stump
-
lejeczek