On 01/23/2012 05:12 PM, Laine Stump wrote:

In view of the discussion on SCSI passthrough, it seems to me that
this should be attached to an <interface> element:

<devices>
<interface type='hostdev'>
<source>
<address type='pci' bus='0x06' slot='0x02' function='0x0'/>
</source>
<mac address='00:16:3e:5d:c7:9e'/>
<address type='pci' .../>
</interface>
</devices>

Nice! I should have thought of this in my original proposal - it's the
logical extension of having networks of type='hostdev'. I would prefer
this as well, but it hits one of Dan's criticism's of the original
proposal (from
https://www.redhat.com/archives/libvir-list/2011-August/msg01033.html ),
so I didn't further consider using a change to <interface>:

I didn't have time now to read the whole original discussion, however...

On 08/22/2011 at 05:17 AM, Dan Berrange wrote:
 The issue I see is that if an application wants to know what
 PCI devices have been assigned to a guest, they can no longer
 just look at<hostdev>  elements. They also need to look at
<interface>  elements. If we follow this proposed model in other
 areas, we could end up with PCI devices appearing as<disks>
<controllers>  and who knows what else.

... this is exactly what we're doing for <controller>. In that case, the <source> syntax is roughly the same that you use in a SCSI pool.

See here for how it arose:

http://www.redhat.com/archives/libvir-list/2011-October/msg01298.html

Since originally proposing the <hostdev> examples for network
cards, I've switched to the opinion that this was in fact the
wrong thing todo at all. The network devices should be in the
<interface> element, so we have access to all the properties
that this element allows for.

My general view is that <hostdev> should be kept for "opaque"
device assignment where we're not caring about what capabilities
the device has. Just "blind" assignment of the PCI/USB/ISA
hardware device based on their hardware addresses.

(That's Dan speaking, not me :)).

Paolo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to