Posts made by fohdeesha

@pdonias yep I can confirm that works as expected, cloud-init uses the base VM name specified in the top of the create VM page, not the numbered VM names that result after creation. Nevermind!

@olivierlambert thinking further it should probably just be completely removed from the example/default, when creating multiple VMs from our "create "VM" page, numbering of all the VM names directly is already achieved, so having another number variable on top of those numbered VM names inside the cloud init config will just end up with the multiple VMs having hostnames like "test00", "test11", "test22", etc

@bradk that's working as expected, the number of the VM is the % in the hostname variable. If you want the hostname to be set to the name of the VM, without numbering, just use hostname: {name}

I also just noticed you were using the v3 testing version of clonezilla, not stable. I just tested that as well just in case and as expected it works out of the box - Clonezilla at its core is just trimmed down ubuntu or debian, and the xen PV device drivers are built directly into the kernel for both of these, so it's incredibly unlikely they would ever not be present. Screenshot from clonezilla live testing (same ISO you stated in your original post):

@fred974 I think you definitely have your templates or something else mixed up, Clonezilla works great out of the box running as a VM under XCP-ng, using any Ubuntu or Debian VM template. In fact, you should be able to use any linux template when creating a VM. To double check, I just downloaded both clonezilla stable live ISO (debian based) and clonezilla live stable alternative (the ubuntu build), and both boot fine and have working network adapters out of the box, using either debian VM templates or ubuntu VM templates (doesn't matter).

In fact, the issue Olivier is remembering is that clonezilla does not work out of the box when booted under a Windows 10 template, because windows 10 templates present platform:device_id=0002 to the guest OS, and QEMU combined with some linux OS's get confused by this (understandably, the ID is for windows), and it breaks the display. So a customer that was trying to boot clonezilla under windows 10 templated VMs had garbled display output until he used xe to change platform:device_id=0002 to platform:device_id=0001 which is what linux templates use.

The fact that you're reporting your clonezilla actually works fine under windows templates, but not linux templates, tells me some wires are crossed somewhere - it could be the ISO you're using, the templates you're using or choosing from, or your XCP-ng install. Is your XCP-ng fully up to date? if so, have you rebooted it since applying updates? We also had some strange issues with customers applying updates recently but then not rebooting as advised, this left QEMU in a weird state until it was finally rebooted that I suppose could cause this issue. For reference, here is how I'm creating clonezilla templates that work right out of the box (note the template, ISO name, and boot mode: bios):

@vmpr Great work and example!

@Gheppy I'm not sure if xo-cli supports job interactions, @olivierlambert may have to inquire with the xo-cli dev @julien-f . For your niche use case, you could solve it in the meantime by running your XO instance from your house (or wherever this CR destination and DB test server are). Then, you can set the CR job to replicate to two remotes, your main CR destination, and then your test pool you've been manually copying to. Since these are now both local to XOA, it won't use up extra internet bandwidth, XOA will still only be pulling one stream from the production server out on the internet, then once it's inside your network on XO, it duplicates and writes to both local CR destinations

@Torodiesel Are you using the ubuntu or debian hub template? the default user included with the debian template is debian, not ubuntu :)However if you're yusing the ubuntu template, it should indeed be ubuntu. I would start from scratch and copy/paste only my example config above without networking, replacing only the key line with your public key. If that still doesn't work, you can be sure the issue is somewhere on your side (probably the keypair is corrupted, or your ssh client isn't sending the correct privkey)

@Torodiesel the networking config should go in the network config box when deploying the template, not in the same box as the cloud-config data. Also, I see a few things wrong, including your network config having non-existent fields (you have to define a nameserver type field, then list addresses under it). Here is a known-working config. Note that you don't need to create an xcp-ng user, the templates come configured with a sudo user with the name of the OS, so for our debian template, the default sudo user is debian, just provide a key like below and you can log in as him::

#cloud-config
hostname: {name}%
fqdn: {name}%.localdomain.local
ssh_authorized_keys:
  - ssh-rsa XXXXXXXX
packages:
  - tmux

  version: 1
  config:
    - type: physical
      name: eth0
      subnets:
        - type: static
          address: 192.168.1.169/24
          gateway: 192.168.1.1
    - type: nameserver
      address:
        - 8.8.8.8
        - 1.1.1.1
      search:
        - home.lan

And yes, filling a field with a value of {name}% will pass along the name of the VM, whatever you have named it

@vmpr Hi, this is one of cloud-inits many "features" - on debian and debian-like distros, it does not overwrite /etc/network/interfaces - it appends the existing config with a file placed under /etc/network/interfaces.d/ as you noticed - this is cloud-inits design choice. So when Debian's default /etc/network/interfaces file has dhcp configured on eth0, it's going to pull a DHCP address. There's two ways around this. One, you can remove the interface config inside of /etc/network/interfaces - I thought about this briefly when creating the hub templates - then debian would not have its own DHCP address added to your static config. The problem though is users who do not provide their own network config during spin up (which is about 90% of our users) will have a VM spin up with no network config or address at all, which obviously isn't an option.

The second option is using cloud-inits ability to run commands after spin-up, and use it to run sed or similar to remove the dhcp config out of the /etc/network/interfaces file, then restart the networking service. If you google around you'll find some suggestions about this and the syntax to use (I'm not an expert here). https://cloudinit.readthedocs.io/en/latest/topics/modules.html#runcmd

