On Mon, Jul 16, 2007 at 03:57:19PM -0400, Daniel Veillard wrote:
> On Mon, Jul 16, 2007 at 06:52:15PM +0100, Richard W.M. Jones wrote:
> > Daniel P. Berrange wrote:
> > >On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> > >>Dan Berrange wrote:
> > >>>I don't see the point in thi
On Mon, Jul 16, 2007 at 06:52:15PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> >>Dan Berrange wrote:
> >>>I don't see the point in this. Libvirt already knows both hostnames
> >>>of the source & destination.
>
Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
Dan Berrange wrote:
I don't see the point in this. Libvirt already knows both hostnames
of the source & destination.
It's really very hard for libvirt to accurately determine the hostname
of the desti
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> Dan Berrange wrote:
> >I don't see the point in this. Libvirt already knows both hostnames
> >of the source & destination.
>
> It's really very hard for libvirt to accurately determine the hostname
> of the destination as seen
On Mon, Jul 16, 2007 at 03:43:48PM +0100, Richard W.M. Jones wrote:
> Dan Smith wrote:
> >RJ> * Params is a linked list of hypervisor-specific parameters. Each
> >RJ> * element is a virMigrateParamPtr containing the following fields:
> >RJ> * name Parameter name being set.
> >RJ
John Levon wrote:
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
* @resource: (optional) specify resource limit in Mbps
*
* The maximum bandwidth (in Mbps) that will be used to do migration
* can be specified with the resource parameter. If set to 0,
* libvirt will
On Mon, Jul 16, 2007 at 05:09:28PM +0100, Richard W.M. Jones wrote:
> >Will there be another way to find this out? It would be unfortunate if
> >the only way was to actually attempt it.
>
> virConnectGetCapabilities should return something to say whether this is
> supported. I'll add that to my
John Levon wrote:
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
* @resource: (optional) specify resource limit in Mbps
*
* The maximum bandwidth (in Mbps) that will be used to do migration
* can be specified with the resource parameter. If set to 0,
* libvirt will ch
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> * @resource: (optional) specify resource limit in Mbps
> *
> * The maximum bandwidth (in Mbps) that will be used to do migration
> * can be specified with the resource parameter. If set to 0,
> * libvirt will choose a suit
Dan Berrange wrote:
I don't see the point in this. Libvirt already knows both hostnames
of the source & destination.
It's really very hard for libvirt to accurately determine the hostname
of the destination as seen from the source. Consider the case where you
have a multi-homed host with a g
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
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-speci
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-speci
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
On Mon, Jul 16, 2007 at 07:22:27AM -0700, Dan Smith wrote:
> RJ> * Params is a linked list of hypervisor-specific parameters. Each
> RJ> * element is a virMigrateParamPtr containing the following fields:
> RJ> * name Parameter name being set.
> RJ> * value A unio
On Mon, Jul 16, 2007 at 01:47:38PM +0100, Richard W.M. Jones wrote:
> To cut to the chase, this is the proposed additional libvirt call to
> support migration. Please also read my explanation below.
>
> /**
> * virDomainMigrate:
> * @domain: a domain object
> * @dconn: destination host (a con
Dan Smith wrote:
RJ> * Params is a linked list of hypervisor-specific parameters. Each
RJ> * element is a virMigrateParamPtr containing the following fields:
RJ> * name Parameter name being set.
RJ> * value A union expressing the value.
RJ> * value.strv
RJ> * Params is a linked list of hypervisor-specific parameters. Each
RJ> * element is a virMigrateParamPtr containing the following fields:
RJ> * name Parameter name being set.
RJ> * value A union expressing the value.
RJ> * value.strv A string valu
To cut to the chase, this is the proposed additional libvirt call to
support migration. Please also read my explanation below.
/**
* virDomainMigrate:
* @domain: a domain object
* @dconn: destination host (a connection object)
* @flags: flags
* @dname: (optional) rename domain to this at d
19 matches
Mail list logo
