[ovirt-devel] SR-IOV feature

[Antoni Segura Puimedon]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Alona Kaplan" <alkaplan at redhat.com>, devel at ovirt.org
> Sent: Friday, October 24, 2014 12:21:00 PM
> Subject: Re: [ovirt-devel] SR-IOV feature
> 
> On 10/05/2014 07:02 AM, Alona Kaplan wrote:
> > Hi all,
> >
> > Currently SR-IOV in oVirt is only supported using vdsm-hook [1].
> > This feature will add SR-IOV support to oVirt management system (including
> > migration).
> >
> > You are more than welcome to review the feature page-
> > http://www.ovirt.org/Feature/SR-IOV
> >
> >
> > Thanks,
> > Alona.
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
> 
> Glad to see this.
> 
> some questions:
> 
> > Note: this feature is about exposing a virtualized (or VirtIO) vNic to the
> > guest, and not about exposing the PCI device to it. This restriction is
> > necessary for migration to be supported.
> 
> did not understand this sentence - are you hinting to macvtap?

Most likely macvtap, yes.

Additionally I think Martin Poledník is looking into direct sr-iov attachment
to VMs as part of the pci passthrough work he is doing.

> 
> > add/edit profile
> 
> so i gather the implementation is at profile level, which is at logical
> network level?
> how does this work exactly? can this logical network be vlan tagged or
> must be native? if vlan tagged who does the tagging for the passthrough
> device? (I see later on vf_vlan is one of the parameters to vdsm, just
> wondering how the mapping can be at host level if this is a passthrough
> device)?
> is this because the use of virtio (macvtap)?
> wouldn't it be better to support both macvtap and passthrough and just
> flag the VM as non migratable in that case?
> 
> also (and doesn't have to be in first phase) what happens if i ran out
> of hosts with sr-iov (or they failed) - can i fail back to non
> pcipassthrough profile for backup (policy question at vm level if more
> important to have sr-iov or more important it will run even without it
> since it provides a critical service, with a [scheduling] preference to
> run on sr-iov?
> (oh, i see this is in the "futures" section already.
> 
> 
> > management, display and migration properties are not relevant for the VFs
> > configuration
> 
> just wondering - any technical reason we can't put the management on a
> VF (not saying its a priority to do so)?
> 
> > sr-iov host nic management - num of VFs
> 
> I assume this is for admin to define a policy on how many VFs to use,
> based on the max as reported by getVdsCaps. worth stating that for clarity.
> 
> >  User Experience - Setup networks - Option 1
> 
> in the last picture ("Edit VFs networks and labels") - why are there
> labels here together with the networks (if labels appear at the PF level
> in the first dialog)?
> 
> iiuc, the option 2 is re-using the setup networks, where the PF will
> just be another physical interface, and networks or labels edited just
> like for regular network interfaces?
> (not sure where you are on this, but it sounds more straight
> forward/similar to existing concepts iiuc).
> 
> Question: any issues with hot plug/unplug or just expected to work normally?
> 
> Thanks,
>     Itamar
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>