We have one test cluster that we use to test all sort of failures. This time all hosts on this specific test cluster were failed such that the SSVM and CPVM also failed. This seem to prevent the management server to start any new CPVM on any other clusters, but the SSVM creation were fine. A new CPVM was started on the production cluster as soon as I deleted the CPVM the failed test cluster.
Is this an expected blocking behaviour on the CPVM management logic? Regards, Antoine Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. > On Dec 8, 2022, at 12:39 PM, [email protected] wrote: > > Hmmm... well i guess turn ssl encryption off in global settings and > afterwards restart SSVM and depending on your overall setup the mgmt server. > Never have performed this before so i would suggest to dig a bit through the > documentation and wiki for this topic. > > Regards > > Am Do., 8. Dez. 2022 um 16:52 Uhr schrieb Antoine Boucher > <[email protected] <mailto:[email protected]>>: >> What is the simplest way to disable ssl? Global setting then WebUI? >> >> >> >> Antoine Boucher >> [email protected] <mailto:[email protected]> >> [o] +1-226-505-9734 >> www.haltondc.com <http://www.haltondc.com/> >> >> “Data security made simple” >> >> >> <HDClogo7-small.png> >> >> >> Confidentiality Warning: This message and any attachments are intended only >> for the use of the intended recipient(s), are confidential, and may be >> privileged. If you are not the intended recipient, you are hereby notified >> that any review, retransmission, conversion to hard copy, copying, >> circulation or other use of this message and any attachments is strictly >> prohibited. If you are not the intended recipient, please notify the sender >> immediately by return e-mail, and delete this message and any attachments >> from your system. >> >> >>> On Dec 8, 2022, at 4:28 AM, [email protected] <mailto:[email protected]> wrote: >>> >>> Hi Antoine, >>> >>> without any log files this is going to be quiet challangeing. >>> The log in DEBUG level or 'worse' TRACE on the management server should at >>> least give some information that >>> a) a console proxy is missing >>> b) the deployment should start >>> c) that a deployment fails / timed out >>> or what else is currently not working properly. >>> >>> How ever: have you tried to disable SSL configuration for the whole setup=? >>> Just to get a idea where to search onwards from this point on? >>> >>> Regards >>> >>> Am Do., 8. Dez. 2022 um 01:52 Uhr schrieb Antoine Boucher < >>> [email protected] <mailto:[email protected]>>: >>> >>>> I now see that the certificates should be in Keystore table and all seems >>>> ok. >>>> >>>> Does anyone have any suggestion? It is becoming critical as we can not >>>> get to any vm consoles. >>>> >>>> Regards, >>>> Antoine >>>> >>>> >>>> >>>> Confidentiality Warning: This message and any attachments are intended >>>> only for the use of the intended recipient(s), are confidential, and may be >>>> privileged. If you are not the intended recipient, you are hereby notified >>>> that any review, retransmission, conversion to hard copy, copying, >>>> circulation or other use of this message and any attachments is strictly >>>> prohibited. If you are not the intended recipient, please notify the sender >>>> immediately by return e-mail, and delete this message and any attachments >>>> from your system. >>>> >>>> >>>>> On Dec 7, 2022, at 7:34 AM, Antoine Boucher <[email protected] >>>>> <mailto:[email protected]>> >>>> wrote: >>>>> >>>>> We still have not found any resolution and still no console proxy. >>>>> >>>>> We had to change the ssl certificate at the same time. However, I was >>>> looking at the database and I see that the sslcerts table is empty so are >>>> any other tables with name containing the word “cert” are also empty. Is >>>> this normal? >>>>> >>>>> Regards, >>>>> Antoine >>>>> >>>>>> On Dec 6, 2022, at 7:39 AM, Nux <[email protected] <mailto:[email protected]>> >>>>>> wrote: >>>>>> >>>>>> There could be a few reasons. >>>>>> Make sure your management and hypervisor logs are set to DEBUG when you >>>> are investigating. >>>>>> If nothing shows up on the management side, keep an eye on the >>>> hypervisor, see if a VM creation is even attempted, check libvirt (or >>>> whatever) logs etc. >>>>>> >>>>>> --- >>>>>> Nux >>>>>> www.nux.ro <http://www.nux.ro/> >>>>>> >>>>>> On 2022-12-06 04:37, Antoine Boucher wrote: >>>>>>> Hello, >>>>>>> We had a failure with a secondary storage that created several issues. >>>>>>> Nevertheless, after fixing the issues, we discovered that the system >>>>>>> consoleproxy and secondarystorage vm were hung. >>>>>>> We deleted both system VMs, the secondarystorage vm came back without >>>>>>> issues, but the consoleproxy vm is not being created. >>>>>>> We will investigate further, but we have found nothing out of the >>>>>>> ordinary in the management log file so far. >>>>>>> Has anyone had a similar issue before? >>>>>>> Regards, >>>>>>> Antoine >>>>>>> Confidentiality Warning: This message and any attachments are intended >>>>>>> only for the use of the intended recipient(s), are confidential, and >>>>>>> may be privileged. If you are not the intended recipient, you are >>>>>>> hereby notified that any review, retransmission, conversion to hard >>>>>>> copy, copying, circulation or other use of this message and any >>>>>>> attachments is strictly prohibited. If you are not the intended >>>>>>> recipient, please notify the sender immediately by return e-mail, and >>>>>>> delete this message and any attachments from your system. >>>>> >>>> >>>> >>
