[ovirt-devel] [vdsm] Infrastructure design for node (host) devices

[Francesco Romani]

----- Original Message -----
> From: "Martin Polednik" <mpoledni at redhat.com>
> To: devel at ovirt.org
> Sent: Tuesday, June 24, 2014 12:26:17 PM
> Subject: [ovirt-devel] [vdsm] Infrastructure design for node (host) devices
> 
> Hello,

Sorry for the late reply,
 
> 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.

This is the simplest and the most consistent solution, so I'd start from here
as first option.
Your concern is about the sheer number of (host) devices and the added traffic
to/from Engine or there is something else?

I was also trying to guess which devices should we expect in the common case,
and if it is safe to filter out by default in VDSM some devices classes;
or, to flip the side, to have whitelists.

This could possibly help us to migration work smoothly and without surprises
like an host device available on host A but not into host B.

For example, and just to my understanding, which one is the intended use case of
an host SCSI device?

This on top of any filter verbs (which someone else, probably Saggi, already mentioned,
and I like the concept).

> 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.

The drawbacks of the added complexity seems to hedge the gains, and I'm concerned
about migrations in particular, so I tend to dislike the pool concept.

I can be convinced, anyway, if you can outline the design win of the pool
concept, and especially the pain points this approach is supposed to solve.

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani