-
Notifications
You must be signed in to change notification settings - Fork 95
Supplying a fix for "#836: vm creation is failing on vsanDatastore" #839
Supplying a fix for "#836: vm creation is failing on vsanDatastore" #839
Conversation
# bare minimum VM shell, no disks. Feel free to edit | ||
vmx_file = vim.vm.FileInfo(logDirectory=None, | ||
snapshotDirectory=None, | ||
suspendDirectory=None, | ||
vmPathName=datastore_path) | ||
vmPathName='[' + datastore + '] ') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rename create_vm param from datastore
to vm_path
and it will be good to go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, Thanks!
59381b4
to
697becf
Compare
…anDatastore" Addressing Mark's comment (renaming method parameter to more meaningful name) Correcting the lint errors
697becf
to
8ef06a5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please see comments
@@ -479,7 +476,7 @@ def setUp(self): | |||
si = vmdk_ops.get_si() | |||
error, self.vm = create_vm(si=si, | |||
vm_name=self.vm_name, | |||
datastore=self.datastore_name) | |||
vm_path=self.datastore_name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is still weird... why self.datastore_name actually keep the vm_path ?
I'll approve to unbock , but please investigate as a separate item
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually create_vm
is internally prepares vm_path (vmHome) i.e. vm_path = datastore_name + vmDisplayName
.
So I am going to rename it with 'datastore_name' with more meaningful name to reduce the confusion.
Vm creation was not complaining for vmfs as it doesn't use osfs code path and fails only for vsan as it is objectBased FS and vm-name was appending twice hence the issue.
Testing Done: Yes (both on vsan and vmfs)
vmdk_ops_test.py tests are passing locally and able to create vm successfully.
//CC @ashahi1 @shaominchen