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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list