Re: Creating Windows Server 2019 templates with cloudbase init

[simon.voelker]

Hi,

Thanks! That’s very helpful.

For resetting the password I had a timing issue, I think. Did you try a reset 
of the password and reboot the VM twice? I believe that worked for me during 
testing.

Regards
Simon

> On 14. Jan 2020, at 19:13, Ismaili, Liridon (SWISS TXT) 
>  wrote:
> 
> Hi,
> @Simon:
> There is a config (found in 
> 
>  
> https://cloudbase-init.readthedocs.io/en/latest/plugins.html#setting-password-main)
>  called first_logon_behavior which you can set to 'no'. This will allow you 
> to setup the password with no need to be reset after the first login.
> So this one was indeed a cloudbase-init "feature". I did test that and it 
> works fine for me under MS Windows Server 2019.
> 
> What I get now is, that cloudbase-init allows me to set the password only 
> once - so I can't reset it after the first launch of the instance. I did 
> create an issue for this one but I believe that this was by design.
> 
> Regards
> Liridon
> 
> -Original Message-
> From: n...@li.nux.ro
> Reply-To: users@cloudstack.apache.org
> To: users@cloudstack.apache.org
> Subject: Re: Creating Windows Server 2019 templates with cloudbase init
> Date: Tue, 14 Jan 2020 13:43:04 +
> Mailer: Roundcube Webmail/1.4-rc1
> 
> 
> It's quite possible. I try to do the minimum where Windows is concerned,
> 
> so I stopped at using the old CloudInstanceManager when I saw it's
> 
> working.
> 
> 
> 
> On 2020-01-14 13:28,
> 
> 
> 
> simon.voel...@zv.fraunhofer.de
> 
> wrote:
> 
> Hi,
> 
> 
> I believe that having to set a new password after it has been reset is
> 
> supposed to be a feature from Microsoft’s side. I’ve also noticed that
> 
> login through RDP is disabled until a new password has been set. So
> 
> far I haven’t been able to get it to work completely. (mainly due to
> 
> time constraints)
> 
> 
> Regards
> 
> 
> Simon Völker
> 
> 
> Fraunhofer-Gesellschaft e.V.
> 
> Schloss Birlinghoven
> 
> 53754 Sankt Augustin
> 
> Telefon: +49 2241 14-2311
> 
> E-mail:
> 
> 
> 
> simon.voel...@zv.fraunhofer.de
> 
>  
> 
> 
> simon.voel...@zv.fraunhofer.de
> 
>> 
> 
> 
> 
> 
> Am 14.01.2020 um 14:20 schrieb
> 
> 
> 
> n...@li.nux.ro
> 
>  
> 
> 
> n...@li.nux.ro
> 
>> :
> 
> 
> Hi,
> 
> 
> This could be a bug (or undocumented feature, ahem) with
> 
> cloudbase-init.
> 
> Despite efforts I never got it to work reliably in the past, not sure
> 
> about now.
> 
> Have you tried using CloudInstanceManager.msi for setting the
> 
> password? It still works for me.
> 
> 
> What I do is set up the template with a sysprep and unattend.xml where
> 
> I also set a default password (perhaps this is what stops it from
> 
> asking for new user pass), then on first boots CloudInstanceManager
> 
> sets up the password without problems and resets work, too. SG zone
> 
> btw.
> 
> 
> Lucian
> 
> 
> On 2020-01-14 12:53, Ismaili, Liridon (SWISS TXT) wrote:
> 
> Hi Simon
> 
> We are also building some new windows templates and would like to use
> 
> cloudbase-init as you do.
> 
> I get the same behavior as you did describe (after password reset it
> 
> requires to setup a new password). How did you workaround this? I
> 
> expect this to be a policy issue but would like to ask before I search
> 
> to long as you had the same issue.
> 
> Regards
> 
> Liridon
> 
> -Original Message-
> 
> From:
> 
> 
> 
> simon.voel...@zv.fraunhofer.de
> 
>  
> 
> 
> simon.voel...@zv.fraunhofer.de
> 
>>  
> 
> 
> simon.voel...@zv.fraunhofer.de
> 
>> 
> 
> Reply-To:
> 
> 
> 
> users@cloudstack.apache.org
> 
>  
> 
> 
> users@cloudstack.apache.org
> 
>>  
> 
> 
> users@cloudstack.apache.org
> 
>> 
> 
> To:
> 
> 
> 
> users@cloudstack.apache.org
> 
>  
> 
> 
> users@cloudstack.apache.org
> 
>>  
> 
> 
> users@cloudstack.apache.org
> 
>> 
> 
> Subject: Re: Creating Windows Server 2019 templates with cloudbase init
> 
> Date: Mon, 09 Sep 2019 07:54:02 +
> 
> Hi,
> 
> we are using cloudplatform 4.11 which is based on cloudstack 4.10.
> 
> Regards
> 
> Simon Völker
> 
> Fraunhofer-Gesellschaft e.V.
> 
> Schloss Birlinghoven
> 
> 53754 Sankt Augustin
> 
> Telefon: +49 2241 14-2311
> 
> E-mail:
> 
>  
> 
> 
> simon.voel...@zv.fraunhofer.de
> 
>> 
> 
> 
> 
> simon.voel...@zv.fraunhofer.de
> 
>  
> 

Re: Creating Windows Server 2019 templates with cloudbase init

[simon.voelker]

Hi,

I believe that having to set a new password after it has been reset is supposed 
to be a feature from Microsoft’s side. I’ve also noticed that login through RDP 
is disabled until a new password has been set. So far I haven’t been able to 
get it to work completely. (mainly due to time constraints)

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail: simon.voel...@zv.fraunhofer.de



Am 14.01.2020 um 14:20 schrieb n...@li.nux.ro:

Hi,

This could be a bug (or undocumented feature, ahem) with cloudbase-init.
Despite efforts I never got it to work reliably in the past, not sure about now.
Have you tried using CloudInstanceManager.msi for setting the password? It 
still works for me.

What I do is set up the template with a sysprep and unattend.xml where I also 
set a default password (perhaps this is what stops it from asking for new user 
pass), then on first boots CloudInstanceManager sets up the password without 
problems and resets work, too. SG zone btw.

Lucian

On 2020-01-14 12:53, Ismaili, Liridon (SWISS TXT) wrote:
Hi Simon
We are also building some new windows templates and would like to use
cloudbase-init as you do.
I get the same behavior as you did describe (after password reset it
requires to setup a new password). How did you workaround this? I
expect this to be a policy issue but would like to ask before I search
to long as you had the same issue.
Regards
Liridon
-Original Message-
From: 
simon.voel...@zv.fraunhofer.de
Reply-To: 
users@cloudstack.apache.org
To: 
users@cloudstack.apache.org
Subject: Re: Creating Windows Server 2019 templates with cloudbase init
Date: Mon, 09 Sep 2019 07:54:02 +
Hi,
we are using cloudplatform 4.11 which is based on cloudstack 4.10.
Regards
Simon Völker
Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail:

simon.voel...@zv.fraunhofer.de
mailto:simon.voel...@zv.fraunhofer.de>
simon.voel...@zv.fraunhofer.de
Am 06.09.2019 um 15:34 schrieb Andrija Panic <

andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com>
andrija.pa...@gmail.com
:
That sounds like something that was happening on ACS 4.8.
Which version are you running?
Andrija
On Fri, 6 Sep 2019 at 14:50, <

simon.voel...@zv.fraunhofer.de
mailto:simon.voel...@zv.fraunhofer.de>
simon.voel...@zv.fraunhofer.de
wrote:
Hi,
I’ve checked that and found something peculiar: The password is retrieved
from the VPR if I do a password reset, reboot and reboot again. However,
upon first login with the password generated by the reset, Windows requires
a new password to be set. The password shows up in the passwords file on
the vpr, but isn’t replaced by password=saved, it simply disappears when
retrieved.
Regards
Simon Völker
Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail:

simon.voel...@zv.fraunhofer.de
mailto:simon.voel...@zv.fraunhofer.de>
simon.voel...@zv.fraunhofer.de
mailto:simon.voel...@zv.fraunhofer.de>
simon.voel...@zv.fraunhofer.de
mailto:simon.voel...@zv.fraunhofer.de>
simon.voel...@zv.fraunhofer.de
Am 06.09.2019 um 11:23 schrieb Andrija Panic <

andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com>
andrija.pa...@gmail.com
mailto:andrija.pa...@gmail.com>
andrija.pa...@gmail.com
:
Hi Simon,
I assume that the cloudbased-init runs BEFORE the user has to set pass via
Windows, thus overwriting the pass that ACS has previously set?
Does rebooting the VM actually sets the new pass (from ACS), that was
generated previously? You can actually check inside the VR
/var/cache/cloud/password- file - this file will contain
the actual pass if it has NOT been fetched by the VM - or if it says
"password=saved" - this means it was already fetched by the VM.
Andrija
On Fri, 6 Sep 2019 at 10:47, <

simon.voel...@zv.fraunhofer.de
mailto:simon.voel...@zv.fraunhofer.de>
simon.voel...@zv.fraunhofer.de
mailto:simon.voel...@zv.fraunhofer.de>
simon.voel...@zv.fraunhofer.de
mailto:simon.voel...@zv.fraunhofer.de>
simon.voel...@zv.fraunhofer.de
wrote:
Hi,
I am currently doing a new batch of our templates. So far we’ve been using
Cloudbase-init for our Microsoft Server 2016 templates. Now with the 2019
version, instead of setting the password that cloudstack provides, the user
has to set a password on first startup. Does someone have experience with
Cloudbase-init and Windows Server 2019 or has faced the same 

Re: Creating Windows Server 2019 templates with cloudbase init

[simon.voelker]

Hi,

we are using cloudplatform 4.11 which is based on cloudstack 4.10.

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail: simon.voel...@zv.fraunhofer.de



Am 06.09.2019 um 15:34 schrieb Andrija Panic 
mailto:andrija.pa...@gmail.com>>:

That sounds like something that was happening on ACS 4.8.
Which version are you running?

Andrija

On Fri, 6 Sep 2019 at 14:50, 
mailto:simon.voel...@zv.fraunhofer.de>> wrote:

Hi,

I’ve checked that and found something peculiar: The password is retrieved
from the VPR if I do a password reset, reboot and reboot again. However,
upon first login with the password generated by the reset, Windows requires
a new password to be set. The password shows up in the passwords file on
the vpr, but isn’t replaced by password=saved, it simply disappears when
retrieved.

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail: 
simon.voel...@zv.fraunhofer.demailto:simon.voel...@zv.fraunhofer.de>>



Am 06.09.2019 um 11:23 schrieb Andrija Panic 
mailto:andrija.pa...@gmail.com>
>:

Hi Simon,

I assume that the cloudbased-init runs BEFORE the user has to set pass via
Windows, thus overwriting the pass that ACS has previously set?
Does rebooting the VM actually sets the new pass (from ACS), that was
generated previously? You can actually check inside the VR
/var/cache/cloud/password- file - this file will contain
the actual pass if it has NOT been fetched by the VM - or if it says
"password=saved" - this means it was already fetched by the VM.

Andrija

On Fri, 6 Sep 2019 at 10:47, 
mailto:simon.voel...@zv.fraunhofer.de>mailto:simon.voel...@zv.fraunhofer.de>>> wrote:

Hi,

I am currently doing a new batch of our templates. So far we’ve been using
Cloudbase-init for our Microsoft Server 2016 templates. Now with the 2019
version, instead of setting the password that cloudstack provides, the user
has to set a password on first startup. Does someone have experience with
Cloudbase-init and Windows Server 2019 or has faced the same issue?

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail: 
simon.voel...@zv.fraunhofer.demailto:simon.voel...@zv.fraunhofer.de>>mailto:simon.voel...@zv.fraunhofer.de>>





--

Andrija Panić



--

Andrija Panić

Re: Creating Windows Server 2019 templates with cloudbase init

[simon.voelker]

Hi,

I’ve checked that and found something peculiar: The password is retrieved from 
the VPR if I do a password reset, reboot and reboot again. However, upon first 
login with the password generated by the reset, Windows requires a new password 
to be set. The password shows up in the passwords file on the vpr, but isn’t 
replaced by password=saved, it simply disappears when retrieved.

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail: simon.voel...@zv.fraunhofer.de



Am 06.09.2019 um 11:23 schrieb Andrija Panic 
mailto:andrija.pa...@gmail.com>>:

Hi Simon,

I assume that the cloudbased-init runs BEFORE the user has to set pass via
Windows, thus overwriting the pass that ACS has previously set?
Does rebooting the VM actually sets the new pass (from ACS), that was
generated previously? You can actually check inside the VR
/var/cache/cloud/password- file - this file will contain
the actual pass if it has NOT been fetched by the VM - or if it says
"password=saved" - this means it was already fetched by the VM.

Andrija

On Fri, 6 Sep 2019 at 10:47, 
mailto:simon.voel...@zv.fraunhofer.de>> wrote:

Hi,

I am currently doing a new batch of our templates. So far we’ve been using
Cloudbase-init for our Microsoft Server 2016 templates. Now with the 2019
version, instead of setting the password that cloudstack provides, the user
has to set a password on first startup. Does someone have experience with
Cloudbase-init and Windows Server 2019 or has faced the same issue?

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail: 
simon.voel...@zv.fraunhofer.demailto:simon.voel...@zv.fraunhofer.de>>





--

Andrija Panić

Creating Windows Server 2019 templates with cloudbase init

[simon.voelker]

Hi,

I am currently doing a new batch of our templates. So far we’ve been using 
Cloudbase-init for our Microsoft Server 2016 templates. Now with the 2019 
version, instead of setting the password that cloudstack provides, the user has 
to set a password on first startup. Does someone have experience with 
Cloudbase-init and Windows Server 2019 or has faced the same issue?

Regards

Simon Völker

Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail: simon.voel...@zv.fraunhofer.de

Re: cloudstack reset VM password files

[simon.voelker]

Hi,

I can also highly recommend cloud-init. We use it for our templates as well. 
There is also a Windows analogue of it (https://cloudbase.it/cloudbase-init/) 
that I recently used to finally get password functionality to work properly on 
Windows Server 2016.


Simon Völker

Fraunhofer-Gesellschaft e.V.
Schloss Birlinghoven
53754 Sankt Augustin
Telefon: +49 2241 14-2311
E-mail: simon.voel...@zv.fraunhofer.de



Am 07.11.2018 um 09:55 schrieb Yordan Kostov 
mailto:yordan.kos...@worldsupport.info>>:

Thank you René,

I will take it from here and test it. Some documentation will be on the way as 
well.

Best regards,
Jordan

-Original Message-
From: Rene Moser [mailto:m...@renemoser.net]
Sent: Wednesday, November 7, 2018 10:46 AM
To: users@cloudstack.apache.org
Subject: Re: cloudstack reset VM password files

Hi

Nowadays the cloud-init [1] project supports cloudstack out of the box and we 
switched our templates to only use cloud-init.

Unfortunately the docs regarding cloudstack is not that great (it is on my list 
to give back my finding). There are some great docs here 
https://wiki.archlinux.org/index.php/Cloud-init.

Our config under config dir /etc/cloud/cloud.cfg.d/ has two files

- 80_root.cfg
- 99_cloudstack.cfg

80_root.cfg contents is...

system_info:
 default_user:
   name: root
disable_root: 0
ssh_pwauth: 1

...and 99_cloudstack.cfg looks like...

datasource:
 CloudStack: {}
 None: {}
datasource_list:
 - CloudStack

Note that cloud-init has a ton of great features beside the support of 
cloudstack.

Hope that helps

René

[1] https://cloudinit.readthedocs.io/en/latest/

Re: Windows Server 2016 Templates for Cloudstack

[simon.voelker]

Thank you, I’ll look into it.


Simon Völker
Fraunhofer-Gesellschaft e.V.
Abteilung C7 Kommunikationsmanagement
Schloss Birlinghoven IZB, 53754 Sankt Augustin
Telefon: (02241) 14-2311
E-mail: simon.voel...@zv.fraunhofer.de



Am 27.07.2018 um 11:09 schrieb Dag Sonstebo 
mailto:dag.sonst...@shapeblue.com>>:

Hi Simon,

With regards to hostname this should just be a question of setting your Windows 
template to pick up hostname from DHCP.

Admin passwords – if the existing install doesn’t work you could look at a 
cloud-init derivative for Windows, looks like 
https://cloudbase.it/cloudbase-init/ may do the trick?

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 27/07/2018, 09:53, 
"simon.voel...@zv.fraunhofer.de" 
mailto:simon.voel...@zv.fraunhofer.de>> wrote:

   Hi,

   we are currently updating templates we provide to our customers. However, we 
are running into problems with Windows Server 2016 and the cloudstack 
functionality of setting an administrator password and a hostname. The 
CloudInstanceManager we used for older versions does not seem to work anymore. 
Does anybody know a successor to the Cloud Instance Manager or a workaround to 
make the functions work in Server 2016?

   Regards

   Simon Völker
   Fraunhofer-Gesellschaft e.V.
   Abteilung C7 Kommunikationsmanagement
   Schloss Birlinghoven IZB, 53754 Sankt Augustin
   Telefon: (02241) 14-2311
   E-mail: 
simon.voel...@zv.fraunhofer.de






dag.sonst...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue

Windows Server 2016 Templates for Cloudstack

[simon.voelker]

Hi,

we are currently updating templates we provide to our customers. However, we 
are running into problems with Windows Server 2016 and the cloudstack 
functionality of setting an administrator password and a hostname. The 
CloudInstanceManager we used for older versions does not seem to work anymore. 
Does anybody know a successor to the Cloud Instance Manager or a workaround to 
make the functions work in Server 2016?

Regards

Simon Völker
Fraunhofer-Gesellschaft e.V.
Abteilung C7 Kommunikationsmanagement
Schloss Birlinghoven IZB, 53754 Sankt Augustin
Telefon: (02241) 14-2311
E-mail: simon.voel...@zv.fraunhofer.de

Re: Customer Backup with CS 4.7 and VMWare

[simon.voelker]

Hi,

colleague of Daniel’s here, who has been dealing a lot with volumesnapshot 
problems.

We are currently seeing two problems with the volumesnapshots.
The first is the long running snapshots, they go into the „BackingUp“ state and 
never finish and thus block all further snapshots. These can be fixed 
reasonably easy by hacking the database and setting the stuck snapshot to 
„Error“ Usually the next snapshot resumes normally. This can also happen due to 
restarts of the management service while OVF exports are running. In this case 
the ACPdoctor’s cleanup usually fixes the stale snapshots.

A second issue we are seeing since late last year is snapshots failing because 
they can not locate the volume they are supposed to snapshot. This seems to be 
due to inconsistencies between the database and vmware, specifically in the 
„Path“ and „ChainInfo“ variables. The accelerite support I am working with 
currently is supecting some race condition to cause this for VMs with multiple 
volumes.

The current suspicion is:
root volume snapshot triggers, this causes the creation of vmnamehere-0003.vmdk
data volume snapshot triggers, this causes the creation of vmnamehere-0004.vmdk
Once the snapshot is created, CP will parse the snapshot and then it is copied 
to secondary storage, during this process CP was unable to find the 0004.vmdk 
as part of the snapshot
When parsing the snapshot for the data disk, it does find the 0004.vmdk on 
datastore but not when parsing the snapshot info from vmsd as you can see above 
( notice the snapshot.numSnapshots = "4" in both ( when parsing ROOT and DATA 
disks) the cases)
Later, once the snapshot copying is done. CP will delete the snapshot of the VM 
and then consolidate the disks.
For the root disk cp tries to delete 0003.vmdk after copying, but this fails. 
It marks 0004 as top vmdk though.
CP keeps updating 0004.vmdk, but this vmdk is removed once the Vm runs a 
consolidation.

I’m currently looking to verify this is indeed the root cause of the described 
error.

Regards


Simon Völker
Fraunhofer-Gesellschaft e.V.
Abteilung C7 Kommunikationsmanagement
Schloss Birlinghoven IZB, 53754 Sankt Augustin
Telefon: (02241) 14-2311
E-mail: simon.voel...@zv.fraunhofer.de



Am 08.02.2018 um 09:25 schrieb 
daniel.herrm...@zv.fraunhofer.de:

Hi Sebastián,

Thank you for your answer. This is exactly the same problem we are facing. Some 
customers have >1TB volumes, and it just takes ages to complete them. Which by 
the way would not be the actual problem, but sometimes CS does not even create 
the snapshot from the recurring snapshot policy or, even worse, a snapshot is 
created but never (>7d) finishes and remains in the BackingUp state, causing 
new snapshots of this series not to be created.

I read about a solution with Veeam and Tags (e.g. let the customer tag the 
virtual machines, and Veeam automatically backups the tagged machines), but 
this adds problems such as:

- how to bill the usage of this method?
- We could restore the virtual machine to an earlier state. But if the customer 
accidently deleted the machine, we cannot create it back from the backup as CS 
would not recognize it again.

So... if anyone has further insight, we'd be happy to hear about it. (

Regards
Daniel

On 08.02.18, 08:21, "Sebastian Gomez" 
> wrote:

   Hello Daniel,

   We have the same environment, and the same problem.
   I agree, the volume snapshots are a pain in time needings. Volume snapshot
   does a full copy of the volume through the network from primary storage to
   the secondary. May be there is a storage configuration that could optimize
   this action, but we have iSCSI for primary storage and NFS por secondary...
   For some big volumes it takes up to 8 h to complete the snap.

   This is NOT a sustainable solution.

   Our customers uses backup agents of their backup solutions, and we (as
   providers) have a backup at VMware level (you can find many solutions like
   vRanger, veeam, ...), is the only way that we have found to have a
   disaster-recovery backup of the platform. We are working now on how to
   offer to customers using this backup as a service, facing to have a
   global-unique backup solution (and scalable) for all the platform and users.

   In this way, for example Veeam backup offers many options to allow users to
   recover their own data (configuring access via API), but the problem here
   is that in Cloudstack you can't recover a virtual machine on the
   virtualization layer without informing the cloud-manager...


   Perhaps someone else could light us.




   Regards.





   Atentamente,
   Sebastián Gómez

   On Wed, Feb 7, 2018 at 3:35 PM, 
> 
wrote:

Hi All,

We are using CS 4.7.1 with VMWare Hypervisor and advanced networking in a
private cloud environment.