Hello all

I have a question but dot know enough about Xen hypervisor to answer it.
So it simple why cant XCP-ng mask the type of CPU that the vms running on.
Take for example the KVM on proxmox you can set host pass-through to send all CPU functions to the vm or mask it to an intel Xeon scalable or AMD Epyc.
I see that host pass-through is what XCP-ng does but was wondering why.

Doesnt masking the cpu make the vm more portable as the profile can be set to for example QEMU-xen or something making it possible to say migrate a vm live from AMD to intel n different pools or a heterogeneous cluster.

And one last thing if it is possible is there no way to emulate other architecture supported by qemu such as arm64 or does xen hypervisor still need more features built out on arm before that i possible. Asking because my use case is i cant afford a raspberry pi but have alot of compute on x86 why not emulate arm 64 on the hypervisor rather than in a vm

Just asking would appreciate a response. thanks

@ddelnano said in Vates Supporting OpenTofu (Terraform alternative):

ojects needed to implement a terraform provider (terraform-plugin sdk and the terraform-plugin-framework) have not been relicensed. Unless that occurs, which I think is extremely unlikely, there will be no impact for the Xen Orchestra terraform

Hello @ddelnano

Thanks for chiming in and i apologize for the late reply there's been a few health issues so i haven't been on the forum much same with work.

But thanks for the input

@olivierlambert So experience helped drove that decision home. Interesting there's always more to learn. Ive still got a long way to go.

@olivierlambert This is seriously impressive. and i like how you guys are sticking to the K.I.S.S principle for your infrastructure. What made you settle to a simplified structure. If i may ask ?

Thank you for also sharing this not many organizations like to say what they are running

Hello @olivierlambert thanks for the response

Right now the future for automation on XCP-ng and Xen Orchestra looks bright.
And im looking forward to all the new Features like XOSTOR RunX and XOlite

Hello eveyone

For those not clued in Hashicorp changed how some of there software was being licensed moving form the mozilla public license to business source license.

As a result and as the opensource community does as it doese. The terraform project was forked to OpenTF now Opentofu. a community driven project aming to give users the same functionality as terraform but with out the burden of licensing for home use or business.

Bringing me to this post. I noticed Vates is listed as one of the 147 companies supporting the project.

1. Thanks all the team at Vates for supporting opensource projects like this
   I can say from a homelab perspective ive automated my vm deployments with terraform cloud-init and ansible its become importent part of how i spin up vms and systems for testing and deployment

2. A question what does this mean for terraform support going forward

Once again Thanks everyone

New update

I got a asus n3150i-c motherboard and found a spare ssd

Im reusing a node for parts and am installing truenas scale as a shared storage target for NFS

Its only 100gb of SSD storage but before i redo my workloads im waiting on debian 12 to be released

so im down a compute node but am up on shared storage with dedicated node

Ive still got 4GB of ram to spare on Xen- 2 and 3 so abit more room for 1 CPU/RAM vms to deploy

I still think that this a the perfect environment for RUNx containers just the efficiency especially with memory will help alot

@brodiecyber ok

new update

Redoing my cloud-init templates and preparing for the next version of Debian in June release 12.
Am using terraform to provision virtual machines and cloud-init and ansible to install software

I'm also using the boot disk as VM storage i don't recommend it as its a 120GB disk and i had to redo my templates as the VM they provision are to big for the little storage.

but Im running

• HA pihole with a keepalived

• WIreguard

• Terraform

• Dashboards. RSS, Archivebox

Will be adding

• dedicated XO-ce VM

• Unifi Controller

Hello

I was finally been able to get cloud-init working. But i have a question that i can seem to find and answer to

Must the cloud config drive be permanently attached to the VM to preserve Network configurations? As my custom template applies the network config but when i remove the drive it defaults back to DHCP

Ive removed removed the network configurations in the /etc/network/interfaces file except for the eth0 hotplug and well as details in the hosts file

This is my cloud config

#Cloud-config
users:
   - default

disable_root: true

#Set hostname
preserve_hostname: false
hostname: debian-localhost
manage_resolv_conf: true
manage_etc_hosts: true
apt_preserve_sources_list: true

cloud_init_modules:
 - migrator
 - seed_random
 - bootcmd
 - write-files
 - growpart
 - resizefs
 - disk_setup
 - mounts
 - set_hostname
 - update_hostname
 - update_etc_hosts
 - ca-certs
 - rsyslog
 - users-groups
 - ssh

cloud_config_modules:
 - emit_upstart
 - ssh-import-id
 - locale
 - set-passwords
 - grub-dpkg
 - apt-pipelining
 - apt-configure
 - ntp
 - timezone
 - disable-ec2-metadata
 - runcmd
 - byobu

cloud_final_modules:
 - package-update-upgrade-install
 - fan
 - puppet
 - chef
 - salt-minion
 - mcollective
 - rightscale_userdata
 - scripts-vendor
 - scripts-per-once
 - scripts-per-boot
 - scripts-per-instance
 - scripts-user
 - ssh-authkey-fingerprints
 - keys-to-console
 - phone-home
 - final-message
 - power-state-change

#Install packages
package_update: true
package_upgrade: true
packages:
 - curl
 - sudo
 - unattended-upgrades
 - open-iscsi
 - nfs-common
 - cifs-utils
 - htop
 - net-tools
 - nftables
 - fail2ban
 - unzip
 - rsyslog

