Update README.md to add a known issue regarding storage vmotion of VM [SKIP CI] #1639

lipingxue · 2017-07-26T22:31:00Z

Update README.md to add a known issue regarding storage vmotion of VM.

Update README.md to add a known issue regarding storage vmotion of VM. Minor fix.

shaominchen · 2017-07-26T22:51:26Z

README.md

@@ -163,6 +163,7 @@ logging config format for content details.
 -  Full volume name with format like "volume@datastore" cannot be specified in the compose file for stack deployment. [#1315](https://github.com/vmware/docker-volume-vsphere/issues/1315). It is a docker compose issue and a workaround has been provided in the issue.
 -  Specifying "Datastore Cluster" name during volume creation is not supported. Datastore clusters (as a part of Storage DRS) is a VC feature and not available on individual ESX. [#556](https://github.com/vmware/docker-volume-vsphere/issues/556)
 -  Volume creation using VFAT filesystem is not working currently. [#1327](https://github.com/vmware/docker-volume-vsphere/issues/1327)
+-  Volume is not shown when running ```docker volume ls``` and ```vmdkops_admin volume ls``` command after performing storage vMotion of VM when volume is attached to VM. It is an expected behavior since storage vMotion messes up the location and names of attached vmdk files. [#1618] (https://github.com/vmware/docker-volume-vsphere/issues/1618)


storage vMotion => Storage vMotion

I won't say "messes up", probably "changes" or any word more neutral

Agree, should not mention messes up. Actually are we even able to svmotion when attaching the volume in the default independent mode?

The wording should mention exactly the scenarios where this behavior is observed - volumes attached as independent vs. persistent, impact when the volumes are not attached vs. attached and how to avoid the issue (address volume via qualified name - vol@ds - for example).

ashahi1 · 2017-07-26T23:10:49Z

Please make sure to update gh-pages as well.

govint · 2017-07-27T05:01:30Z

README.md

@@ -163,6 +163,7 @@ logging config format for content details.
 -  Full volume name with format like "volume@datastore" cannot be specified in the compose file for stack deployment. [#1315](https://github.com/vmware/docker-volume-vsphere/issues/1315). It is a docker compose issue and a workaround has been provided in the issue.
 -  Specifying "Datastore Cluster" name during volume creation is not supported. Datastore clusters (as a part of Storage DRS) is a VC feature and not available on individual ESX. [#556](https://github.com/vmware/docker-volume-vsphere/issues/556)
 -  Volume creation using VFAT filesystem is not working currently. [#1327](https://github.com/vmware/docker-volume-vsphere/issues/1327)
+-  Volume is not shown when running ```docker volume ls``` and ```vmdkops_admin volume ls``` command after performing storage vMotion of VM when volume is attached to VM. It is an expected behavior since storage vMotion messes up the location and names of attached vmdk files. [#1618] (https://github.com/vmware/docker-volume-vsphere/issues/1618)


Agree, should not mention messes up. Actually are we even able to svmotion when attaching the volume in the default independent mode?

The wording should mention exactly the scenarios where this behavior is observed - volumes attached as independent vs. persistent, impact when the volumes are not attached vs. attached and how to avoid the issue (address volume via qualified name - vol@ds - for example).

lipingxue · 2017-07-27T18:29:47Z

@govint
See my answer to your questions below.

Actually are we even able to svmotion when attaching the volume in the default independent mode?
[Liping] Yes. In the step that Anup gave, the volume is attached as "

root@sc-rdops-vm02-dhcp-52-237:~# docker volume inspect testVolXXX@sharedVmfs-0
[
    {
        "Driver": "vsphere:latest",
        "Labels": null,
        "Mountpoint": "/mnt/vmdk/testVolXXX@sharedVmfs-0",
        "Name": "testVolXXX@sharedVmfs-0",
        "Options": {},
        "Scope": "global",
        "Status": {
            "access": "read-write",
            "attach-as": "independent_persistent",
            "capacity": {
                "allocated": "13MB",
                "size": "100MB"
            },
            "clone-from": "None",
            "created": "Fri Jul 21 19:07:53 2017",
            "created by VM": "ubuntu-VM0.0",
            "datastore": "sharedVmfs-0",
            "diskformat": "thin",
            "fstype": "ext4",
            "status": "detached"
        }
    }
]

lipingxue · 2017-07-27T18:34:19Z

@govint We have two mode for disk attach, "independent_persistent" and "persistent". I am not quite understand how the disk attach mode will affect the svmotion. Could you explain more?
I believe if the volume is not attached, then svmotion will not affect it, but I need to do some test to verify it.

Address volume via qualified name - vol@ds may not solve this issue if the ds is the datastore where VM resides. For example, svmotion move the vm from ds to ds1, then the volume attached to vm will be put in to the vm folder in ds1 instead of the dockervol folder as we hope.

govint · 2017-07-27T18:52:45Z

When an independent disk is attached to a VM some ops aren't allowed like snaps for example. That's why I was asking if the svmotion happens. The documentation indicates svmotion requires disks in persistent mode - see https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vcenterhost.doc/GUID-A16BA123-403C-4D13-A581-DC4062E11165.html)

lipingxue · 2017-07-27T20:04:36Z

@govint We allow two attach mode. "independent_persistent"(default mode) and "persistent" mode. So both mode attach disk as "persistent". So svmotion should work.

ashahi1 · 2017-07-27T20:28:28Z

@lipingxue Issue #1618 also happens in case of X-vMotion as well since in X-vMotion, we change datastore as well as host of a vm.
Can you please add X-vMotion also? Something like Storage vMotion/X-vMotion

lipingxue · 2017-07-27T21:48:57Z

@ashahi1 As far as I know, you need to shut down VM before running X-vmotion. So it is not a valid test to running X-vmotion when Vm is not shut down.

Address comments from Sam and Govindan. Address comments from Sam and Govindan. Minor fix. Small fix.

lipingxue · 2017-07-27T22:02:30Z

@shaominchen @govint I have addressed your comments and please take a look.

shaominchen

LGTM.

ashahi1 · 2017-07-27T22:44:17Z

@lipingxue Yes, we do allow X-vMotion of a vm from powered-on state. X-vMotion does not needs vm to be shutdown.

lipingxue · 2017-07-31T20:49:10Z

@govint I have addressed your comments, and please review it. Thanks!

govint

Looks good.

Update README.md to add a known issue regarding storage vmotion of VM.

a686bb2

Update README.md to add a known issue regarding storage vmotion of VM. Minor fix.

vmwclabot added the cla-not-required label Jul 26, 2017

shaominchen reviewed Jul 26, 2017

View reviewed changes

govint suggested changes Jul 27, 2017

View reviewed changes

lipingxue force-pushed the svmotion_known_issue.liping branch from 6ae3463 to 63fe482 Compare July 27, 2017 21:55

Address comments from Sam and Govindan.

c11e980

Address comments from Sam and Govindan. Address comments from Sam and Govindan. Minor fix. Small fix.

lipingxue force-pushed the svmotion_known_issue.liping branch from 63fe482 to c11e980 Compare July 27, 2017 22:01

shaominchen approved these changes Jul 27, 2017

View reviewed changes

govint approved these changes Aug 1, 2017

View reviewed changes

lipingxue merged commit 36e24f5 into vmware-archive:master Aug 1, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update README.md to add a known issue regarding storage vmotion of VM [SKIP CI] #1639

Update README.md to add a known issue regarding storage vmotion of VM [SKIP CI] #1639

lipingxue commented Jul 26, 2017

shaominchen Jul 26, 2017

govint Jul 27, 2017

ashahi1 commented Jul 26, 2017

govint Jul 27, 2017

lipingxue commented Jul 27, 2017

lipingxue commented Jul 27, 2017

govint commented Jul 27, 2017

lipingxue commented Jul 27, 2017

ashahi1 commented Jul 27, 2017

lipingxue commented Jul 27, 2017

lipingxue commented Jul 27, 2017

shaominchen left a comment

ashahi1 commented Jul 27, 2017

lipingxue commented Jul 31, 2017

govint left a comment

Update README.md to add a known issue regarding storage vmotion of VM [SKIP CI] #1639

Update README.md to add a known issue regarding storage vmotion of VM [SKIP CI] #1639

Conversation

lipingxue commented Jul 26, 2017

shaominchen Jul 26, 2017

Choose a reason for hiding this comment

govint Jul 27, 2017

Choose a reason for hiding this comment

ashahi1 commented Jul 26, 2017

govint Jul 27, 2017

Choose a reason for hiding this comment

lipingxue commented Jul 27, 2017

lipingxue commented Jul 27, 2017

govint commented Jul 27, 2017

lipingxue commented Jul 27, 2017

ashahi1 commented Jul 27, 2017

lipingxue commented Jul 27, 2017

lipingxue commented Jul 27, 2017

shaominchen left a comment

Choose a reason for hiding this comment

ashahi1 commented Jul 27, 2017

lipingxue commented Jul 31, 2017

govint left a comment

Choose a reason for hiding this comment