[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] XCP 1.6 - Disaster recovery



Hi Martin,

 

That’s strange – maybe the recovery wizard only shows VMs for which the storage is available, and hides those it can’t failover.

 

If you can see the VM(s) you want to failover after running “xe vm-list database:vdi-uuid=<metadata-vdi-uuid>”, then try this:

 

xe vm-recover database:vdi-uuid=<metadata-vdi-uuid> uuid=<vm-to-failover>

 

If that doesn’t work, you should at least get an error explaining why you can’t failover the VM.

 

John

 

From: martin.kralicek@xxxxxxxxxxxxx [mailto:martin.kralicek@xxxxxxxxxxxxx]
Sent: 25 April 2013 10:17
To: John Else
Cc: xen-api@xxxxxxxxxxxxx
Subject: RE: XCP 1.6 - Disaster recovery

 

Hi John,

 

Thanks for your reply and sorry for my late respond.

 

Yes I am configure DR from xencenter gui and I see that VDIs „Metadata for DR“ were created on each SR.

 

Next step what I performed was verify this configuration via  Disaster Recovery wizard – Test Failover but there does not shown any VMs

But when I tried to run xe vm-list database:vdi-uuid=<metadata-vdi-uuid> now everything is alright.

 

So, is this bug?

 

Thanks for your time.

 

Regards

 

Martin

 

From: John Else [mailto:john.else@xxxxxxxxxx]
Sent: 23. dubna 2013 9:32
To: Kralicek, Martin
Subject: RE: XCP 1.6 - Disaster recovery

 

Hi Martin,

 

To configure disaster recovery you need to enable database replication to one or more shared lvmoiscsi or lvmohba SRs - either via the CLI (“xe sr-enable-database-replication”) or through the XenCenter dialog at Pool > Disaster Recovery > Configure…

 

It sounds like you’ve already done this though – in which case you should have a VDI called “Metadata for DR” in each of those SRs. When you take one of those SRs and attach it to a secondary pool, XCP can use that VDI to look up which VMs were present in the original pool. You should also be able to run the failover wizard for the secondary pool and view VMs from the original pool.

 

n.b. even through each Metadata VDI will contain the database information for all VMs that were present on the original pool, you won’t be able to recover VMs to the secondary pool unless the SR used by those VMs for storage is attached to the secondary pool as well (although there’s nothing to stop you using the same SR for storage and DR metadata).

 

Lastly, you can query these metadata VDIs on the CLI if you want to sanity-check what’s on them, e.g.

 

xe vm-list database:vdi-uuid=<metadata-vdi-uuid>

 

Hope this helps,

John

 

From: xen-api-bounces@xxxxxxxxxxxxx [mailto:xen-api-bounces@xxxxxxxxxxxxx] On Behalf Of martin.kralicek@xxxxxxxxxxxxx
Sent: 22 April 2013 11:16
To: xen-api@xxxxxxxxxxxxx
Subject: [Xen-API] XCP 1.6 - Disaster recovery

 

Hello,

 

I would like to ask how I have to configure disaster recovery, because when I performed configuration steps and selected all iSCSI SRs everything seem be OK, but after I want to check it via Test Failover wizard and selected again all available storages the next step does not show VMs.

 

Thanks for any advice.

 

Martin

 


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited.

Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.

______________________________________________________________________________________

www.accenture.com

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.