Re: [Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
On Mon, Jul 16, 2007 at 08:20:54AM -0700, Dan Smith wrote:
DB> I don't. The API should be hypervisor agnostic. Needing
to pass
DB> HV specific attributes to make it works shows we have failed.
In that case, haven't we already failed with virDomainCreate() since
it takes hypervisor-specific XML?
the goal still is to try to coerce all common behaviour into as
generic as possible APIs. My initial suggestion carried just an
extra flags int to hold options (like live vs. non-live migrations)
Maybe this won't be sufficient, Rich seems to think so, I hope
we can avoid morphing APIs we did it once (and with XML).
The real goal of unified API is that an app like virt-manager don't
need to do custom code to support new hypervisor. Right, domain
creation is unfortunately one of the parts where one need knowledge of
the underlying engine in the app, but let's try to limit it as much
as possible (and as long as the resulting API still make sense and are
usable).
Doesn't the presence of
VIR_DEVICE_RW_FORCE imply knowledge of Xen-specific behavior?
hum, no, I think when using NFS (or any other kind of stateless
networking protocol) it may be important to indicate the virtualization
layer that this can be shared because the virtualization system may
not be able to guess it.
How would you handle someone wanting to use tcp:// or ssh:// with
qemu?
don't we have qemu+ssh://host/system vs. qemu://host/system kind
of connections ? Or maybe I'm missing something...
DV
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/