On Thu, Jun 22, 2017 at 09:28:57AM -0600, Alex Williamson wrote:
> On Thu, 22 Jun 2017 17:14:48 +0200
> Erik Skultety <eskultet@xxxxxxxxxx> wrote:
>
> > [...]
> > > >
> > > > ^this is the thing we constantly keep discussing as everyone has a slightly
> > > > different angle of view - libvirt does not implement any kind of policy,
> > > > therefore the only "configuration" would be the PCI parent placement - you say
> > > > what to do and we do it, no logic in it, that's it. Now, I don't understand
> > > > taking care of the guesswork for the user in the simplest manner possible as
> > > > policy rather as a mere convenience, be it just for developers and testers, but
> > > > even that might apparently be perceived as a policy and therefore unacceptable.
> > > >
> > > > I still stand by idea of having auto-creation as unfortunately, I sort of still
> > > > fail to understand what the negative implications of having it are - is that it
> > > > would get just unnecessarily too complex to maintain in the future that we would
> > > > regret it or that we'd get a huge amount of follow-up requests for extending the
> > > > feature or is it just that simply the interpretation of auto-create == policy?
> > >
> > > The increasing complexity of the qemu driver is a significant concern with
> > > adding policy based logic to the code. THinking about this though, if we
> > > provide the inactive node device feature, then we can avoid essentially
> > > all new code and complexity QEMU driver, and still support auto-create.
> > >
> > > ie, in the domain XML we just continue to have the exact same XML that
> > > we already have today for mdevs, but with a single new attribute
> > > autocreate=yes|no
> > >
> > > <devices>
> > > <hostdev mode='subsystem' type='mdev' model='vfio-pci' autocreate="yes">
> > > <source>
> > > <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'>
> >
> > So, just for clarification of the concept, the device with ^this UUID will have
> > had to be defined by the nodedev API by the time we start to edit the domain
> > XML in this manner in which case the only thing the autocreate=yes would do is
> > to actually create the mdev according to the nodedev config, right? Continuing
> > with that thought, if UUID doesn't refer to any of the inactive configs it will
> > be an error I suppose? What about the fact that only one vgpu type can live on
> > the GPU? even if you can successfully identify a device using the UUID in this
> > way, you'll still face the problem, that other types might be currently
> > occupying the GPU and need to be torn down first, will this be automated as
> > well in what you suggest? I assume not.
> >
> > > </source>
> > > </hostdev>
> > > </devices>
> > >
> > > In the QEMU driver, then the only change required is
> > >
> > > if (def->autocreate)
> > > virNodeDeviceCreate(dev)
> >
> > Aha, so if a device gets torn down on shutdown, we won't face the problem with
> > some other devices being active, all of them will have to be in the inactive
> > state because they got torn down during the last shutdown - that would work.
>
>
> I'm not familiar with how inactive devices would be defined in the
> nodedev API, would someone mind explaining or providing an example
> please? I don't understand where the metadata is stored that describes
> the what and where of a given UUID. Thanks,
It would basically copy what we do for domains. Currently there is
virNodeDeviceCreateXML() which takes the XML definitions and creates a
new active node device and virNodeDeviceDestroy() which takes as
argument an object of existing active node device.
We would extend the functionality with new APIs:
- virNodeDeviceCreate() which would take as argument an object of
existing inactive node device.
- virNodeDeviceDefineXML() would define the node device as inactive.
With the virNodeDeviceDefineXML() you would create a list of predefined
inactive devices which could be obtained by
virConnectListAllNodeDevices() for example.
Internally we would store XML files the same way as we do for domains,
somewhere in "/etc/libvirt/..." and like with domains the APIs would
work with these files.
In virsh terms there would be similar analogy to the domain commands:
"virsh nodedev-start" could simply map to virNodeDeviceCreate() and
would work like "virsh start" for domains and "virsh nodedev-define"
woudl map to virNodeDeviceDefineXML() and work the same way as
"virsh define". You could simply list the predefined mdev devices
using "virsh nodedev-list", get UUID of existing mdev device and use it
in a domain.
In virt-manager there could be new type of hostdev device where you
could select on of existing mdev devices from a drop-down list where
virt-manager would show nice user-friendly descriptions of the mdev
devices but under the hood it would put the UUID in the domain XML.
Pavel
>
> Alex
>
> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
