Live Migration was the big stick that everyone beat up Windows Server 2008 Hyper-V. A few seconds downtime for a quick migration was often good enough for 75%-90% of VM\u2019s but not for 100%. But you can relax now; we have Live Migration. I\u2019m using it in production and it is good! <\/em>I can do host maintenance and enable completely automated PRO tips in VMM without worrying of any downtime, no matter how brief, for VM\u2019s. How does Live Migration Work? Let\u2019s look at how it works.<\/p>\n So when does all this stop?<\/p>\n Note: The memory is being copied over a GB network. I talked about this recently when I discussed the network requirements for Live Migration and Windows Server 2008 R2 Hyper-V clusters<\/a>.<\/em><\/p>\n Remember, the VM is still running on host 1 right now. No users or network applications have seen any impact on uptime.<\/p>\n Just how long was the VM offline between being paused on host 1 and un-paused on host 2? Microsoft claims the time is around 2 milliseconds on a correctly configured cluster. No network application will time out and no user will notice. I\u2019ve done quite a bit of testing on this. I\u2019ve pinged, I\u2019ve done file copies, I\u2019ve used RDP sessions, I\u2019ve run web servers, I\u2019ve got OpsMgr agents running on them and not one of those applications has missed a beat. It\u2019s really impressive.<\/p>\n Now you should understand why there’s this "long" running progress bar when you initiate a live migration. There’s a lot of leg work going on while the VM is running on the original host and then suddenly it’s running on the destination host.<\/p>\n VMware cluster admins might recognise the above technique described above. I think<\/em> it\u2019s pretty much how they accomplish VMotion.<\/p>\n Are there any support issues? The two applications that come to mind for me are the two most memory intensive ones. Microsoft has a support statement to say that SQL 2005 and SQL 2008 are supported on Live Migration clusters<\/a>. But what about Exchange? I\u2019ve asked and I\u2019ve searched but I do not have a definitive answer on that one. I\u2019ll update this post if I find out anything either way.<\/p>\n Edit #1<\/p>\n Exchange MVP\u2019s Nathan Winters<\/a> and Jetze Mellema<\/a> both came back to me with a definitive answer for Exchange. Jetze had a link<\/a> (check under hardware virtualization). The basic rule is that a DAG (Data Availability Group) does not support hardware virtualisation if the hosts are clustered, i.e. migration of an Exchange 2010 DAG member is not supported.<\/p>\n Let\u2019s recap the different types of migration that we can get with Windows Server Hyper-V and System Center Virtual Machine Manager: Quick Migration: Leveraging Windows Failover Clustering, a VM is treated as a clustered resource. To quick migrate, the running state is saved to disk (hibernating the VM), the disk failed over to another node … Continue reading “How W2008 R2 Live Migration Works”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"_wpcom_ai_launchpad_first_post":false,"footnotes":""},"categories":[20],"tags":[63,181,74,96,97,196,117],"class_list":["post-10109","post","type-post","status-publish","format-standard","hentry","category-hyper-v","tag-failover-clustering","tag-hyper-v","tag-live-migration","tag-sql-2005","tag-sql-2008","tag-vmm","tag-windows-server-2008-r2"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t![\"image\"](\"https:\/\/aidanfinn.com\/wp-content\/uploads\/2009\/11\/image7.png\" "\\"image\\"")
<\/a>Above, we have a virtual machine running on host 1. It has a configuration and a \u201cstate\u201d.<\/p>\n<\/a>When we initiate a live migration the configuration of the VM is copied from host 1 when the VM is running to host 2, the destination host. This builds up a new VM. The VM is still running on host 1.<\/p>\n<\/a>While the VM remains running on host 1, the memory of the VM is broken down and tracked using a bitmap. Each page is initially marked as clean. The pages are copied from the running VM on host 1 to the new VM sitting paused on host 2. Users and network applications continue to use the VM on host 1. If a RAM page changes in the running VM on host 1 after it has been copied to host 2 then Windows changes the state from clean to dirty. This means that Windows needs to copy that page again during another copy cycle. After the first RAM page copy cycle, only dirty pages are copied. As memory is copied again it is marked as clean. As it changes again, it is marked as dirty. This continues \u2026<\/p>\n\n
<\/a>Start your stop watch. This next piece is very, very quick.<\/em> The VM is paused on host 1. The remaining state is copied over to the VM on host 2 and the files\/disk are failed over from host 1 to host 2.<\/p>\n<\/a>That stop watch is still ticking. Once the state is copied from the VM on host 1 to host 2 Windows will un-pause it on host 2. Stop your stop watch. The VM is removed from host 1 and it\u2019s running away on host 2 as it had been on host 1.<\/p>\n