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