Hypervisors now self register in system when they start. Check parameters in isardvdi.cfg

[miguerus]

Hi everyone.
I am new in IsardVdi and I have a question, cus in isardvdi hypervisors list appears this messege " Hypervisors now self register in system when they start. Check parameters in isardvdi.cfg " and I don`t know what to do.
Could you give me some help, please?
Thanks

[Josep Maria Viñolas Auquer]

Well, as each service is containerized, also the KVM virtualization is in it's container that will self register/unregister in system through API REST based on parameters in isardvdi.cfg. But by default with the common 'all-in-one' default setup nothing about needs to be changed in isardvdi.cfg.

The isardvdi.cfg file it is self explanatory abot parameters. If you set up a remote (or multiple remote) hypervisor flavour and a web flavour that controls them, then you'll need to setup at hypervisor isardvdi.cfg at least API_DOMAIN and VPN_DOMAIN to point at the web flavour host to allow self registering and communication between the isard-engine container residing at web flavour host and remote hypervisor.

But, as I've said, this setup is needed only when you are setting IsardVDI in an infrastructure (usually with hypervisors with a network shared storage). For an all-in-one (the default) nothing is needed (maybe the DOMAIN to allow client viewers reach it and LETSENCRYPT_EMAIL if the server has 80/443 ports open to Internet and you want isard-portal to ask for LetsEncrypt certificates and renew them automatically.

Anyway you can find more detailed information at documentation

[miguerus]

Well, as each service is containerized, also the KVM virtualization is in it's container that will self register/unregister in system through API REST based on parameters in isardvdi.cfg. But by default with the common 'all-in-one' default setup nothing about needs to be changed in isardvdi.cfg.

The isardvdi.cfg file it is self explanatory abot parameters. If you set up a remote (or multiple remote) hypervisor flavour and a web flavour that controls them, then you'll need to setup at hypervisor isardvdi.cfg at least API_DOMAIN and VPN_DOMAIN to point at the web flavour host to allow self registering and communication between the isard-engine container residing at web flavour host and remote hypervisor.

But, as I've said, this setup is needed only when you are setting IsardVDI in an infrastructure (usually with hypervisors with a network shared storage). For an all-in-one (the default) nothing is needed (maybe the DOMAIN to allow client viewers reach it and LETSENCRYPT_EMAIL if the server has 80/443 ports open to Internet and you want isard-portal to ask for LetsEncrypt certificates and renew them automatically.

Thank you, jvinolas, I will test it.

[miguerus]

Jvinolas, estuve probando el Isard.
Logre crear desktops, uno en debian 9 y otro con windows 10, doy start al escritorio y arranca, pero al intentar ingresar a traves de la opcion "show", aparece el mensaje para que seleccione de que forma quiero entrar al escritorio y luego no me permite hacer nada. incluso termina reiniciando el host donde tengo montado el isardvdi y luego, al recuperar la conexion al host, hay solo 3 servicios funcionando, y tengo que volver a ejecutar con docker-compose up -d para levantar todo nuevamente, Tienes alguna idea de que puede estar probocando esto, o por lo menos donde buscar?,

Gracias desde ya, y espero no moleste que escribo en español.

[Josep Maria Viñolas Auquer]

The only thing I can think it could be 'killing' container services is exhausting OS memory. In Linux there is the OOM killer daemon that will kill services when hardware memory is being exhausted to keep the OS running. You can check it by issuing dmesg in the terminal and looking for any OOM messages.