On Thu, Jan 29, 2009 at 10:50:18PM -0500, John Levon wrote:
2675 * Returns the new domain object if the migration was successful,
2676 * or NULL in case of error. Note that the new domain object
2677 * exists in the scope of the destination connection (dconn).
This is obviously
On Fri, Jan 30, 2009 at 03:41:04PM +, Daniel P. Berrange wrote:
This is obviously impossible for xenmigr:///. As a result, virsh migrate
always returns an error code:
I'm not sure I understand why this is impossible ?
I thought the purpose of xenmigr:/// was to allow live migration
On Fri, Jan 30, 2009 at 11:04:12AM -0500, John Levon wrote:
On Fri, Jan 30, 2009 at 03:41:04PM +, Daniel P. Berrange wrote:
This is obviously impossible for xenmigr:///. As a result, virsh migrate
always returns an error code:
I'm not sure I understand why this is impossible ?
On Fri, Jan 30, 2009 at 04:19:06PM +, Daniel P. Berrange wrote:
I'm not sure I understand why this is impossible ?
I thought the purpose of xenmigr:/// was to allow live migration the
traditional way without needing a remotely accessible libvirtd. At
least, that's how we're using
On Fri, Jan 30, 2009 at 11:36:16AM -0500, John Levon wrote:
On Fri, Jan 30, 2009 at 04:19:06PM +, Daniel P. Berrange wrote:
I'm not sure I understand why this is impossible ?
I thought the purpose of xenmigr:/// was to allow live migration the
traditional way without needing a
On Fri, Jan 30, 2009 at 04:42:04PM +, Daniel P. Berrange wrote:
We're not going to *require* libvirtd to listen across the network when
there's an existing mechanism, so it sounds like we'll have to fork this
part.
You can use the xen+ssh://hostname/ URI for the destination if you
2675 * Returns the new domain object if the migration was successful,
2676 * or NULL in case of error. Note that the new domain object
2677 * exists in the scope of the destination connection (dconn).
This is obviously impossible for xenmigr:///. As a result, virsh migrate
always returns
