@olivierlambert I’ve got a few VM’s that lock up from time to time. There is no rhyme nor reason (different hosts, different storage, etc). As a result, I just have a job that restarts them at 5:30 am every day. I’d like to have the software tool software restart them but, in the occasion wher the VM is locked up tight as Fort Knox, I’d like the hard reset to happen. Make sense ?

@cocoon hello! For now we are on reflexion on a refactoring to move towards a system more RBAK based, IAM type. We will inform the whole community when we are sure of the direction the new ACL system will take. Stay tuned

Pinging @stormi about it

@jkatz Thanks for that. I actually did something different but it worked. I don't know how but it is working. I used this in XO in Cloud Config [image: 1747138648336-a5f1ca37-802a-4ff4-bc4f-6c8ccaa3dc97-image.png] It worked [image: 1747138770858-e2666c29-8a03-41e1-879b-b6559b7f0bf2-image.png] Don't know if does it matter or not ( probably does) that I also entered this plugin into both files : cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin @jkatz said in Cloudbase-init on Windows: You don't. That is lame. Wonder if domain join is possible with that...

These two bugs have been fixed in the latest release

Don't worry it's for you

Ping @pdonias

@piotrlotr1 I think my original mini-lab did this, I had mistakenly joined these hosts to the big lab pool, found out is was wrong and detached them to make a mini-lab pool. There were some oddities when I did this, but I just worked past them and created their own pool and did my warm migrations. Wish I had taken better notes of this when I did it. I wiped and rebuilt my mini-lab now, so no going back.

Thanks for fixing this!

@Bastien-Nollet Thanks for the update. In my community edition instance at my church, I just updated it to Master, commit 37fbb so I'll test over the weekend and provide an update. For my XOA (Airgapped) instance at work, I did receive an updated appliance about two weeks ago, so I'll test and see if the problem persists. If it does, then I'll just wait until the official release of XO and then I'll request an updated appliance.

Problem solved with update of XOCE

@Andrew To me the summary answer is no, ha. The content of this system is nothing super important. So replacing it new would be the quicker approach.

@ecoutinho Thanks for chiming in. I managed to figure out the math, but thanks nonetheless.

@Danp It used to be 45 seconds to a minute before, but good to know thank you. I updated my origional reply with the updated information. Thank you for for the help

@dslauter You can test the new RPMs using the testing repository, FYI: sm-3.2.3-1.14.xcpng8.3 and http-nbd-transfer-1.5.0-1.xcpng8.3.

@encryptblockr Yes, and I documented the process I used a while back here: https://xcp-ng.org/forum/topic/6821/cloud-init-success I just use the stock cloud image .ova file as my base image. for Ubuntu templates. I use the noble (24.04) image in quite a few instances from my template with success. Your post mentions cloud-init is not working - some tips to try troubleshooting, when the new VM is provisioned, (assuming you are able to login) I usually run "cloud-init status --wait" and when that completes I run "cloud-init status --long" for a summary of the state. Then you can grep for WARNING in /var/log/cloud-init.log for clues. If you weren't able to login to the VM - make sure your cloud-init config has the userid's, passwords and SSH keys you will need for login. See the example I posted here, since those are what I use in my lab or some variation. Feel free to share any troubleshooting steps you have taken, and I will help any way I can. I have setup hundreds of VM's from templates using cloud-init so I have seen many of the challenges it brings.

We are implementing tests in our CI to detect this issue and protect against regressions, then we'll investigate the cause.

@mbriet Ever figure this out? I'm getting the same exact thing...