Alright I finally got it to work.
I think the trick was to put "Ethernet 2" in quotations. I also perfected the YAML spacing and bracketed the two nameserver addresses.
Thanks for the help gentlemen. Final working network config:
#network:
version: 2
ethernets:
"Ethernet 2":
dhcp4: false
addresses:
- 192.168.1.30/24
gateway4: 192.168.1.1
nameservers:
addresses: [192.168.1.5, 8.8.8.8]
@Kptainflintt Hey! XO team dev is doing a fix on it: https://github.com/vatesfr/xen-orchestra/pull/8979
FYI @pdonias
pdonias opened this pull request in vatesfr/xen-orchestra
open
fix(xo-server/resource-sets): only edit limits if `limits` is passed
#8979
@manilx I have proposed to the IaC team of Vates, a MCP Server for Vates VMS. Which can be used by GitHub Copilot or similar, if used when doing IaC etc.
@olivierlambert Hah, indeed it was! CIFS is totally unstable, but I was able to get NFS working with these configs:
mount -o vers=3,soft,mountproto=tcp [IP]:/share /mnt/nfs_share/backup.xva
@d1rtym0nk3y Thanks for the feedback! This is actually something that we had in mind. It will probably have to wait for the next major version of XO, though.
It's because it's a fake, edited to show how we would like to have it
If you need that, please open an issue in XO bugtracker, only after checking there isn't an existing same request
@dreday said in Cannot see virtual Machine consoles...:
@FPIT I would say to further troubleshoot the limited connectivity issues first...
A few things that jump to mind right away
Does the host have a network gateway address set for the management interface?
Are there any firewalls or switch port ACLs blocking traffic?
This one is the least likely culprit
3) Is you host management configured to use DHCP?(based on the blank console, though it would not explain the connectivity issues unless DHCP is not providing all necessary information for the network)
Option number 3 worked for me. I had initially configured my management console (with public IP) to use DHCP and the other port (with local IP) to use static. When I did reset all connections to use DHCP the consoles came up. Thank you thank you thank you! @DreDay and of course thanks @FPIT for raising the issue. #one
@olivierlambert
Thank you again for the answer!
I was not using the right search criteria to find this part myself
Changed the 'config.toml' file after searching my system (not an XOA but XO CE, so it was in another location then mentioned in the documentation)
Restarted and just as expected the GUI was only available on the specified IP
We are focusing first on getting something correctly integrated from XOA, it doesn't mean it will be exclusive to XOA.
It's just we are first focusing on a completely "known" environment (XOA), but I think at some point we'll be able to provide manual setup for people who want to do it from the sources
@julien-f Backup files check found no problems, so I tried to restore again and it works. No changes or updates in XO, no changes on vhd or json files (same dates and sizes). Only think I did was detach and attach backup repository (settings - remotes) which I tried before with no luck.
In theory, static min is bundled in the template and you shouldn't use less than that. If you still want to do it, consider it as "advanced", and do it with xe
@olivierlambert Dont know why the screenshots were not loading, posting that again
With no snapshots and coalesce completed, very very little space used.
[image: 1606962162989-captura-de-pantalla-233.png]
@ruskofd is right. You should be able to use the cloud_network_config attribute to achieve this.
The following code is untested but should launch a vm with a static IP. Please see the xenorchestra_vm resource docs and the cloud-init networking v1 docs for more details.
resource "xenorchestra_vm" "static_ip_vm" {
....
cloud_network_config = <<EOF
network:
version: 1
config:
- type: physical
name: eth0
subnets:
- type: static
address: STATIC_IP/24
gateway: GATEWAY_IP
dns_nameservers:
- 8.8.8.8
EOF
}
Let me know if you have any questions or issues using cloud_network_config,
As for the blog post, the VM would have been assigned an ip address via dhcp (assuming the guest OS had cloud-init installed which was true for the VM template in the blog post).
