The past year 2022 was again an exciting year with numerous innovations in XCP-ng and Xen Orchestra as well as good and helpful discussions in the forum. I am excited about what the new year brings and wish everyone a good start for 2023.
Best posts made by gskger
-
A wonderful new year for everybody
-
RE: Can I just say thanks?
I second that! While not a commercial user, I really like the community and the active participation of the Vates team helping novice homelab user with patience and commercial user with in-depth knowledge alike. Keep rocking!
-
RE: Backup reports on Microsoft Teams
You could at least send the backup reports (requires
backup-reports
andtransport-email
plugin on XOA) to a Microsoft Teams channel of your choice (Channel - More options - Get email adress). -
RE: Updates announcements and testing
@gduperrey Updated my two host playlab without a problem. Installed and/or update guest tools (now reporting
7.30.0-11
) on some mainstream Linux distros worked as well as the usual VM operations in the pool. Looks good -
RE: Updates announcements and testing
@stormi Did not even know the problem existed . Anyway, added a new (second) DNS server (9.9.9.9) to the DNS server list via
xsconsole
and rebooted the host (XCP-ng 8.2.0 fully patched).Before update: DNS 9.9.9.9 did not persist, only the previous settings are shown
After update: DNS 9.9.9.9 did persist the reboot and is listed together with the previous settingsDeleting DNS 9.9.9.9 worked as well, so the
xsconsole
update worked for me. -
RE: Updates announcements and testing
@stormi Updated my two host playlab (8.2.0 fully patched, the third host currently serves as a Covid-19 homeoffice workstation) with no error. Rebooted and ran the usual tests (create, live migrate, copy and delete a linux and a windows 10 VM as well as create / revert snapshot (with/without ram) ). Fooled myself with a
VM_LACKS_FEATURE
error on the windows 10 VM until I realized that I forgot to install the Guest tools - I need more sleep. Will try a restore after tonights backup.Edit: restore from backup worked as well
-
A great and happy new year
A great and happy new year 2022 to everybody! Another year has passed and the XCP-ng community continues to rock! Stay optimistic and healthy (never hurts ).
-
RE: Updates announcements and testing
@stormi My two host cluster (HP ProDesk 600 G6) updated without an issue. Let's see how the cluster is performing during the coming days.
-
RE: Updates announcements and testing
Updated my playlab and nothing to report. Looks good.
Latest posts made by gskger
-
RE: VM’s Slow booting
@olivierlambert Just updated my post with the BIOS vs. UEFI Time to login. Both hypervisors are equally fast with EUFI, although Ubuntu 22.04 on proxmox is now slightly slower. But I guess that is not realy relevant.
-
RE: VM’s Slow booting
@olivierlambert Out of curiosity, I carried out a few tests this weekend. My tests are not really scientific and must be taken with a grain of salt. I started with the bare metal installs, followed by the VM installs on the hypervisors. The current server ISOs have been used for OS or hypervisor installs. All OS or hypervisor were updated, but otherwise no tweaking was done (e.g. remove snap from Ubuntu).
The tests were carried out manually by starting the (bare metal/virtualized) OS and taking the time until the login prompt appeared. Where necessary, the grub menu was confirmed manually as quickly as possible. Up to three runs were averaged. The host is a HP ProDesk 400 G6 with a i5-10500T CPU, 32GB RAM and a KIOXIA 512GB M.2 NVMe SSD (KXG70ZNV512G). VMs had 2 CPU, 4 GB RAM and 32 GB storage.
Host OS Time to login [BIOS/EUFI in s] bare metal Ubuntu 22.04.4 -/39 Debian 12.5 -/20 XCP-ng 8.2.1 Ubuntu 22.04.4 28/12 Debian 12.5 18/8 Proxmox 8.1.4 Ubuntu 22.04.4 12/15 Debian 12.5 10/10 Even if the differences are measurable, they don't have much significance for me in normal everyday operation. The result is still interesting though.
Edit: Added Time to login for EUFI boot on the hypervisors.
-
RE: First SMAPIv3 driver is available in preview
@olivierlambert Easy to install and setup on a dedicated host. Did some basic testing with VM creation, snapshots, (re-) import-/exporting, copying, removing and all worked.
The blog post on the SMAPIv3 preview states that it is not yet possible to use this SR type for live storage motion. But it seems that no storage migration is possible at this point (neither live, warm nor cold migration from or to the SMAPIv3 volume). Copying a VM from the SMAPIv3 to a local SMAPIv1 SR works and vice versa.
Looking forward to more capabilities of the SMAPIv3 implementation. Keep up the great work !
Eidt: typos and some clarifications
-
RE: Settings -> Remote -> (NFS|SMB) on a Sinology NAS
@olivierlambert I think that was probably related to my question if he tried to
connect the same NFS share on the Synology as storage and backup target
-
RE: Settings -> Remote -> (NFS|SMB) on a Sinology NAS
@aqua-calc said in Settings -> Remote -> (NFS|SMB) on a Sinology NAS:
same NFS is mounted
It is probably dumb to ask: you are not trying to connect the same NFS share on the Synology as storage and backup target?
Edit: did not see your post
-
RE: Settings -> Remote -> (NFS|SMB) on a Sinology NAS
@aqua-calc What error message do you get when trying to connect the remote to the Synology NFS share? Like others, I am also using a Synology (RS818plus) as a NFS storage and backup target without any issues.
-
RE: Settings -> Remote -> (NFS|SMB) on a Sinology NAS
@aqua-calc Did you check the NFS authorization in the Synology NFS share folders properties (allowed networks)? But that is just guessing and more information or the error message is needed.
-
RE: NBD error SSL
@andersonvaz said in NBD error SSL:
@gskger This explanation you gave about the Truenas certificate is confusing because Truenas does not have NBD
True, since NBD is the transfer method between the XCP-ng hosts and Xen Orchestra. Sorry for the confusion.
-
RE: NBD error SSL
@andersonvaz I wouldn't call it "using NBD" yet because I'm experimenting with it in my playlab. However, the SSL_CTX_use_certificate:ee key too small error message suggest a TLS cipher problem and since the Xen Orchestra 5.76 blog post states that XO is using TLS by default, so the transfer is secure it might be related. According to that (older) post, you can disable TLS with "insecure NBD" for ruling this out.
But you are right, perhaps others who have more relevant experience with NBD can chime in to help.