On Jun 24, 2014, at 12:26 , Martin Polednik <mpole...@redhat.com> wrote:
> Hello, > > I'm actively working on getting host device passthrough (pci, usb and scsi) > exposed in VDSM, but I've encountered growing complexity of this feature. > > The devices are currently created in the same manner as virtual devices and > their reporting is done via hostDevices list in getCaps. As I implemented > usb and scsi devices, the size of this list grew almost twice - and that is > on a laptop. > > Similar problem is with the devices themselves, they are closely tied to host > and currently, engine would have to keep their mapping to VMs, reattach back > loose devices and handle all of this in case of migration. > > I would like to hear your opinion on building something like host device pool > in VDSM. The pool would be populated and periodically updated (to handle > hot(un)plugs) and VMs/engine could query it for free/assigned/possibly > problematic > devices (which could be reattached by the pool). This has added benefit of > requiring fewer libvirt calls, but a bit more complexity and possibly one > thread. > The persistence of the pool on VDSM restart could be kept in config or > constructed > from XML. best would be if we can live without too much persistence. Can we find out the actual state of things including VM mapping on vdsm startup? > > I'd need new API verbs to allow engine to communicate with the pool, > possibly leaving caps as they are and engine could detect the presence of > newer > vdsm by presence of these API verbs. The vmCreate call would remain almost the > same, only with the addition of new device for VMs (where the detach and > tracking > routine would be communicated with the pool). > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
