Hi there,
I've come across this issue a couple of times but can't seem to get past it this time. Right now it's happening trying to restore a VM to a host, but it happens fairly regularly backing up as well. The error in pure says:
"Error creating the VM: cannot login host_name: Login error for https://host_name:443/sdk: InvalidLogin: Cannot complete login due to an incorrect user name or password."
On the host there are a couple of errors, one in events: "User cannot logon since the user is already logged on."
In tasks: "Failed - Invalid configuration for device '11'."
I've come across this before backing up two hosts to one Pure instance and for the most part fixed it by staggering the backup timing. Most nights it succeeds but I still have the odd failed backup. My thinking for this is login timeouts.
However this time trying to restore a machine, I managed to restore one machine but haven't been able to do any more, it keeps giving me this error. I've tried different host accounts, changing the login timeout, even waiting days to try again. This time I haven't been able to get past it.
Apart from this Pure has been working so great!
Thanks.
Ps. I also seem to be getting a lot of errors on this forum at the moment..
Hi Luke,
Login errors like the ones that you describe did occur in the past but I thought we fixed all of those. Which version of Pure are you using? Which deployment type (VM, NAS device, your own Linux)?
I think you should be able to reset the login state by restarting Pure (either via 'stop.sh' and 'start.sh' scripts, by selecting the corresponding option in the console menu or via your NAS device GUI, depending on the way you have deployed Pure). Restarting should log you out or rather, force the vSphere to issue new credentials. In any case, I would be interested in looking at your logs to see what exactly is happening and try to figure out the sequence of events that triggered this behaviour.
----
'Invalid configuration for device 11' is a separate issue, not related to login. It could mean that the VM configuration of the backed up VM has a setting that the target host for the restore does not accept. Such examples could include unsupported Cdrom device type, unsupported network card setting, virtual video card memory not being set, etc. We correct all these issues as we discover them, but since they are nowhere documented, it is always possible we missed something. In many cases a configuration item will be supported by a vCenter and the VM will run perfectly fine but when Pure tries to create a new VM with the same setting on the ESXi directly (sometimes even on the same vCenter), the setting will be refused.
In any case, VMware logs should give you more detail about the exact problem, at least enough to identify the offending 'device 11'.
Btw., the bugfix for the 'video memory being set to 0' issue that I mentioned earlier has not yet been released so one thing you can try is opening the VM configuration in vSphere and make sure that the virtual video card has the memory size set to something other than 0.
Also, the issue might be caused by a heavy load on your system either due to backups/restores or due to some other cause if you are using distributed switches. Maybe this KB article https://kb.vmware.com/s/article/2006809 can give you some ideas.
----
I will contact you by email about sending us the log files. And I'm sorry about the forum software misbehaving. One of the plugins occasionally messes something after auto-updating and prevents logins.
Thanks for the reply! For reference I'm using the Pure VM image.
Restarting the Pure application cleared the login errors thank you!
The device '11' issue ended up being related to the network card - so was a matter of removing the device before backing up to move the machine to our other host.. I guess these errors aren't a big deal if they're being restored to the same host, but in this case restoring to a different host just required a couple extra steps.
Thanks again!
Glad to hear that everything worked out for you. However, I am still very interested in examining the log files and trying to find the real cause of this behaviour. This especially goes for the network card problem as we would like Pure to work hassle free in all such cases.
I would really be grateful if you would send me the log files anyway and maybe copy/paste the relevant lines from VMware logs. I am confident we can fix this issue and allow Pure to restore VMs properly regardless of the target host type.
Hi, thank you for the logs that you sent me. Although they do not contain any trace of 'invalid configuration for device 11', they do show a lot of login errors. Please update to Pure 2.0.7 in order to fix those.
Afterwards, if possible, try a backup and restore again with the same (problematic) network card settings. If you get the 'invalid configuration...' error, please send me the logs again.
Cheers
This issue has been confirmed as resolved by @luke_tearle and will be included in Pure version 2.0.8. Here is just a quick recap of the things we found out while solving this.
The problem was caused by an invalid VM configuration setting. The virtual network card had a property 'uptCompatibilityEnabled' set to 'true'. As can be seen in the official VMware documentation,
Indicates whether UPT(Universal Pass-through) compatibility is enabled on this network adapter. UPT is only compatible for Vmxnet3 adapter. Clients can set this property enabled or disabled if ethernet virtual device is Vmxnet3.
Since vSphere API 6.0
this property is supported only on 'Vmxnet3' type network cards. Luke had a 'VirtualE10000e' type card which does not support this property and this caused the VM creation to fail.
There are a number of similar undocumented ways for a VM configuration to enter invalid state over time. This usually does not prevent the VM from functioning normally but it does cause failures when a new VM with the same configuration is created or even when the same VM is migrated. Archiware Pure already handles many such examples automatically but the experience has thought us that there will always be some more undocumented cases to handle. Since it is impossible to predict every VM configuration state and its interaction with every possible ESXi/vCenter configuration, we will have to handle such cases as their appear. In this we greatly appreciate your help and feedback.