Sometimes we don't get an immediate response from the support team. The initial POC also took a lot of resources. 

I would like hardware capacity additions to be a little more flexible. The upgrade path for the existing XTremIO units requires you to purchase 2 XBricks at a time and they need to be the same capacity as the existing XBricks.

-You could not mix drive sizes
-You could not add just a single XBrick
-You had to fully populate both XBrick’s
All of this equals a very expensive\large upgrade path
However; after saying all of this, EMC announced a new generation of XTremIO (X2) which allows more granular growth, mixed drive size, etc…
(You need to purchase new hardware – I don’t believe they are adding these features to existing XTremIO Clusters.)

The evergreen factor, which is the ability to upgrade in-place upgrades to new hardware could be improved.

I would like to see the ease of deployment and built-in Metro clustering.

If you are looking at flash storage solutions, XtremIO doesn't offer any unique features. Most of my customers are migrating their workload from XtremIO to other formats because of this. If you look at Hitachi or IBM, they have the VSP G series or FlashSystem, these products have many features available. We can scale up and scale out, add multiple nodes, use a global cache, and we don't have the same kinds of features in XtremIO. Because of the lack of unique and key features, most customers nowadays don't want XtremIO. 

XtremIO needs to have a global cache. Internal architecture should also be redefined and existing architecture sectioned off. Additional unique features should be added, rather than just common features like replication. Right now, XtremIO is an all-flash array, which is costly. I would like to see them come up with a hybrid model, one that is more cost-effective and may offer more benefits to customers. 

Since XtremIO is all-flash, it doesn't currently have NAND support. I would like to see interface support from XtremIO, and at least NAND or SD card support. If they supported a combination of SSDs and SDs, that could be beneficial to some small and medium businesses. 

Dell should also provide a data analysis tool, in the case of any issues with internal components like controls, cache, backup drive, etc. It would be helpful to have a tool to troubleshoot performance issues. 

A last feature is that XtremIO should have a cloud mobility option, in addition to flash. XtremIO has no data migration features, so these features should be implemented without needing to purchase an additional license or application. XtremIO needs some fine-tuning and these are where I would start. 

The replication of Dell EMC XtremIO could improve. In the newer versions they have improved, however, the replication can be improved further where we can include concurrent or cascaded methodologies.

In the next release, the solution could have better integration and if we can host assets on the cloud, such as NetApp has the NetApp volumes, which we can host on the cloud directly called NetApp CVO (cloud volume ONTAP). Dell EMC should come up with something purely on the cloud rather than manage services.

The upgrade ability seems to have improved. I believe having more replication options comparatively to VMAX (other than RecoverPoint) would be great. Maybe something like SRDF (which is symm only replication, but something like this).

Native data replication: To replicate data between XtremIO devices, you need to use EMC’s RecoverPoint appliances to move the data. More and more arrays are providing the ability to replicate the data natively without the need for a secondary device to do it for them.

The EMC VNX platform is the same way. It only requires native replication via RecoverPoint. EMC’s flagship VMAX and their new Unity platform replicate natively. Even EMC's Isilon does data replication natively.

XtremeIO needs to catch up. That’s about the only Achilles heel of the product.

Replication: XtremIO has none

Controller failover: When you lose one of the scale-out nodes on XtremIO, your hosts will see a large drop in I/O while it occurs and EMC is unaware of how their controllers work. As it is shown in their demos, the work load after a failure is spread across each node. But if you look at the “ACTUAL” process, the work is loaded on each node until that node gets to 100%. Then, the work goes to the next node and repeats. So, in the event of a failure, you will have several nodes at 100% and others at 25% load.

Data recovery: In the event of a dual power supply failure, the array has to be recovered from a backup.

Volume limits of 8192 per XMS and stability. I have unfortunately had some bad experience with bugs and failed upgrades. It has improved with the new 4.0 code but it’s still not as good as typical EMC.

XtremIO and Pure Storage have a volume limit. XtremIO is 8192 logical volumes per XMS management server. XMS can manage multiple XIO clutters, if you do that your volume count is 8192 across all the clusters XMS is managing. Pure Storage has just released code to go to 5000. A logical volume on XIO is any volume, whether it’s a snapshot or a volume presented to a host. Whereas Pure Storage only counts a snapshot that is hydrated.

Volume count. A hard limit of 8192 volumes per cluster. This becomes an issue with DR replication and RecoverPoint and trying to maintain the best RPO possible.

