I found the root cause, thanks again to David for letting me search in the
logs again. :-)
The key is a value in vm_template_details for that template. So it will be
used everytime I use this template.
Now my question is, is this expected behavior? When using a key during
template creation it will
I did more detailed search within the management-server.log and found this:
"SSH.KeyPairName":"packer_5f635a58-1c36-bd60-b7fa-dc04b5f4c8a2"
We are creating our templates via packer.io, but we do delete the keys
inside the template via packer provisioner. Is CS storing the ssh keypair
with during t
Hi David,
even if I create a VM now the public key will be put in the file for the new
VM. And this key is not in the db. I do not understand where the VR is
getting this key from?
Which logs do you mean? I was looking through /management-server.log with
debug enabled but was unable to find anythi
Not a dev myself, but most probably due to using linked-clones by default -
afaik it's not possible to resize volume there?
On Mon, 12 Oct 2020 at 17:19, Brussk, Michael
wrote:
> Hi Community,
>
>
>
> I was wondering, why automated resize volume test is still disabled with
> note “unsupported on
It could be because the key has been deleted on Cloudstack. Checking the logs
could verify that
From: m...@swen.io
Sent: Thursday, October 15, 2020 2:07 PM
To: users@cloudstack.apache.org
Subject: AW: metadata on VR
Hi,
any idea why a public key which is not in
Hi,
any idea why a public key which is not in the db is put into the public-keys
file on the VR?
Swen
-Ursprüngliche Nachricht-
Von: David Jumani
Gesendet: Mittwoch, 14. Oktober 2020 14:30
An: users@cloudstack.apache.org
Betreff: Re: metadata on VR
Hi Cu,
The database stores the MD5
