libvirt users - Oct 2014 - Re: sr-vio on intel while virsh chooses rtl8139 for model type

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

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