[Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)

[Daniel P. Berrange]

On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >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.
> 
> 
> Why?  If nothing but QEMU support ssh:// then exposing an API to do SSH 
> migration isn't really hypervisor agnostic.  It's an API for QEMU.
> 
> If you don't expose raw URIs, then you can never support pluggable 
> migration transports which I will implement in the not to distant future.

Its depends where you need to expose it. For any single deployment of
do you need to be able to use all possible transports ? I think that
some people will choose SSH, others will choose SSL, other's something
else again, but they aren't all neccessarily used all the time. So it
may be sufficient to specify which migration scheme to use per host.
So libvirt can make use of all possible transports, without having to
expose this to every single application using the API.

> I think there's a balance between being hypervisor agnostic and only 
> supporting the least common denominator.  Whenever there's a possibility 
> to be common, I think libvirt should strive to provide a common 
> interface but I still think it's important to unique features of the 
> particular virtualization solution.

Sure, but making use of all available capabilities in libvirt doesn't mean
we have to expose them all in the API - some can be used 'behind the scenes'
without apps needing to care about them.

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