[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