[cisco-voip] vMotion w/o Shared Storage

Sun Mar 15 16:11:33 EDT 2015

You can also power down and move VMs box to box. Extremely slow but works.

~ # scp -r /vmfs/volumes/530c546f-ab5b67c0-2bc1-b83861d767e5/ISOs  root at 172.19.233.211:/vmfs/volumes/52df6d00-b8f0cbe1-6f83-c067af83fce8/ISOs/CUCM/<mailto:root at 172.19.233.211:/vmfs/volumes/52df6d00-b8f0cbe1-6f83-c067af83fce8/ISOs/CUCM/>

I’ve got a Synology 2013+ and thinking about testing out iSCSI/SSD and ESXi for the my lab stuff.  Thinking it will be too slow.  It is amazing how quick ccmadmin is running on direct SSD. No more “loading please wait”

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Heim, Dennis
Sent: Saturday, March 14, 2015 10:00 AM
To: Dave Goodwin; Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] vMotion w/o Shared Storage

This is definitely interesting that you can migration between datastore’s even if a specific host does not have access. However, I think this is getting close to the just because you can, doesn’t mean you should. In today’s age it should be pretty easy to get a NFS mount that both hosts can point to. Heck, you can even do NFS or iSCSI on a Synology SAN. Load it with SSD’s and probably get acceptable IOPS (not recommending this as an enterprise solution).

Dennis Heim | Emerging Technology Architect (Collaboration)
World Wide Technology, Inc. | +1 314-212-1814
[twitter]<https://twitter.com/CollabSensei>
[chat]<xmpp:dennis.heim at wwt.com>[Phone]<tel:+13142121814>[video]<sip:dennis.heim at wwt.com>
"Innovation happens on project squared" -- http://www.projectsquared.com<http://www.projectsquared.com/>

Click here to join me in my Collaboration Meeting Room<https://wwt.webex.com/meet/dennis.heim>

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Dave Goodwin
Sent: Saturday, March 14, 2015 6:54 AM
To: Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] vMotion w/o Shared Storage

What about a live migration from one C-series with DAS to another C-series with DAS? VMware supports this in 5.1 and later. VMware doesn't really call this Storage vMotion (even if part of the underlying task is performing a similar feat). They don't even call it enhanced vMotion anymore in 5.5.
https://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-561681D9-6511-44DF-B169-F20E6CA94944.html

If it definitely falls into the "not supported" area, does anyone have an idea of whether it's not supported on purpose, because it was shown to wreak some kind of havoc on live traffic compared with a more simple vMotion? Or, unsupported due to lack of testing or knowledge of impact potential? Just trying to get a sense as to whether or not folks have tried it in a real production environment.

-Dave

On Fri, Mar 13, 2015 at 1:03 PM, Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
The storage part of enhanced vMotion is called Storage vMotion and essentially isn’t supported.
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Storage_vMotion

"May only be done during a maintenance window with UC VMs shut down.”  This is basically saying storage vMotion isn’t supported but you can migrate between datastores all day long.  I don’t even see the point of requiring SAN since with the VM shut down whether you are going between SANs or DAS datastores is just a matter of time.

-Ryan

On Mar 13, 2015, at 11:35 AM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:

Hey how’s it going, Anthony – The confusion I had was mostly with VMware/ESX terminology behind migration methods. The Cisco documentation I was reading for supported vMotion methods all said “when shared storage is available”… and my question was “well… what if you have no shared storage and need to migrate between such datastores and hosts? Is this supported?”

The steps I was interested in taking to migrate the virtual machine is documented as “Enhanced vMotion”: http://vmdamentals.com/?p=4222

But here’s why I say I was confusing VMware terms… the vMotion (or Enhanced vMotion) process applies to live/powered-up virtual machines. For a powered down machine it’s simply considered a cold migration:

https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc_50%2FGUID-326DEC3C-3EFC-4DA0-B1E9-0B2D4698CBCC.html

