Re: [ovirt-devel] [vdsm] Infrastructure design for node (host) devices
----- Original Message -----
From: "Martin Polednik" <mpoledni(a)redhat.com>
To: devel(a)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