Container VM never starts on vic backed by vvol datastore.

[SlickWish]

VIC Version:

0.1 / master / 7ed76a8

Code

docker -H 172.22.44.132:2376 --tls run busybox

Expected behavior:
Virtual machine gets added to the resource pool and VM/Container started.
Actual behavior:
Virtual machine is created but never started. Never gets added to resource pool.
Logs from host indicate a problem with Mkdir. The code seems to indicate special handling for vsan so I assumed it'd be similar for a vvol datastore

Changinging session.go and datastore.go from

return dsType == types.HostFileSystemVolumeFileSystemTypeVsan

to

return (dsType == types.HostFileSystemVolumeFileSystemTypeVsan) || (dsType == types.HostFileSystemVolumeFileSystemTypeVVOL)

seems to help

[matthewavery]

@SlickWish I will need more details as well as the log bundle from your vch deployment. Is this really version 0.1? this functionality was not supported in version 0.1 of VIC. The log bundle can be retrieved from the vicadmin service that is also launched on a successful vic-machine create.

[SlickWish]

No, the version is a mistake, but the 7ed76a8 should be correct.

I will pull the latest and try to get the logs you need. Do you have access to a vvol environment?

[matthewavery]

@SlickWish I do not have access to a vvol environment at the moment. I am working on getting access to one in the future. Please let me know what happens when you try with the latest version.

[mdubya66]

@matthewavery I'm working on getting us a vvol setup. @hickeng should chime in on this one though as it may not be so simple, given our reliance on vmdk's.

I'm keeping this in GA for now but it may move to Icebox as vvol's was not a requirement for the 1.0

[SlickWish]

Sorry I haven't had the time to reproduce this yet, but if you do make the change I had suggested it does appear to work. For vvols each vmdk becomes a separate SAN volume. On my array it starts with the base and writes it, then does a some sort of fastclone and writes the next layer. In the end it creates a tree of snapshots / volumes.

[mdubya66]

Moving to Icebox per 9/20 Triage

[matthewavery]

@SlickWish We will definitely be looking into this more in the future. Once we have a vvol setup ready for testing I will apply your change and test it some more.

[stuclem]

Already in the release notes, so removing the kind/note tag.

[mhagen-vmware]

needs an estimate before going into backlog, please @matthewavery

[hickeng]

Changing to feature as it's a request for vvol support.

[awninc]

I would like to add in my support for seeing VVols supported for docker volume backed storage. A very compelling reason is that a lot of newer AFA's support volume snapshotting/replication (regular volumes & VVols). You are then able to create and apply storage policies to your persistent docker volumes, and even clone/restore those volumes from point-in-time snapshots, replicate to other Arrays, etc.

This would certainly help solve the issue of needing multiple systems to ensure persistent volume data is backed up, and also help with managing your docker persistent volumes and keeping them separate from other storage resources.

[mamatadesai]

With VVols, the storage array can have tailor-made volumes based on what the container needs. The layer of VMFS can be removed as well, bringing goodness to snapshots, offloading to the storage array.

[renmaosheng]

closing the long lived issue, if you still needs this please file a new bug with specific requirement description and justification for the request. thanks.