As for it taking a reboot for the static IP to be applied, I never experienced that so I can't say what's going on there. As for the default password, there is no passwords for any users on the templates by default for security reasons. You must use a key, or use the runcmd cloud-init param above to run something like echo 'root:mypass' | chpasswd after the first boot to set a password

@ITJamie Alma Linux 8.5 template is finished and should be added to the hub in the next day or two. I should have Rocky Linux done shortly after that. Note that in CentOS/RHEL related distros, the hostname: {name}% parameter that's filled in under the cloud-init config is not enough to change the hostname for the machine, CentOS (and related) expects a fully qualified domain name. To get the newly spawned VM have the hostname you'd like, supply fqdn parameter as well:

use VM name as hostname:

#cloud-config
hostname: {name}%
fqdn: {name}%.localdomain.local

use custom hostname:

#cloud-config
hostname: testvm
fqdn: testvm.localdomain.local

Hi, I will look into both of these for the hub in the coming weeks.

@Zevgeny there's no special reserved MACs or special validation in XCP-ng, as it just uses linux networking via OpenVswitch underneath, so if your custom MACs adhere to IEEE standards they will work. Of course, make sure you don't collide with the MAC addresses on the physical adapter in the server (plus maybe 3 or 4 sequentially above that) as XCP-ng uses those in dom0

@stevewest15 those instructions will not work as XOA is running on node and does not have a physical "web root" folder like you are thinking of. Also @gskger please be cautious about scheduling xo-server restarts, doing so interrupts and breaks any task xo-server is running at that time, like backups etc. I believe this is one of the main reasons we haven't implemented let's encrypt integration into XOA, it's not as simple as just firing off an xo-server restart everytime LE certs are updated - this would break a lot of important backups for the majority of our customers. We would need to add some type of sensing to see xo-server's current status, and schedule the restart for when there's no longer any tasks running

@dkmuir when cloud-init is installed on a VM, it runs every single boot and searches for a config drive, mounts it, reads it, then unmounts it. If it sees it's the same as a previous config that's already been loaded (which is what will happen on a deployed VM after the firstboot), it'll ignore it and not do anything - it won't re-apply the same old config. So you can safely leave the old config drive there, however you can also safely remove the drive entirely as well - cloud-init will still scan on startup, but it won't find a config drive to even check. You can remove the config drive while the VM is running without issue, it's not even mounted any longer (cloud-init only temporarily mounts it during boot)

You can also remove cloud-init iself indeed after the first boot

@Zevgeny As you suspected, this is caused by the VMs booting with new & fresh MAC addresses they've never seen before, which from their point of view means an entirely new NIC. The "clean" solution here would be to have an option or toggle inside of XOA backup jobs, that allows MAC addresses to be preserved - this way the replicated DR VMs on the backup site still have the same MAC addresses. This could be something you could file as a feature request on our github

However note that pretty much any VM copy/replicate action will trigger xen to generate a new MAC address (for safety, duplicated MACs are usually bad). This means that even if the MAC is preserved to the DR VMs, when your admin copies the DR VMs and boots them, the new copies will have newly generated MACs. I suppose it would be possible to add a "preserve MAC" checkbox for copy operations too, but I'm not sure if XAPI currently exposes such functionality.

@kulmacet Can you recreate this with other VMs, or just this specific oracle linux VM? I would spin up a new debian VM for example and shut this problematic VM off, and see if the issue happens with this VM as well. Outside of that, it's really looking like a hardware issue. Also, double check the ILO and BIOS firmware are at the latest. I can almost guarantee it shipped with ancient versions, and many issues like this have been patched relatively recently.

@alexanderk Heh yes, and a few other Brocade/Quanta/Dell guides

@maxcerny I'm not sure on a debian 11 image, if it's been assigned to another team member it may be done very soon, if not I can probably get one created within the next week.

As for bugs, take your pick. For a "vanilla" install it's not too bad, but a big can of worms gets opened when you add in an avenue to pass network information to the cloud-init instance - it either overriding your cloud-init.cfg and ignoring it, or not overwriting interfaces and just appending to it leaving a stale DHCP address and lease, not overriding resolvers that were set previously during the templating process, stuff like that. Then there's the fun stuff like /etc/cloud/cloud.cfg.d/99-installer.cfg and other files in this directory overriding the nocloud config even when explicitly commented out. Many of these things have been reported to the cloud-init project but it seems everyone has moved to Ignition (which I'd like to do in the future, but it would take a lot of rewriting on the XOA side). This GIST (not mine) sums up some of my feelings pretty well - https://gist.github.com/Informatic/0b6b24374b54d09c77b9d25595cdbd47

@alexanderk Hi, apologies but we were never able to trace this down to anything in the xen kernel itself, it seems to be something specific to the older gen 8 HP and how their BIOS/UEFI firmware handles VT-d / passthrough. If there's newer BIOS firmware available for your machine, you could try that, and double check vt-d, IOMMU etc is enabled in bios.