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? Doesn't the presence of > VIR_DEVICE_RW_FORCE imply knowledge of Xen-specific behavior? The XML is *not* hypervisor specific. There is a subtle difference is between hypervisor specific concepts, and generic concepts which may only only be relevant to a sub-set of hypervisors. > How would you handle someone wanting to use tcp:// or ssh:// with > qemu? 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. Exposing a flag VIR_CHANNEL_CLEAR, VIR_CHANNEL_SSH, VIR_CHANNEL_TLS is agnostic because it allows the same syntax to be used regardless of driver. Now some drivers may only support a subset of channel types, but that's OK. 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