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 -=|