I have been to a Microsoft presentation today for a large customer that is thinking to virtualize quite a lot of servers (100s-1000s). Their mind was clearly set for ESX 3 but that was until Microsoft came along. MS has a very personal approach to work with the customer to convince him to go with them. Something I have not seen VMware doing yet.
Anyway, the presentation focused a lot on high availabilty with Virtual Server 2005 R2 namely:
- vm restart after failure
When he started to talk about hot migration, the MS expert said it was the same as VMotion because memory contents is copied between the physical hosts and that VMotion was less flexible because it requires a dedicated Gb connection.
I thought that was quite funny.
To my knowledge, Virtual Server R2 implements "hot" migration by saving the VM state to disk, failing over the cluster group's resources (IP, disk, VM) and then bringing the resources online. To me it is apparent that there is downtime in that case, especially when multiple VMs are running on the same LUN because they all have to have their state saved and resumed. Depending on the application you might or might not notice this. But depending on load, speed of failover etc.... you cannot guarantee issue-free hot migration.
And by the way: to "hot" migrate each VM independently of the others, each VM needs it own LUN. Think about an 8-way cluster with 20 VMs each: 160LUNs for all those old underused systems. Nice
My question is: does anyone have experience with Virtual Server 2005 R2 "hot" migration in real life situations? How bad/good is it? How can you counter arguments like above the best way? How can I create a demonstration that clearly shows the differences?
Thanks for the response.
Anyway, the presentation focused a lot on high availabilty with Virtual Server 2005 R2 namely:
- vm restart after failure
When he started to talk about hot migration, the MS expert said it was the same as VMotion because memory contents is copied between the physical hosts and that VMotion was less flexible because it requires a dedicated Gb connection.
I thought that was quite funny.To my knowledge, Virtual Server R2 implements "hot" migration by saving the VM state to disk, failing over the cluster group's resources (IP, disk, VM) and then bringing the resources online. To me it is apparent that there is downtime in that case, especially when multiple VMs are running on the same LUN because they all have to have their state saved and resumed. Depending on the application you might or might not notice this. But depending on load, speed of failover etc.... you cannot guarantee issue-free hot migration.
And by the way: to "hot" migrate each VM independently of the others, each VM needs it own LUN. Think about an 8-way cluster with 20 VMs each: 160LUNs for all those old underused systems. Nice
My question is: does anyone have experience with Virtual Server 2005 R2 "hot" migration in real life situations? How bad/good is it? How can you counter arguments like above the best way? How can I create a demonstration that clearly shows the differences?
Thanks for the response.
