DRS and new virtualization "migration" technologies

[Svedja]

I was wondering if Vmware ESX 3.5 with DRS is going to use new virtualization technologies to leverage new techologies to do a better job at evening out the guest load over the machine that is the best for the particular guest.

With new CPU techologies like Intel FlexMigration you will be able to mix older and newer hardware (to my knowledge) and do Vmotion both ways.

But will Vmware DRS be aware of the fact that new CPU (ie Intel 7300) has better memory handling and put guests with higher memory pressure on these machines.

Other guests are not as memory intensive and migth stay on my "older" Intel 53xx ESX servers.

Not to mention that Storage migration as a technology is already announced in the new version, but I have no knowledge how automatic it will be, with moving diskintensive operations to high performance disks, and lowintensive operations to slower (usualy cheaper) disks.

The next time it's going to be IO virtualization and then something else, so the question is not when ESX is going to use the technology, but how much the system is going to help me maximize the hardware utilization at minimal investment and workforce.

Im my case I use Intel, but the same applies to AMD-based solutions as they have the same technologies on the way.

[mreferre]

FlexMigrate (which is not in the current 7300 processors but it will be in the next iteration based on 45nm technology) is going to remove a VMotion constraint so DRS will use it in the sense that it will be able to float workloads around with less limitations.

It is important to notice that FlexMigrate is not going to buy you any "memory performance improvement" as it only adds VMotion backward compatibility. Memory improvements are supposed to be brought in by the AMD nested page table technology (in the Barcelona SKU's and intercepted by ESX 3.5). Intel will release something on the lines next year at some point.

All in all I would say that your doubts are interesting ..... but we are still far from seeing these technologies in the field ......... automatizing the workload placement to gain the advantages is yet another step on top of what we need to do right now.

Clearly enhanced optimization (in general) remains a big challenge in this space (or an opportunity if you will).

Massimo.

[Svedja]

Hmm,

That answers one of my underlaying questions, to continue with Intel 53xx CPU servers or to move to Intel 73xx.

For the moment the 73xx machines are overpriced for my envirovmet approx double price compared to 53xx and gives to little advantages.

And I don't wan't to move to AMD as of yet. There need to be even more advantages to decide to take that step.

But how about the storage migration feature included in Vi3.5?

Have anyone tried the feature? Is it manual (with possible recommendations from DRS) or policy based and/or automatic?

[mreferre]

The way I see VMotion of vmdk files right now is for storage server migration. For example: I need to swap out storage server A from vendor X and need to replace it with storage server B from vendor Y.

Another way to look at it would be for tiered storage support. For example: This vm is no longer important to this project so that I will move it from FC to SATA based storage. This other vm is getting important so I will move it from SATA to FC based storage.

I don't think we will see a continuos DRS-like monitoring of vmdk files (at the beginning at least) and let VC decide to move files around based on ...... "its thoughts".

Massimo.

[Svedja]

There seems to be no clear answer publicly available, but we have to wait and see.

Not even my local vmware representative knows exactly how it work but comes to approximatly the same conclusion as you.

Thanks for correcting me regarding Intel 7300.

It seems that the only virtualization "acceleration" is better interrupt handling and the extra "flex" features that doesn't change performance.

Introduced in the new Quad-Core Intel® Xeon® Processor 7300 series platforms, Intel VT FlexPriority ...

Also Intel is doing a good job at not being too exact "[Up to 1.86x performance improvement compared to two-socket Quad-Core Intel® Xeon® processor 5300 series-based servers|http://download.intel.com/products/processor/xeon/7300_prodbrief.pdf]".

The problem is at you can't tell if it is two socket 7300 compared to tvo socket 5300. But it must have been fun for the marketing department.

[dpomeroy]

Some of what you are talking about with ESX 3.5 is still under NDA, so there may be stuff people are not able to tell you.

As far as I know there hasn't been anything publically stated about having DRS extend to looking at performance beyond CPU and Memory utilization. There is still a lot of room for advancements in the automation and optimization features of VI, and I expect they will continue to further expand and enhance features like DRS, HA, etc.

Don Pomeroy

VMTN Communities User Moderator

[mreferre]

I need to take it (partially) back. FlexMigrate is what i described.

However now that you mention that I remember that Intel is doing some advancement in the hardware-assist performance-wise and this might very well fall into this other marketing brand that is FlexPriority.

A brief google search came out with this:

Now it might buy you something (and I have no idea how much ....) but a 167% improvement ......... well it should be on the first page of the Wall Street Journal if that is true ..... so it should be taken with a bit of grain of sault in my opinion.

I have no idea if/when VMware is going to leverage this.

Massimo.

[GBromage]

Perhaps we might get to a situation where we move away from a SAN environment to having a cluster of iSCSI enables NAS appliances. In the same way that 3.5 will be able to power down hosts that aren't needed, future versions may be able to migrate and shut down NAS storage as well? (Or maybe I've planted the idea in their heads just now? ?:| If so, I want a credit if they implement that feature!)

I'll be quite interested in seeing how VCB reacts to VMs moving between LUNs partway through a backup.

[mreferre]

I think you are thinking a bit ahead of the times .....

Massimo.

[Svedja]

VCB being integrated in the Vmware suite, it shouldn't be any problems implementing a mutex that locks the storage (or at least the VCB snapshot) for the duration of the backup.

Thirdparty applications might have a much bigger problem if there is not API to control that from "outside" vmware suite.