xen discuss - Feb 2008 - Q. xm migrate [--live] vs virsh

Hi,

I''m just playing with xm migrate and xm migrate --live and just have a
few questions,

1. Is there an equivalent virsh command to xm migrate/live migrate.

2. It appears that via xm migrate it is possible to have the same domU  
name, albeit with a different domain id on the same xVM node. Please  
consider the following

bash-3.2# virsh list --all
  Id Name                 State
----------------------------------
   0 Domain-0             running
   - elko-1               shut off
   - elko-2               shut off

bash-3.2# virsh start elko-2
Domain elko-2 started

bash-3.2# virsh list --all
  Id Name                 State
----------------------------------
   0 Domain-0             running
  47 elko-2               running
   - elko-1               shut off

bash-3.2#
bash-3.2# virsh start elko-2
error: Domain is already active

bash-3.2# virsh list --all
  Id Name                 State
----------------------------------
   0 Domain-0             running
  47 elko-2               blocked
   - elko-1               shut off

bash-3.2#

For me at least, I like the above behavior.

However, I could end up with this if I start elko-2 on another node  
and then xm migrate --live to the node above, i.e.

bash-3.2# virsh list --all
  Id Name                 State
----------------------------------
   0 Domain-0             running
  47 elko-2               blocked
  48 elko-2               blocked
   - elko-1               shut off

If we consider multiple xVM nodes that will participate in live  
migration, i.e. assuming an NFS mounted filesystem on these xVM nodes  
for the boot image, then I could start the same domU on another or all  
xVM nodes that could potentially participate in live migration.

While I accept that doing so will likely corrupt the backend data  
store and confuse everyone where the domu is running if it is running,  
it nevertheless is currently possible to do. If we consider that for  
live migration to work we need to follow these steps,

Listen on all addresses (or you can specify a particular interface IP)
# svccfg -s xend setprop config/xend-relocation-address = \"\"
Create list of hosts from which to accept migrations:
# svccfg -s xend setprop config/xend-relocation-hosts-allow = \"^flax$  
^localhost$\"
Update the config:
# svcadm refresh xend && svcadm restart xend

Then my question #1 comes back into play albeit somewhat expanded.

1. Is there a [planned] virsh start/migrate command that would check  
the "config/xend-relocation-hosts-allow" hostlist to determine if the
"Domain is already active" somewhere on this relocation hostlist, and
if it is then not allow the domain to be started and instead push out  
the message "Domain is already active on node X".

Regards
Neil

Hi Neil,
> 
> 1. Is there an equivalent virsh command to xm migrate/live migrate.
No, not to my knowledge. Do you have the latest virsh man page?


-- 
Best regards

-Michael
Sun Microsystems, Inc.

On Tue, Feb 12, 2008 at 06:18:29PM +0000, Neil Garthwaite wrote:
> 1. Is there an equivalent virsh command to xm migrate/live migrate.
Not currently, but one will be hitting Nevada fairly soon (hopefully).
> If we consider multiple xVM nodes that will participate in live  
> migration, i.e. assuming an NFS mounted filesystem on these xVM nodes  
> for the boot image, then I could start the same domU on another or all  
> xVM nodes that could potentially participate in live migration.
This has very little to do with live migration. You could equally well
use the same shared storage for two unrelated domains. The results would
be equally disastrous.

The solution to management issues like this is (you knew it was coming)
something like xVM Ops Centre.
> 1. Is there a [planned] virsh start/migrate command that would check  
> the "config/xend-relocation-hosts-allow" hostlist to determine if
the
> "Domain is already active" somewhere on this relocation hostlist,
and
> if it is then not allow the domain to be started and instead push out  
> the message "Domain is already active on node X".
For this particular case, we could look for the UUID on the target host
and see if it''s running. However, this would only catch one
circumstance
as I''ve pointed out. We do need to improve the negotation of live
migration (in fact, there is /none/ at the moment), however.

regards
john