@gb.123 those scsi messages can be expected and ignored when a USB enclosure is connected, some USB enclosures do not emulate SCSI Enclosure Services (SES) very well, so the kernel complains when it queries them and gets nonsense back. USB passthrough devices are still visible and enumerated by dom0's kernel. If you remove the drive the messages will go away, but they can be safely ignored.

@r0ssar00 hi, that issue would arise if you ran this script with python3, but it's interpreter is set as /usr/bin/python - How did you call this script, did you manually call it with python3? It should be ran by just running the command on the CLI eg interface-rename

@jubin3 As this is totally unrelated to XOA and XCP-ng, you'll (hopefully) get a better response in the cloud-init community, as it's their project which has (once again) been broken by an OS update. I gave up chasing them some time ago, especially with brand new OS releases.

@rtjdamen Copying my reply to your official support ticket (any reason for duplicating support tickets on the forum as well?):

given XOA is built on standard debian, you can assign multiple IPs to the same interface quite easily by just duplicating another "iface eth1 inet static" line. Also keep in mind XOA does not add extra interfaces under the main /etc/network/interfaces file, but in files under the /etc/network/interfaces.d/ directory. So in your case given it was eth1 you wanted a second IP on, you can add your required second IP in this file like so:

[09:43 12] xoa:~$ cat /etc/network/interfaces.d/eth1
allow-hotplug eth1
iface eth1 inet static
 address 192.168.1.80
 netmask 255.255.255.0

#second IP
iface eth1 inet static
 address 172.16.100.5
 netmask 255.255.255.0

@abelaguilar indeed you do not have to fill out the dns and gateway fields - in fact as you surmised you shouldn't. Where you getting an error or something when leaving them blank? The only mandatory fields are IP and netmask.

@SNSNSN Indeed, these would typically at least be isolated via vlans at least (one vlan for iscsi traffic, one for iscsi). There's no point in having them in two different subnets if they're in the same network and vlan, the traffic isn't isolated at all. You might as well have them in the same subnet if you're doing that, in which case you only need 1 IP on the XCP-ng management NIC.

@SNSNSN Hi, this isn't possible, at least not without a lot of manual workarounds. It's not recommended anyhow, why do you need to assign another subnet to an adapter already in a different subnet? These should typically be isolated either physically via different connections, or via VLANs.

@olivierlambert never done it myself, but this is indeed exactly what the feature "Copy host BIOS strings to VM" was intended for as @Andrew mentioned. Hopefully the BIOS strings this feature copies are enough for the ROK installer to recognize the "authorized" dell hardware

Indeed, to properly edit iptables rules on xcp-ng, you need to add rules to /etc/sysconfig/iptables. I would copy something like the ssh allow line to another line directly below it, and change the port to 161 for example (and change protocol to udp, which I'm pretty sure your card uses, if it's just doing plain snmp). After verifying that fixes it, you can lock the rule down further by allowing this traffic only from the IP of the management card.

Example of added line below ssh line:

-A RH-Firewall-1-INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m conntrack --ctstate NEW -m udp --dport 694 -j ACCEPT
##UPS rule
-A RH-Firewall-1-INPUT -p tcp -m conntrack --ctstate NEW -m udp --dport 161 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 80 -j ACCEPT
etc
etc

Note that anytime you edit this file, you must restart iptables for it to take effect with service iptables restart

Thinking about this further though I don't think this should be necessary, as the ups daemon in dom0 is reaching out to the UPS card, not the other way around, so an explicit open port shouldn't be necessary with the default iptables in dom0 (which allows outbound conns)

@brm Hmm, I actually am not sure if we ever added support for this specifically (specifying an IP from IP pools in a cloud-init configuration). I've never seen IP variables used or referenced so I don't think it's currently possible. @olivierlambert who was it on the team that implemented the IP Pools feature?

@MrXeon So, the actual root issue here I believe, is opnsense installs come with an IP and dhcp server already assigned and enabled on the lan interface (I believe it's 192.168.1.1, but don't quote me). If your existing home network already uses 192.168.1.x/24 and already has a dhcp server, booting an opnsense install with it's virtual lan nic set to your existing home lan, there will be a lot of conflicts. Virtual nic order can be whatever you'd like (you can change and move around assignments in opnsense), but if it's preconfigured lan interface gets set to your preexisting lan network, there will be conflicts

