On Jun 24, 2014, at 12:26 , Martin Polednik <mpoledni(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel