[Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
Daniel P. Berrange
berrange at redhat.com
Mon Jul 16 15:40:03 UTC 2007
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 -=|
More information about the libvir-list
mailing list