[Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)

[Daniel Veillard]

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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/