Tag:

vVols

Migrating VMDK to VVOL fails, logs error ‘Requested size is not a 1MB multiple’

by Philip Sellers May 4, 2017

written by Philip Sellers

I am in the middle of a storage migration and hit a snag while trying to storage vMotion a VM from a VMFS datastore onto a VVOLs. When I started the storage vMotion, it would quickly error out. As a troubleshooting method, I decided to migrate only the VMX and base OS disk files, leaving the large data disk file on its original datastore. Those worked. But every time I tried to move its data disk, it failed with a generic error in the UI

<code>A fatal internal error occurred. See the virtual machine’s log for more details.</code>

Investigating the virtual machine’s logs, I see entries for the storage vMotion attempting to begin, but then it logs these errors:

<code>OBJLIB-VVOLOBJ : VVolObjCheckSize: Requested size (######) is not an MB multiple.</code>

<code>VVolObjDetermineSizeInMB: Requested size (#####) is not a MB multiple.</code>

<code>Mirror: scsi0:1: SVMotionLocalDiskCreate: Failed to create destination disk: The requested size is not a multiple of 1MB. </code>

Solution

After seeing those 3 errors, I decided to look at the VM’s disk configuration. Within the Edit Settings window, the data file showed size of 1,740.7999992370605 MB. That decimal and odd sizing is what was causing my migration to fail.

I increased the disk size to an even MB size, saved the VM configuration and then retried the storage vMotion. This time, it moved the disk without any issue. Apparently with VVOLs, the disk sizing must be full 1MB sizes – so any oddly sized disks will fail to move.

A quick piece of PowerCLI can help you identify these odd shaped disks in your environment:

[code]Get-Datastore | Get-HardDisk | Select Parent, Filename, @{N="Remainder";E={$_.CapacityKB % 1024}} | Where {$_.Remainder -ne 0}[/code]

This post over at Nimble’s community site describes the same issue: https://connect.nimblestorage.com/thread/14391

May 4, 2017 0 comments

Datacenter Storage

HP readies 3PAR StoreServ with vVol support ahead of vSphere 6

by Philip Sellers August 28, 2014

written by Philip Sellers

HP says that they are ready and waiting with Virtual Volume (vVol) support on the 3PAR StoreServ platform when VMware releases vSphere 6. One of the most discussed topics in storage at VMworld is vVol support and HP says that they have been working with VMware since the pre-acquisition days of 3PAR to implement and support vVols on the platform. The HP 3PAR StoreServ has also the test architecture for fiber channel with vVols for VMware.

I was able to get a demo of the support at the HP booth during VMworld this week. The vVol objects look a lot like standard 3PAR Virtual Volumes (VV’s) on the platform. The two technologies share the same name, which could lead to some confusion, but they do act differently. vVols create the individual VM objects against the 3PAR system utilizing the Common Provisioning Group (CPG) as the object that they create into. 3PAR VV’s are the traditional LUNs that get provisioned from the pool of disks and are also carved out of a CPG.

From 3PAR CLI, the vVol support on 3PAR looks a lot like standard 3PAR VV’s on the platform. The thing that becomes clear is that vVols will create exponentially more objects on the 3PAR for the storage administrator to manage against. Today, within a single 3PAR VV (LUN), you may have 10 or 12 virtual machines. The storage administrator’s view is a single object, the VV.

This pivots with vVols where the VM provisioning in vSphere creates 2 objects on the 3PAR, a Config- and a Data- object. In addition, at least 5 objects for a running VM are active on the 3PAR, potentially increasing the number of objects in the storage admin’s view 50x or more. Adding an additional problem, the naming is generated with the Config- and Data- prefix along with a identifier string which may make correlation difficult. HP is working to ease the management headaches that a potential 50x increase in objects to manage.

3PAR has implemented separate commands in the 3PAR CLI to handle vVols, using things like showvvol instead of showvv administrators currently use. What’s more, its not an all or nothing choice. vVols and normal 3PAR VV’s can coexist on the same array and in the same vSphere hosts. Even while the object count increases in the 3PAR console, the usable information also increases. Since the objects correspond to an individual VM, its easier to use 3PAR’s reporting and CLI to pinpoint performance issues and address them. vVols also unlock native array capabilities at the VM level, like performing array based snapshots on an individual VM instead of an entire LUN all from the normal workflow and interface of the vSphere client.

vVols support relies on VMware API’s for Storage Awareness (VASA) providers to communicate between vSphere and the storage arrays. According to a presentation by Ivan Iannaccone (@IvanIannaccone), HP has put their VASA providers directly onto the 3PAR controllers, meaning that customers will not need an additional layer of software located outside of the array to enable vVol support.

I asked a couple HP folks about replication and vVols and at this point, it is not present in the vSphere implementation. HP says 3PAR is ready to handle replication with vVols since they are basically the same as LUN virtual volumes on the platform, but it will need VMware to deliver support in vSphere first. That also means users with Peer Persistence configurations cannot benefit from vVols until a later time.

To find out more and see vVols on 3PAR in action, check out this older video that Calvin Zito, @HPStorageGuy, posted back in 2012 showing of vVol on 3PAR. In the video, Calvin focuses on the 3PAR InServ Management Console (IMC) to show the virtual volumes. The demo I saw focused on the 3PAR CLI, but you will get the idea.

August 28, 2014 0 comments

Datacenter Storage Virtualization

vSphere users get just the beta this year at VMworld

by Philip Sellers August 27, 2014

written by Philip Sellers

VMworld has a bit disappointing for core vSphere users this year. Its the first VMworld since at least 2008 where a major release of vSphere wasn’t made during the show. This year, we all have to settle for the vSphere 6 beta which was already publicly available. No news on timelines or release datas for vSphere 6. That’s not to say there isn’t plenty of news on other horizons (pun intended) and initiatives from the company, but for core virtualization, not a lot has been discussed.

VMware did publicly discuss some of the features of the upcoming vSphere 6 release, something everyone who has participated in the beta was unable to do because of non-disclosure agreements. Here is a quick run-down of the features that were publicly discussed:

Compute > Multi-vCPU Fault Tolerance support

Network > vMotion Enhancements across virtual switches and vCenter instances & support for routed vMotion
Storage > Virtual Volumes (vVols) support for storage

vSphere 6 will be bringing a number of improvements in terms of scale and sizing that customers will appreciate. The specifics weren’t covered in the keynote and I have not seen them publicly discussed.

Compute > SMP-FT

vSphere 6 adds multi-vCPU support for Fault Tolerance (SMP-FT), extending this technology to a wider range of uses. Most mission critical apps where Fault Tolerance would likely be adopted were more than 1 vCPU, so this is welcome news for administrators. There are still some limits to the technology, SMP-FT will support up to 4 vCPU and 64GB of RAM. Users will be limited to 4 VM running SMP-FT or 8 total vCPU running SMP-FT. Your FT logging network is required to be 10Gig to support SMP-FT. Julian Wood has some additional details in his blog post on the topic.

Network > vMotion

vMotion gets a number of enhancements, all of which should allow for easier administration. The critical one from an administrator’s point of view is the cross-vSwitch and cross-vCenter vMotion. Much like the shared nothing Storage vMotion that was added in vSphere 5.5, the cross-vCenter vMotion will allow a Virtual Machine to hop port groups between virtual switches, changing assignments. Previously, administrators were limited to either Standard vSwitches with the same port group name in order to cross clusters with vMotion or they needed to extend their Distributed vSwitch across clusters. But crossing a vCenter server is an entirely new capability and this is clearly targeted at multi-site scenarios allowing administrators to move workloads without the requirements of stretching a distributed switch and vCenter across sites. Chris Wahl has an excellent blog post about the new vMotion capabilities.

Storage > vVols

The big, well-discussed feature being added is Virtual Volumes (vVols) support. vVols allows vSphere to talk directly against the storage and provision virtual machines natively, without the need for LUNs. Each virtual machine, natively provisions several files on the storage – one for config, one or more for data and then at boot, the expected RAM files and log files required. This allows the storage administrator to have a native, VMware object level view of the data and using native storage tools, better identify problems and bottlenecks by identifying individual VMs or VM disks instead of a noisy LUN.

If you are familiar with NFS storage vendor Tintri, the whole concept will sound really familiar. With a Tintri, you present one large NFS datastore and then provision VMs inside of it. The storage is VM aware and has a lot of additional performance metrics and management. It allows for things like quality of service at a VM level.

In the vSphere side, the vSphere Administrator is presented with a storage system and they provision against it rather than being presented a LUN and having to format and manage capacity with VMFS datastores and datastore clusters. From the storage administrators view point, instead of having 10 LUNs, they may now have 5 times as many objects within their views. This is where the storage vendor’s implementation becomes a critical point. The views and management consoles will have to adapt and change.

vVols also allows the vSphere administrator to wrap tagging and policy controls around storage. The concept that VMware introduced with the VSAN in vSphere 5.5, policy based storage allows for an abstraction from the array and LUN constructs to a needs-based construct for deploying VMs. What does that mean? Well, to deploy a virtual machine, the user had to make a choice of which datastore to deploy onto. With vSphere 5.5, policies and tagging could allow administrators to define a service profile or level of service abstraction from the physical storage devices and let the user choose options like a Platinum storage location for mission critical applications or a Bronze storage location for dev/test. Those tags and policies allow for the decisions where to place a VM in storage without having to know that Array X is the one the user should use.

In the meantime, all vSphere users will be waiting for the new release and finalization of capabilities. With SMP-FT and vVols, users have been waiting for VMware to deliver these features for a long time and their discussion during the keynote on Tuesday drew lots of applause.

August 27, 2014 0 comments