There is a limit of 8192 volumes/LUNS that can be created. This includes all volumes/LUNs presented to hosts along with all snapshots, so it becomes very easy to bump up against the limits in certain circumstances. For us, we use RecoverPoint to replication between XtremIO devices, and since RecoverPoint creates a snapshot of each volume to allow for point in time recovery that results in a lot of snapshots that have to be accounted for.

• The management server needs to be integrated. XtremIO VNX and VMAX have separate management software stacks for managing the various arrays.
• We would also like to see one universal management view into all these sub-systems. For example, IBM SVC and Pure Storage Purity each have one universal software management view.

Replication: EMC should have native replication ability, not something you have to take an outage for in order to install, i.e., if you did not purchase the replication when you rolled out the storage array.

Native replication is important for a few reasons:

• If something goes wrong, it gives you more of a "one throat to choke" scenario, meaning you only have to talk to one or two vendors.
• Native replication is usually cheaper, especially IP replication (versus fiber-based replication).
• When replication is native, you can usually have more insight at to what is replicated and what is not, instead of having to query various different things to get an answer.
• Native replication is usually easier to set up and maintain. It also has little less administrative work and overhead costs.

Even with the fast SSD drives and processing on the controller, there was still a lag on the FC ports.

The initial node came with only two FC ports per controller. It was used for multiple ports on the VMAX to spread traffic over several VSANs.

For more detail:

I had 4 dH2i powerpath servers hitting it, along with 4 vmware clusters 8 host each, on a X1 brick we only had two controllers both with 2 port
So a total of 4 FC ports.

Compared to the VMAX 20K, where I had 8 ports on vlan 2, 6 ports on vlan 100, 8 ports on vlan 50, so I was able to spread the traffic around between process.
I had 2 directors on one VMAX, whereas I had 3 directors on the other VMAX.

With only 4 ports on the xtremeIO, the most I could do was send traffic on 2 ports to two different VLANS one on each controller.
So my comment was get additional ports, so the DH2I servers don’t hog all the IOPS.

Recommend getting the second brick X2 and the matrix switch, then with 8 FC connector can start spreading the traffic.

The company had me routing the data thru a fabric switch MDS9500, separate from the main traffic as this was a test.
Most of production was on 4 other MDS9500 switches.

Monitor of the switch, did not show a bottleneck going to the servers, only on the 4 8GB FC going to the XtremeIO.
Connect to different blades on the 9500.

Don’t think they have touched it since I left. Nor on the other 8 SAN units.

• The physical architecture could use some higher levels of redundancy.
• The past upgrades were highly impactful to active workloads.
• Previous levels were also susceptible to security vulnerability scanning.

Integration with other EMC SAN storage array ecosystems like VMAX3, Unity, etc., especially for consistency group protection: This will help to consistently recover applications which are spread across multiple product lines like VMAX3 and XtremIO for various reasons.

I could give an example of SQL DB hosted in EMC VMAX array with SRDF replication to a remote site for disaster recovery.

If we have to move part of the volumes (like TempDB, Indexes,logs. Etc) into XtremIO and part remains in VMAX, the whole server won’t be able to able to get recovered with consistent point in time of recovery due to different replication technologies in 2 different platforms (VMAX and XtremIO).

I meant to say that it may be perfect for other environments but not for environments which are heavily dependent upon SRDF based replication. There might be ways to get around like implementing Recoverpoint for VMAX and XtremIO but the integration was complex in our use case.

Get rid of the Java aspect of the GUI console. Basically, the GUI to administrator the array uses Java as its base to run on. Java at best is buggy and prone to loading issues, so moving away from this platform would be nice.

It has no storage replication. The replication is done through the VPLEX. In some cases where we don’t need the flexibility of the virtualization layer, we could free up resources on the VPLEX by using the storage replication.

The replication and DR capabilities could be improved, since there is no native replication technique with XtremIO. EMC wants customers to rely on EMC RecoverPoint for those needs or VPLEX for DR sorts. Native replication is needed.

At times, it's difficult to track down allocated resources as compared to other solutions, like VMAX and VNX, because it's completely software-based.

The GUI could be modified more in terms of how the different components are linked to each other.

What needs to improve is that the end compression uses a lot of CPU, which makes it difficult or impossible to upgrade. I believe that it has improved in the upgraded versions, which we don't have yet. Also, the price and interface should be simplified too. 