Since I plan on having the machine powered off anyway, and Cisco fully supports a cold migration, then it seems I should have no concerns for my specific scenario…

… but on the topic of vMotion on a powered on UC VM, since documentation states that regardless of the UC app, the “VM must be installed on shared storage” and “source and destination servers must be connected to same SAN” – which tells me that Enhanced vMotion on a powered up UC VM between unshared storage is not supported.

^^^ The confusion of a non-VCP :)

- Dan

From: Anthony Holloway [mailto:avholloway+cisco-voip at gmail.com]
Sent: Wednesday, March 11, 2015 2:01 AM
To: Daniel Pagan; Dave Goodwin
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] vMotion w/o Shared Storage

Daniel,
Could you give a little more detail about your experience with this process?  The confusion you faced is likely the same confusion many of us would face.

Which document(s) did you follow?  Which files did you copy?  What were the high level steps? etc.

On Tue, Mar 10, 2015 at 9:02 PM Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:
Thanks Dave. I also came across these details, but it too states shared storage:

“A Virtual Machine (VM) file on network/shared storage can be booted on any physical server hosting ESXi that has access to that network shared storage.”

But perhaps my confusion was vMotion vs cold migration. My original thought was using Enhanced vMotion since the objective was to bring the VM config and disk to another host and unshared datastore.

http://www.vladan.fr/vmware-enhanced-vmotion/
http://www.ntpro.nl/blog/archives/2118-Enhanced-vMotion-with-vSphere-5.1.html

I wasn’t sure if this was Cisco supported since all mention of vMotion migrations in the VMware requirements document state shared storage, but it seems this doesn’t quite fit the process of vMotion (Enhanced or not) since the virtual machine is powered off anyway. This would certainly fall under the category of cold migration, which is definitely Cisco supported.

Some confusion on my part between the two migration methods but all is clear.

Thanks!

- Dan

From: Dave Goodwin [mailto:dave.goodwin at december.net<mailto:dave.goodwin at december.net>]
Sent: Tuesday, March 10, 2015 8:47 PM
To: Daniel Pagan
Cc: Ryan Huff; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>

Subject: Re: [cisco-voip] vMotion w/o Shared Storage

Keep in mind that moving a VM from one host to another (whether the VM's storage is being moved or not) is not considered a vMotion. That is why you can do it even without enabling any NICs on the host for the vMotion feature. Therefore, the VMWare feature you'd want to look for in the matrix is probably "Restart Virtual Machine on Different ESXi Host" and not vMotion.
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements

On Tue, Mar 10, 2015 at 6:18 PM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:
Thanks - that’s what I figured and just tested with no issues. Seems the non-shared storage caveat for vMotion is a non-issue in ESXi 5.1 and higher.

http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-9F1D4A3B-3392-46A3-8720-73CBFA000A3C.html

I was also concerned of partition alignment but I guess that would be a non-issue as well since the vmdk is already provisioned. The move to the stand-alone datastore is nearing completion so I’ll double check the start block size once it’s done just to be sure!

- Dan

From: Ryan Huff [mailto:ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>]
Sent: Tuesday, March 10, 2015 5:08 PM
To: Daniel Pagan; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] vMotion w/o Shared Storage

Shutdown, yes. Running, no.

Thanks,

Ryan

-------- Original Message --------
From: Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>>
Sent: Tuesday, March 10, 2015 05:06 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] vMotion w/o Shared Storage
Quick question…

vMotion of a shut down UCM between two hosts without shared storage using vCenter. Is this supported? The virtualization document for UC platforms says vMotion is supported on shared storage, so I figured to ask. Is this migration method supported?

- Dan

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150315/f6012199/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3876 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150315/f6012199/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1389 bytes
Desc: image002.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150315/f6012199/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1292 bytes
Desc: image003.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150315/f6012199/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1391 bytes
Desc: image004.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150315/f6012199/attachment-0003.png>