@Pilow password: as a global option and passwd: or plain_text_passwd: under users: key are two different things. The first one sets the password for the default user, ubuntu on Ubuntu if I recall correctly, while the others set password for the user specified in the users: key.

Read the docs people

What he is talking about is Security Identifier (SID) and is specific to Windows. Each Windows machine must have a unique SID in an AD environment. Cloned machines will have identical SID which is bad.

The solution to this problem is sysprep, a Windows tool that will reset SID and other parameters so that each Windows installation is uniquely identifiable. This is something done inside a machine, of course, and is not something that can be done on HV level. VMware, and Hyper-V as seen here, have integrated support for invoking sysprep (or equivalent) during the machine cloning process. This is achieved by sending a signal to the management agent inside a machine (e.g. VMware Guest Tools).

As far as I know, XenServer/XCP-ng management agent is rudimentary and does not have this functionality. In world of XenServer/XCP-ng, machine has to be syspreped manually before it is cloned.

@acebmxer Great. These are some YAML basics. You should read more about it . Following AI instructions without understanding is not going to take you far.

@john-c

I feel your pain, however, the main difference between VMware support in Ansible and XenServer/XCP-ng is that VMware has a whole working group with a dozen of regular members and contributors:

https://github.com/ansible/community/wiki/VMware

Major contributors are all Red Hat or VMware employees i.e. people paid to do it. There is no such thing for XenServer/XCP-ng. Citrix never showed any interest in supporting Ansible. Netscaler is the only Citrix product that has a decent Ansible support.

To help you better understand how Ansible as a project works, here are some points from my personal adventure:

• To be able to contribute new modules to Ansible or any of the official collections, you need to implement extensive unit and integration tests. I understand the requirement. Ansible/Red Hat wants to maintain a high level of quality and to easily (and in automated way) detect any regressions. That's all good but implementing tests is harder and more work than implementing modules themselves. What's very very helpful in case of VMware is that there is a whole simulator called govcsim developed by VMware. You can test your modules against the simulator with ease and automate all the tests with little effort. To my knowledge, there is no simulator available for XenAPI. If such simulator does exist, it is most likely kept in secret by Citrix. If Citrix was ever to release this simulator, that would be a HUGE step forward.
• If you want to contribute new modules to Ansible or any of the official collections, someone has to review your code. Not many people are willing to do so and have the power to include your code to Ansible. As a matter of fact, finding reviewers and begging them for help is the hardest thing of all. I had some tremendous luck to acquire the interest of Abhijeet Kasurde, one of the top Ansible guys, to review my code and to eventually include xenserver_guest_* modules into Ansible. The guy handles VMware in Ansible... surprise! My xenserver_guest module was included without any unit or integration tests but for other modules I had to implement them. Luckily, they were simple and I had a luck to find a reviewer for tests also. When I wanted to upgrade xenserver_guest module with new functionality, they required unit and integration tests. I eventually implemented tests for xenserver_guest module but it was a huge undertaking and the amount of code involved easily dwarfed the module itself. I basically ended up implementing a barebone XenAPI simulator. This is where I hit a road block. No one, even the people that initially supported me, wanted to review this monstrosity of test+simulator. It was never included in Ansible.
• If you don't want to rely on external reviewers then you have to form a team, or if possible, a work group. That way you can review each others code and include it in Ansible without external support. Everything is pretty much handled by bots. If you gain a high enough status in Ansible project, you could get permissions to merge the code yourself without relying on anyone, not even bots. Should I mention that I failed to ever find any good Python programmer that is into Ansible and interested enough to form a team with me?
• You can skip all this struggle if you just maintain you own collection of modules but then you cannot rely on existing Ansible tooling that will do all the testing, linting, sanity checks, spell checks and such. You are on your own.

After a lot of struggle I eventually lost any interest as I was wasting a lot of time and life had to go on. Not much people showed interest in xenserver_guest_* Ansible modules either. My employer also ditched XenServer/XCP-ng in favor of VMware a few years back. Even with all the Broadcom/VMware situation, we got a super good deal with Broadcom because of our deployment size and commitment so we are sticking with VMWare.

All in all, if Ansible support for XenServer/XCP-ng and Xen Orchestra on par with VMware support is ever to see the light of day, these prerequisites are required:

• Publicly available XenAPI simulator is a must
• A working group of at least three people with knowledge in Python, Ansible and XenAPI committed to the cause
• Possibly corporate and financial backing by Citrix, Vates? or some other third party

Having any official Ansible support for XenServer/XCP-ng was (and is) a miracle to this day. A miracle I was blessed with and a huge learning experience for me.

Sorry for the long post. It is not my intention to discourage people but I think everyone should understand why XenServer/XCP-ng does not enjoy better Ansible support. There is much much more to it than just having a willingness to do anything.

Just to confirm. After copying new install.img to my PXE environment, unattended installation went smoothly with my answer file.

@benapetr This looks phenomenal. Will have to give it a try.

This is a nice coincidence. Just the other day one of my younger colleagues boasted about making XCP-ng Center work under Wine... everything just works. It would save a number of folks having to have a Windows VM on stand by just for the XCP-ng Center. Oh boy, how he was disappointed when I showed him everything that does not work ... but with this, there is still hope.