#Set date of server creation
bootcmd:
 - date > /etc/birth_certificate

datasource_list: [ NoCloud, None ]
datasource:
    NoCloud:
        fs_label: cidata

system_info:
   distro: debian
   default_user:
     name: serveradmin
     lock_passwd: True
     gecos: serveradmin
     groups: [adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video]
     sudo: ["ALL=(ALL) NOPASSWD:ALL"]
     shell: /bin/bash
     ssh_authorized_keys:
      - ssh-rsa xxxxxxxx
   paths:
      cloud_dir: /var/lib/cloud/
      templates_dir: /etc/cloud/templates/
      upstart_dir: /etc/init/
   package_mirrors:
     - arches: [default]
       failsafe:
         primary: http://deb.debian.org/debian
         security: http://security.debian.org/
   ssh_svcname: ssh

this is my 99-fake_cloud.cfg

# configure cloud-init for NoCloud
datasource_list: [ NoCloud, None ]
datasource:
    NoCloud:
        fs_label: cidata

Im using Debain 11.7

Any ideas.

thanks

@brodiecyber

Update Setting up cloud-init templates to provision VMs with Terraform and Ansible for application and patch management.

Maybe ill even setup a XO-ce dedicated to this cluster

@olivierlambert

Roger Roger

@olivierlambert

Conversion in Xen orchestra works with the clone of the VM and the guest iso installed

@olivierlambert Morning i will clone the same VM and try to conversion with an iso installed.

Will update this post in the next few hours

Hello

Ive created a VM that Im converting to a template in Xen Orchestra (xo-server 5.113.0) but i get the following error.

The storage of the vm disk is an nfs share from TrueNAS scale mounted to a 3 node XCP-ng 8.2 cluster

I will note that i can convert to template in XCP-ng Center with no error.

My logs for the error is as follows

vm.convertToTemplate
{
  "id": "e6b3db34-f90f-5a9d-16cf-aeaeaf27c55c"
}
{
  "code": "VBD_IS_EMPTY",
  "params": [
    "OpaqueRef:713ee863-59c8-464e-b9d3-2a5371c76c70"
  ],
  "task": {
    "uuid": "ce2df32b-d7d6-ff50-f484-78e51d81fde7",
    "name_label": "Async.VBD.eject",
    "name_description": "",
    "allowed_operations": [],
    "current_operations": {},
    "created": "20230502T09:29:59Z",
    "finished": "20230502T09:29:59Z",
    "status": "failure",
    "resident_on": "OpaqueRef:b2fad3ee-05d6-474b-a3ec-47534ffb3627",
    "progress": 1,
    "type": "<none/>",
    "result": "",
    "error_info": [
      "VBD_IS_EMPTY",
      "OpaqueRef:713ee863-59c8-464e-b9d3-2a5371c76c70"
    ],
    "other_config": {},
    "subtask_of": "OpaqueRef:NULL",
    "subtasks": [],
    "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vbd_helpers.ml)(line 308))((process xapi)(filename ocaml/xapi/xapi_vbd_helpers.ml)(line 317))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 5190))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 199))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 203))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/xapi/rbac.ml)(line 233))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 104)))"
  },
  "message": "VBD_IS_EMPTY(OpaqueRef:713ee863-59c8-464e-b9d3-2a5371c76c70)",
  "name": "XapiError",
  "stack": "XapiError: VBD_IS_EMPTY(OpaqueRef:713ee863-59c8-464e-b9d3-2a5371c76c70)
    at Function.wrap (/home/serveradmin/xen-orchestra/packages/xen-api/src/_XapiError.js:16:12)
    at _default (/home/serveradmin/xen-orchestra/packages/xen-api/src/_getTaskResult.js:11:29)
    at Xapi._addRecordToCache (/home/serveradmin/xen-orchestra/packages/xen-api/src/index.js:998:37)
    at forEach (/home/serveradmin/xen-orchestra/packages/xen-api/src/index.js:1032:14)
    at Array.forEach (<anonymous>)
    at Xapi._processEvents (/home/serveradmin/xen-orchestra/packages/xen-api/src/index.js:1022:12)
    at Xapi._watchEvents (/home/serveradmin/xen-orchestra/packages/xen-api/src/index.js:1195:14)"
}

Update the cluster is doing good i just need to get some SSDs for XOSTOR.

I have a 1cpu 1gb ram 25gb storage VM running over gigabit networking for ha storage. i don't recommend it its just for testing because disk io and bandwidth is limited.

VM runs and live migration takes about 17 Mississippi

@brodiecyber After 2 hours of waiting its fianlly updates and cluster configured.

I will note out of 8GB of RAM. Dom0 is using 1.9GB leaving me with 6.1GB of RAM

@fred974

also see if this script is available on the last host that has the controller which we can assume is the host that failed the first time. Maybe it has some data on why the controller isn't initializing

@fred974

Maybe also post in the XOSTOR thread
A controller failure should be on the radar for possible failure scenarios.
https://xcp-ng.org/forum/topic/5361/xostor-hyperconvergence-preview

@fred974

ok so thats our problem the lunstor controller is not running on any node so XOSTOR has no way to initialize. Im going to do some reading and see what comes up