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

[Daniel P. Berrange]

On Mon, Jul 16, 2007 at 11:40:30AM -0400, Daniel Veillard 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?
> 
>  the goal still is to try to coerce all common behaviour into as
> generic as possible APIs. My initial suggestion carried just an
> extra flags int to hold options (like live vs. non-live migrations)
> Maybe this won't be sufficient, Rich seems to think so, I hope
> we can avoid morphing APIs we did it once (and with XML).
>  The real goal of unified API is that an app like virt-manager don't
> need to do custom code to support new hypervisor. Right, domain
> creation is unfortunately one of the parts where one need knowledge of
> the underlying engine in the app, but let's try to limit it as much
> as possible (and as long as the resulting API still make sense and are
> usable).

The 'capabilities' XML provides a way for virt-manager to figure out
various bits of metadata for domain creation in a hypervisor agnostic
manner. We just haven't updated virt-manager to use it yet. And again
the difference is between hypervisor specific data representation (we
avoid that), and  hypervisor agnostic representation, but with varying
sets of allowed data. The capabilities API allows you to determine the
allowed data per driver when creating a guest.

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