A milestone has been achieved . All of my modules have been merged upstream. I've updated the first post with new info.

That will most probably be all for Ansible 2.8. I'm keeping some improvements and possibly more modules for Ansible 2.9. Currently, I'm thinking about what other modules could be useful so I could implement them. Any suggestion or wish would be much appreciated.

@nuentes Oh no, no. Your system is not destroyed beyond repair. It can be repaired. It's just that it is almost impossible or too much of a hustle for anyone to try to help you over forum. Someone has to sit in front of your machine to do it.

My only guess is that ChatGPT instructed you to make changes based on a CentOS system but XCP-ng and Xen virtualization in general is much different than regular CentOS. It has two stage boot process. First the Xen kernel boots and then a special virtual machine called Dom0 is booted. What you are accessing and reconfiguring is in fact this VM, not the underlying "system". So it's like a two layer system and some configuration must be done on Xen layer, some on Dom0 layer. I'm unfortunately unfamiliar with exact specifics on kernel and initrd image generation for this case so I can't spot where thing have gone wrong.

In short terms. Instead of going back and forth and trying a lot of different things, it's more time saving and simpler to reinstall the system and restore metadata if you already have a backup.

Has anyone been able to install Ubuntu 24.04 in VM from current official ISO? It seems that official ISOs (i.e. installer) still use unpatched kernel 6.8.0-22. Are there any newer ISO builds that I'm not aware of?

EDIT:
Sorry. False alarm. I screwed up my PXE settings. There was some leftover kernel and initrd images from beta versions of ISO. Kernel and initrd from latest ISOs work properly.

@acebmxer Did you do:

cloud-init clean --logs --seed

before converting the VM to template?

Also, network configuration is not part of the cloud-config (aka user data). In XO, there is a separate field called "Network config" where it should be specified. See examples at the end of the guide I pasted earlier. network: key should also be removed (commented in the examples).

@delacosta456 This is a limitation of Debian's "/etc/network/interfaces" network configuration mechanism. It quite old and static - in other words it just applies network configuration on manual networking service restart. There is no hot plug handling.

For something more advanced, you have to use netplan (like Ubuntu) and/or NetworkManager (some other distros)... or possibly systemd-networkd.

@nikade You can even see that Dom0 VM has 16 vCPUs and host has 40 CPUs, in my case anyway. So Dom0 sees just some chunk of host resources.

@nikade said in Unable to MIgrate VDI when host is low on free memory:

Could you please explain the difference between the term dom0 and host?

This is what I mean:

Dom0 is not "the host". It contains a management layer for the host but in reality it is just another VM, highly specialized one but stil just a VM. It does not see host's RAM as it's own.

@nikade This is not related to Dom0 RAM. It's related to the host RAM.

@hitechhillbilly I'd say this is normal if you are low on RAM and you are doing a live VDI migration. XCP-ng requires some amount of free RAM on the host to be able to live migrate the VDI. The larger the VDI, the more RAM is needed but exact sizing is unknown to me. I've encountered this error numerous times so I consider it common.

The way around this is to shutdown the VM and then migrate the VDI. RAM requirements in that case are much much lower.

@benapetr This looks phenomenal. Will have to give it a try.

This is a nice coincidence. Just the other day one of my younger colleagues boasted about making XCP-ng Center work under Wine... everything just works. It would save a number of folks having to have a Windows VM on stand by just for the XCP-ng Center. Oh boy, how he was disappointed when I showed him everything that does not work ... but with this, there is still hope.

@denis.grilli I understand... but my experience is that even with the default scanning interval the logs become the problem when you get in the range of tens of SRs, thousands of disks. MajorP93's infra is quite small so I believe there is something additional that is spamming the logs... or there is some additional trigger for SR scan.

Update: maybe the default value changed in recent versions?

@Pilow agreed. This shouldn't be the norm. auto-scan-interval=120 is not going to be good for everyone. The majority of people probably don't have any problem with the default value, even in larger deployments.

On the other hand, the real cause of the issue is still elusive.

@MajorP93 Amount of logging is directly proportional to the number of hosts, VMs, SRs and clients (Xen Orchestra, XCP-ng Center...). If you have a lot of those, it's rather normal to have huge logs.

Now, 5 hosts and 2 SRs does not seem to be much so I wouldn't expect you to have problems with huge logs. There could be something going on there. Try restarting your hosts to clear any stuck processes and internal tasks that could potentially spam the logs.

We started having problems with /var/log size when we got in a range of 15+ hosts, 10+ SRs and 1000+ VMs per pool. Unfortunately, log partition cannot be expanded as it is at the end of the disk, followed only by the swap. The workaround we did is to patch the installer to create a large 8GB log partition instead of standard 4GB. Of course, we had to reinstall all of our hosts.

@acebmxer rc in first column means "residual configuration". This means that the package is removed but there are some leftover configuration files so that, for example, when you reinstall the package at later time, the package will use preserved configuration. To remove residual configuration and package completely, use:

sudo apt purge xen-guest-agent