Closed flamingdumpster closed 1 week ago
Howdy 🖐 flamingdumpster ! Thank you for your interest in this project. We value your feedback and will respond soon.
If you want to contribute to this project, please make yourself familiar with the CONTRIBUTION
guidelines.
This is the same problem as #1977 , tl;dr vCenter and Go's encoding/xml package marshals []byte
differently. I'm working on a fix and will share the details with that soon. Enhancing vcsim, tests and govc as part of this. Do you have something you can share that decodes AlternateName.Data? A command we can pipe to from govc would be ideal. Or if there's already some Go code available, maybe we bake something into the govc host.storage.info
command.
Do you have something you can share that decodes AlternateName.Data? A command we can pipe to from govc would be ideal. Or if there's already some Go code available, maybe we bake something into the govc
host.storage.info
command.
The AlternateName.Data field is application/vendor specific so no code that would be useful to test with. We are using govmomi inside of a plugin and not govc itself.
I guess the "definition of done" on this, from our point of view, would be that AlternateName.Data contains all of the bytes that vmware is storing for it, and not just the single entry from the json array that we see now. As long as all the data is there, in the same way it is there for pyvmomi, it should be good.
One question - what would be the best way to work around this. I am going to look at doing a soap request directly using the govmomi client for this particular set of information, but am wondering if there is an easier way.
Change is merged and will be creating a new release today. You can test it out using govc, ended up just testing the length: https://github.com/vmware/govmomi/blob/c1d08321559980694a4e2b3b40693cb04aef38f5/govc/test/host.bats#L163-L172
Example with main branch:
% govc host.storage.info -host $host -json | jq -r '.storageDeviceInfo.scsiLun[].alternateName | select(. != null) | .[].data'
TlZNZV9fX19EZWxsX0VudF9OVk1lX1A1NjAwX01VX1UuMl8xLjZUQl9fX19fX19fMDAwMzUwODMwREU0RDI1Qw==
TlZNZV9fX19EZWxsX0VudF9OVk1lX1A1NTAwX1JJX1UuMl8zLjg0VEJfX19fX19fMDAwMzRCQkYwMEU0RDI1Qw==
AAAAAwCAgw==
null
AQIACABQQwAAAAAA
AAAABQCAg7Cx
UEhZSDExOTQwMkNSMjQwSiAgICA=
AgEAREFUQSAgICAgU1NEU0NLS0IyNDBHOFIgICAgICAgICAgICAgICAgICAgICAgICAgIFBIWUgxMTk0MDJDUjI0MEogICAg
ALAAPAAAAAgCAAAAAAAAAAAAAAAA//8AAAABAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
ALEAPAABAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
vs 0.37.3 release:
% ./govc host.storage.info -host $host -json | jq -r '.storageDeviceInfo.scsiLun[].alternateName | select(. != null) | .[].data'
Njc=
Njc=
LTEyNQ==
null
MA==
LTc5
MzI=
MzI=
MA==
MA==
Describe the bug
When using mo.HostSystem.Properties and specifying nil for ps, ScsiLun.AlternateName.Data is only populated with the first (least most significant) item in the json array that is stored in the vmware database. For each entry in AlternateName in the GENERIC_VPD namespace, the Data field should contain the inquiry data for the VPDs as reported available by the standard inquiry and read by vmware. Using govmomi, we can only get the least most significant entry in the array (internally represented by vmware and visible using the vm-support command to see the vmware-vimdump file.) This value will show up as 1-3 bytes, depending on the number (i.e.. 125 appears as '313235') - see output below.
To Reproduce Steps to reproduce the behavior:
This is the code I am using to see the issue
Expected behavior for GENERIC_VPD namespace, the Data field should contain the full amount of data stored in the json array in the vmware internal database. It currently only gets the single digit, as explained above. It also appears other namespaces have the same issue.
Affected version github.com/vmware/govmomi v0.36.2
Screenshots/Debug Output
the output appears like this when the above code is run.
Additional context Using pyvmomi, we are able to see this data without an issue. Both libraries should provide the same functionality.