Also note the text at the top of your screenshot: to continue you need to select a boot device. There might be a way in that menu (or partition creation submenu) to mark that created partition as bootable, or maybe you just need to highlight/select the partition under "used devices" before hitting "done"

@encryptblockr yup, welcome to cloud-init hell. Your issue is definitely ubuntu related though, if I had to guess, the installer wants/requires a swap partition. Just create a 1 or 2gb swap partition as well, but put it first in the partition table, so the root partition after it has room to grow. You'll also run into some network issues probably when trying to use your new template, as ubuntu has moved to new netplan crap to manage networking in the OS, and cloud-init has a ton of bugs with it

@furyflash777 I'm assuming you're on Ubuntu? Indeed as Olivier said this is tested on Debian and doesn't cause issues, but it seems on the newer Ubuntu versions with cloud-init, the new Netplan based network manager and how it interacts with cloud-init breaks/gets wiped if no cloud-init drive is found. Yet another cloud-init bug to track down

@jcdick1 I run opnsense on xcp-ng personally as well and use their packaged tools without issue, the only time I've gotten this behavior is when I hot-added interfaces and it changed the order of interfaces. If that's not it, I'm really not sure what would be causing this

One last thing you can try in case it's a weird cash issue is (inside XOA) go to settings > servers, click the green connected button next to your xcp-ng server to disconnect it from xoa - then wait a couple seconds and click it again to reconnect it

@jcdick1 Hi, have you hot-added any new network interfaces to this VM by chance? I've noticed when doing this with *bsd based guests like the *sense projects, the order can get quite messed up, if you've added any new interfaces, changed any MAC addresses, etc, can you please shut the VM down entirely (not just issue a reboot) - once the power state of the VM is completely off, start it again.

Note that if you did hot-add interfaces and hadn't rebooted yet, the interface order will probably change into its "final" order (the ordering seems to be affected when hot adding interfaces, eg when I hot add interfaces into *bsd VMs, sometimes the new interface will show up as xn0 in the VM, so the existing xn0 will get moved to xn3 etc). I've avoided this by just no longer hot adding interfaces and doing it when the VM is off instead

@tekwendell xen carefully manages CPU power management to match VM load and vCPU count, I would not manually try to adjust things with xenpm in the meantime as it's likely you'll make things worse (don't try to outsmart xen power management unless you have a VERY specific use case). Xen is designed for paralleled workloads (more than a single VM), so there's many tunables for VMs that are set with this in mind (like CPU affinity). So by default I'm sure the CPU affinity for your single windows VM is still set somewhere in the "middle", so it's not going to be allowed to schedule the full CPU time versus what dom0 is also using.

I'm not an expert in AMD/Epyc power management, but I believe it's pretty typical that CPU power/clock management boosts based on overall CPU load, and running a benchmark on only a single VM using something like 8 cores on a 64 core processor is not going to demand a lot CPU time, so I'm not surprised to see it's not boosting very far. Spin up 6 more of those VMs and benchmark them all at the same time, I wouldn't be surprised if you see it start boosting higher

475 cpu-z versus 501 bare metal is very good and indicates pretty clearly there's no issue here, you're getting 94% bare metal performance on windows under a large virtualization stack (historically the OS with the most overhead to virtualize). I would be very happy about this

If you really want to dig further, ensure your bios power management is set to "OS-controlled", this will hand more control over turbo and c-states to the xen power manager and is what is recommended on AMD processors, and then you can use some commands listed here to check actual turbo status. But again, note that I won't be surprised if you can't get a 64-core processor to enter its highest turbo states when only stressing 1/10th of its cores: https://support.citrix.com/article/CTX200390/power-settings-in-citrix-hypervisor-cstates-turbo-and-cpu-frequency-scaling

@olivierlambert I vaguely remember @pdonias and I discussing which of these behaviors would be best and we decided on adding it to the smallest matching prefix, I'm not sure why the behavior is the opposite

@jmishal As @tjkreidl says, you can do this quite easily through the management console in your screenshot. But be aware if this is a pool, change the master first, then each slave. This won't affect VM traffic on the network or running VMs.