On Mon, Jul 16, 2007 at 10:58:18AM -0500, Anthony Liguori wrote: > John Levon wrote: > >On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote: > > > > > >>>If we need to express some choice of data channel, TCP, vs SSH, vs > >>>SSL/TLS > >>>then figure out a way to expose that in the API with an hypervisor > >>>agnostic > >>>way. Exposing raw QEMU migration URIs is *not* hypervisor agnostic. > >>> > >>Why? If nothing but QEMU support ssh:// then exposing an API to do SSH > >>migration isn't really hypervisor agnostic. It's an API for QEMU. > >> > > > >You're presuming things never change (and that new backends never get > >added to libvirt!) > > > > There's a big difference between taking two implements of SSH migration, > finding the commonality, and building an abstraction verses just > modeling the KVM ssh:// URI. The chances that a second implementation > can be exposed nicely through the later is small. > > What I'd rather see is something that exposed the bits of both KVM and > Xen and then a second "agnostic" interface. For instance, for KVM you > may have: > > virDomainMigrateKVM(..., URI); > > For Xen you'd have: > > virDomainMigrateXen(..., hostname, port); I don't see the point in having separate methods for those when Xen's hostname+port can be formatted as a URI too. > But then you'd also have: > > virDomainMigrate(dom, connPtr); So perhaps we should think about 2 possible APIs: - One based on a URI string - One based on a pre-existing virConnectPtr Or, have 1 API, and have the URI string optional and virConnectPtr be compulsory ? Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list