[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- From: "Daniel P. Berrange" <berrange redhat com>
- To: Anthony Liguori <anthony codemonkey ws>
- Cc: LibVirt-Dev <Libvir-list redhat com>, Dan Smith <danms us ibm com>
- Subject: Re: [Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- Date: Mon, 16 Jul 2007 18:28:37 +0100
On Mon, Jul 16, 2007 at 10:58:18AM -0500, Anthony Liguori wrote:
> John Levon wrote:
> >On Mon, Jul 16, 2007 at 10:47:59AM -0500, Anthony Liguori wrote:
> >
> >
> >>>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.
> >>
> >
> >You're presuming things never change (and that new backends never get
> >added to libvirt!)
> >
>
> There's a big difference between taking two implements of SSH migration,
> finding the commonality, and building an abstraction verses just
> modeling the KVM ssh:// URI. The chances that a second implementation
> can be exposed nicely through the later is small.
>
> What I'd rather see is something that exposed the bits of both KVM and
> Xen and then a second "agnostic" interface. For instance, for KVM you
> may have:
>
> virDomainMigrateKVM(..., URI);
>
> For Xen you'd have:
>
> virDomainMigrateXen(..., hostname, port);
I don't see the point in having separate methods for those when Xen's
hostname+port can be formatted as a URI too.
> But then you'd also have:
>
> virDomainMigrate(dom, connPtr);
So perhaps we should think about 2 possible APIs:
- One based on a URI string
- One based on a pre-existing virConnectPtr
Or, have 1 API, and have the URI string optional and virConnectPtr be
compulsory ?
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 -=|
- References:
- [Libvir] [PATCH 0/2] virDomainMigrate (for discussion only!)
- [Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- Re: [Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- Re: [Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- Re: [Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- Re: [Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- [Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- Re: [Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
- Re: [Libvir] Re: [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]