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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users