9:50 p.m.
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 an error code:
# virsh migrate --live domu-220 xen:/// interpol
18:44:40.974: error : Domain not found: xenUnifiedDomainLookupByName
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
thewhip:xend # echo $?
1
Since virDomainLookupByName() returns NULL. I will request again, can I
remove the 'error' code from xenUnifiedDomainLookupByName?
More importantly, how can this be fixed? Perhaps we can return 'domain'
instead of 'ddomain' if a migrateuri was specified? Also, where does
'domain' get freed in the case where 'ddomain' is returned?
Wish I'd spotted this when it went in :(
regards
john
9:41 a.m.
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 impossible for xenmigr:///. As a result, virsh migrate
always returns an error code:
I'm not sure I understand why this is impossible ?
You always have two virConnectPtr objects - one of the source, and
one for the destination host. The reason for the optional URI is to cope
with the scenario where the clients view of what the destination hostname
is, has to be different from the source host's view.
eg, if a node is multi-homed, 10.0.0.1 and 192.168.1.1
Then the libvirt client might connect to source and estination
hosts with
xen://10.0.0.1/ (source)
xen://10.0.0.2/ (dest)
But, the source & dest may only be able to talk to each other
using 192.168.1.1/.2, so yu'd have to give a extra URI for
xenmigr://192.168.1.2/ so the source host used the correct
network address for the actual migration.
Either way, the libvirt client can get the resulting domain
object, from the destination hosts virConnectPtr instance
# virsh migrate --live domu-220 xen:/// interpol
18:44:40.974: error : Domain not found: xenUnifiedDomainLookupByName
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
thewhip:xend # echo $?
1
Since virDomainLookupByName() returns NULL. I will request again, can I
remove the 'error' code from xenUnifiedDomainLookupByName?
I'm not sure why it returns NULL there ?!?!
More importantly, how can this be fixed? Perhaps we can return
'domain'
instead of 'ddomain' if a migrateuri was specified? Also, where does
'domain' get freed in the case where 'ddomain' is returned?
The passed in 'domain' object is owned by the caller, so the caller is
responsible for free'ing it once its done using it. Likewise the returned
ddomain object should also be free'd by the caller when it no longer
requires it
Danoel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:04 a.m.
On Fri, Jan 30, 2009 at 03:41:04PM +0000, 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 the
traditional way without needing a remotely accessible libvirtd. At
least, that's how we're using it. If it's the intention of libvirt that
you must always have a listening remote API, then we'll have to work out
a private fix for our tree.
> # virsh migrate --live domu-220 xen:/// interpol
> 18:44:40.974: error : Domain not found: xenUnifiedDomainLookupByName
> libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
> libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
>
> thewhip:xend # echo $?
> 1
>
> Since virDomainLookupByName() returns NULL. I will request again, can I
> remove the 'error' code from xenUnifiedDomainLookupByName?
I'm not sure why it returns NULL there ?!?!
xen:/// (the local source host) no longer has the domain, since it moved
to interpol.
> More importantly, how can this be fixed? Perhaps we can return
'domain'
> instead of 'ddomain' if a migrateuri was specified? Also, where does
> 'domain' get freed in the case where 'ddomain' is returned?
The passed in 'domain' object is owned by the caller, so the caller is
responsible for free'ing it once its done using it. Likewise the returned
ddomain object should also be free'd by the caller when it no longer
requires it
Yuck, so that won't do. Perhaps we could duplicate domain and pass that
back.
regards
john
10:19 a.m.
On Fri, Jan 30, 2009 at 11:04:12AM -0500, John Levon wrote:
On Fri, Jan 30, 2009 at 03:41:04PM +0000, 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 the
traditional way without needing a remotely accessible libvirtd. At
least, that's how we're using it. If it's the intention of libvirt that
you must always have a listening remote API, then we'll have to work out
a private fix for our tree.
> > # virsh migrate --live domu-220 xen:/// interpol
> > 18:44:40.974: error : Domain not found: xenUnifiedDomainLookupByName
> > libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
> > libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName
> >
> > thewhip:xend # echo $?
> > 1
> >
> > Since virDomainLookupByName() returns NULL. I will request again, can I
> > remove the 'error' code from xenUnifiedDomainLookupByName?
>
> I'm not sure why it returns NULL there ?!?!
xen:/// (the local source host) no longer has the domain, since it moved
to interpol.
Yeah, so you've passed invalid data to the migrate call by giving
it two connections which both point to the source host. Would
should really add a sanity check to try & detect that mistake.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:36 a.m.
On Fri, Jan 30, 2009 at 04:19:06PM +0000, 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 it. If it's the intention of libvirt that
> you must always have a listening remote API, then we'll have to work out
> a private fix for our tree.
Could you answer this bit? It sounds like from your other comment that
the above is true.
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.
regards,
john
10:42 a.m.
On Fri, Jan 30, 2009 at 11:36:16AM -0500, John Levon wrote:
On Fri, Jan 30, 2009 at 04:19:06PM +0000, 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 it. If it's the intention of libvirt
that
> > you must always have a listening remote API, then we'll have to work out
> > a private fix for our tree.
Could you answer this bit? It sounds like from your other comment that
the above is true.
Yes, the migrate API requires a connection to both libvirtd daemons,
source and destination.
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 don't
want libvirtd to listen publically
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:50 a.m.
On Fri, Jan 30, 2009 at 04:42:04PM +0000, 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 don't
want libvirtd to listen publically
Which requires setting up ssh keys and is significantly slower. Again,
we're not going forbid use of an existing mechanism, but we definitely
don't want to make people use xm, so we'll just hack it in.
regards,
john
5811
days inactive
5811
days old
6 comments
2 participants
participants (2)
-
Daniel P. Berrange -
John Levon