2015-09-29 08:47 AM
I'm looking for some explanation on why a remnant vvol is left on the source VVOL Datastore every time I storage vmotion a VM off of it to a traitional datastore? For some reason this vvol (.sdd.sf) is left behind and looks like a system vvol, but I am not able to find any documentation on why this is the case. I can't delete it manually and have found that I need to delete the vvol through the VASA Provider in order for it to delete the vvol on the NetApp side, which seems overly complex.
So I was curious if this is a known issue and what might be the cause of it. In my example below, I have migrated the vm (VM1) from this iSCSI VVOL Datastore (multi_iscsi_vvol) to a traditional local datastore on the ESX host, but it still leaves this remnant vvol behind on the iSCSI VVOL Datastore and I am not sure why:
Any advice is appreciate and welcomed.
2015-09-29 09:17 AM
Let me clarify on the deletion. Trying to do the vvol deletion without unmounting/remounting the datastore will invoke and error due to being bound to a handle:
So in order to delete it, I have to unmount and remount the vvol datastore to clear it up and then I could delete it - however this can only be done if other servers are not on the datastore - how else can these be cleaned up? There is another option that I have foiund to work that points to the remnant vvol as being an abandoned vvol (but why??). This one can be done online and simply involves scanning the vvol datastore in question for abandoned vvols - if it finds them, it will clean them up automatically as shown below:
Here I have the remnant vvol bound to a handle for some reason still:
Not being able to unmount the datastore and remount, I can go to the ESX host and scan for abandoned vvols (good luck reading about this command on VMware's site - I didn't find much):
It returns "true" so that means something happened right? If you query your list of vvols bound at this point you will see it is reduced by one (your remnant):
And finally if you go to query your NetApp array you will find the remnant vvol now removed:
However the following questions still need to be answered:
1. Why is this remnant/abandoned vvol left during a storage vmotion?
2. Will this remnant/abandoned vvol be left for every VM migrated between vvol block datastores?
3. What does this remnant/abandoned vvol mean other than it is a system file/vvol?
4. Is the only way to clean this up really to run the abandoned vvol scan on all vvol datastores? What will happen in a DRS setup when stuff is flying around left and right? Sure there has got to be a better way otherwise the suggestion is to stay clear away from VVOLs and its surgical requirements for cleanup
Hoping someone from NetApp engineering/product management can weigh in on this please since I have read all the documentation out there I can find and none of the stuff I am seeing in my testing is documented for the most part in terms of making sense of VVOLs and how they are manipulated manually and automatcially.