• Management: At the time, there was no snapshot scheduler, so I had to write XSnapCourier to address it. The sad thing is that even after the newest release, which includes a native scheduler, most customers using XSnapCourier chose to stick with it due to a more feature-rich experience.
• Planning: The VAR we went through told us we would get something like an 8 x 1 ratio between compression and inline deduplication after migration from NetApp. For this reason, we only elected for 20 TB raw. What we actually got, however, was little over 2 to 1, which was actually worse than what NetApp afforded us.
• Support: Even though we paid for a four-hour turnaround support contract, we would have to wait up to two weeks for a response from EMC XtremIO support, because they didn’t actually have the support staff to handle new volume.

• The new UI could be simplified and the implementation should be simplified.
• The UI is easier to use than other EMC offerings, but still takes a pure storage admin to manage and maintain.
• Ease of use is key in the converged and hyper-converged world that requires administrators to have both hypervisor and storage skills.
• Arrays should be “set it and forget it”, including the replication features, which should not require separate products.
• Implementation and expansion require EMC or a partner to implement. However, to be a true scale-out solution, it should be something that customers can do themselves.

Management and reporting need improvement. Cloning could be easier.

It needs a lot of improvement to be more like Pure Storage or Nimble AFAs.

The GUI is still Java based, and this needs to be fixed. It needs a way to determine the deduplication of each LUN and what the impact would be if we were to move data from one LUN to another.

Dell XtremIO needs to provide better performance to keep up with new products.

The solution needs to be simplified. When you integrate your storage with other systems, it could use a little bit of automation. 

It's not an improvement so much as a query. What I'm curious about is whether or not the feature has the ability to do inline data reduction between two physical storage solutions. If we have one storage solution in the UK and the other in Australia, will the system be able to tell us what we have already, so we aren't sending 95% of our data across the world unnecessarily? I know that the feature works locally on the source solution. What I'm curious about is, would that data reduction feature work between two instances of XtremIO in two different places.

XtremIO needs to be lower priced. It also needs better endpoints and scalability.

The deployment of the solution could be simplified.

The solution should be integrated into the system by default and not separately.

Newer HTML 5, no more JAVA required.

If Dell/EMC were to add native replication to the XtremIO, that would be a great improvement.

Right now, external appliances are needed to replicate XtremIO to XtremIO, or to another EMC system.

Having built-in replication will cut the cost of data recovery solutions by removing the expensive appliances and the software required to make the data flow between the two sites.

Until the release of XtremIO X2 this summer, there is currently no “built-in” replication capabilities between XtremIO appliances. This is a feature that some competitors have that XtremIO Gen 1 does not.

In order to replicate block data from XtremIO to XtremIO, or XtremIO to another EMC product, a customer must purchase RecoverPoint appliances and licenses.

To replicate virtual machines, you can either buy RecoverPoint appliances and licenses, vSphere replication and licenses, Zerto, Veeam, or another product.

Buying these add-ons increases the cost of maintaining redundant copies of XtremIO data.

I would like to see improvements in the database workloads. During the testing of database workloads, we found it slow to process I/O requests. This may be due to the compression/deduplication feature available in the product which is still being taken care of by the same controllers.

The product designer should provide a recommendation for which type of workload deduplication/compression will be effective.

This is good to have for VDI, but not for high database workloads though its flash array.

They can improve the product by providing an HTML5-based interface instead of the Java GUI based application.

We use the dashboard of the Java based Windows application to monitor the storage array’s current IOPS and latency metrics.

However, we also require direct firewall access open to the XMS server as we monitor from a different location. I don’t believe the Java based GUI application is proxy aware.

So, if the XMS application server could be monitored through an HTML browser interface, it should then be proxy aware, making life a little simpler.

The most important thing for the system engineer is to check if there is latency in the IOPS for any run. You cannot measure the number of IOPS or whether or not it is overloaded. You cannot measure anything in EMC about this. Most solutions, especially HP, improved our fall-over performance, with our database and servers. Most servers are HP, but we use EMC now only for backup. 

One thing that should be improved is the reporting and monitoring tools. It should use real-time monitoring for storage, IOPS, latency, etc.

The product could be improved by reducing the pricing and having better organization in their technical support team.

The only item that I can think of, is the ability to add more XtremeIO bricks as one logical partition rather than two separate ones.

The stability of the product needs improvement.

The cost of this solution could be reduced.

Scalability is something that can be improved because there is an issue when it comes to mixing versions. We cannot mix version one and version two. This is something that may have been improved but earlier, it is something that was a challenge in terms of scalability.

The management should be improved and the GUI interface could be better and easier.

In the next release, they should improve the replication. There should be high availability. You can't do replication from one EMC to another, you would need to use another tool with the way it is now.