@dvdhngs install onto (mdadm/ZFS) RAID 10: no to use (mdadm/ZFS) RAID 10 as SR: yes, of course!

@danp said in XCP-ng 7.5.0 final is here: @dblogic said in XCP-ng 7.5.0 final is here: Just tried updating our pool and after updating the master had failed migration of VM (Ubuntu) and then was unable to get VM to start (Missing VDI error). Only solution was to roll master back to 7.4 and everything working again. I ran into a similar situation when I upgraded to 7.5 this week. Did you check to see if there was a non-existent ISO mounted in the CD rom for the VM in question? Thank you. That was my problem. I gave cd empty. Everything works.

Actually, looks like I had already written something about it in the Updates Howto: https://github.com/xcp-ng/xcp/wiki/Updates-Howto#a-special-word-about-xcp-ng-75-76-and-live-migrations

Hello dear RC testers! We are releasing 7.5.0 final today, so here's how to go from 7.5.0RC to 7.5.0. Warning: this is only for people who installed the RC. Detailed procedure will be given in the release announcement for upgrading an XCP-ng 7.4 server Option 1, upgrade using the installation ISO Will work, although may be a little overkill since you already have a nearly-final 7.5.0. Option 2, update yum repository files and update the system # remove the RC-specific repository file if present rm /etc/yum.repos.d/xcp-ng-7.5.repo -f # install the 7.5 official repository file wget https://updates.xcp-ng.org/7/xcp-ng-7.5.repo -O /etc/yum.repos.d/xcp-ng.repo # update. If you had updated your RC regularly, this will install nothing, else you'll get a few packages yum update # if the kernel or xen-* packages got updated, reboot your server # that's it, you've got 7.5.0 final!

@olivierlambert Of course. Right now I just got enough information to start the modification on the script which I start tomorrow. In fact, all that is needed to get usbnics working properly in xapi is simply being able to identify usb locations. THAT'S IT! All NICs if you look in the logs are initially named side then because the rename script runs and after properly identifying it assigns a ethxx name which the api will work with. All this would take is an import command and a few if commands. I got the logic down so now it is just about editing, trial and error. Question regarding: import sys, logging from optparse import OptionParser, OptionGroup from os.path import join as joinpath, normpath, exists as pathexists from subprocess import Popen try: import cStringIO as StringIO except ImportError: import StringIO import xcp.logger as LOG from xcp.pci import PCI from xcp.net.biosdevname import all_devices_all_names from xcp.net.ip import ip_link_set_name from xcp.net.ifrename.logic import rename from xcp.net.ifrename.macpci import MACPCI from xcp.net.ifrename.static import StaticRules from xcp.net.ifrename.dynamic import DynamicRules from xcp.net.ifrename.util import niceformat from xcp.net.mac import MAC for the import command as my google fu was no help for the above xcp.net and xcp.pci what is it specifically referring to? What I have that down we simply need to add and import for usb then modify a few existing calls with the first being if device location = usb format then run the modify version of the script that would have the edited fields to pull the proper usb locations etc. For the vendor and device it would be best and most simple if we refer to the usbvidpid list it can simply call the info from an already large existing database which can also be easily updated and/or modified for an entry. Functionality wise all that is needed is those if commands to make a usb location referable. Then any usb NIC (so long as drivers provided) would be truly plug and play and we could use the existing config to chose a specific ethxx name based on MAC so they survive reboots without further editing anything. Got it is referring to the python libary / libs

The case is solved. Here is an updated entry in our Troubleshooting Guide: Cause a) There can be leftovers from old Citrix XenServer Client Tools. -> https://github.com/xcp-ng/xcp/wiki/Troubleshooting#the-management-agent-installer-was-executed-but-the-pv-drivers-are-not-installed-in-the-device-manager

Then feel free to open an issue here: http://github.com/vatesfr/xen-orchestra/issues/new

@maxcuttins There are two packages. User level blktap driver that you referred blktap and a builtin kernel driver blktap2. Said patch is against mainline kernel as additional driver. You still need to have user land blktap from https://github.com/xapi-project/blktap There are instructions lying around https://xcp-ng.org/forum/topic/122/how-to-build-blktap-from-sources/ to build user land blktap (its without patch).

@sfx please take a look here, there are several discussions there: https://github.com/xcp-ng/xcp/issues/107 olivierlambert created this issue in xcp-ng/xcp open Software RAID install on previous used mdadm disks #107

Alright. Thanks for letting us know.

No luck with passing through a zwave usb dongle. Have tried two different types: Aeon Labs Z-Stick Gen 5 (https://aeotec.com/z-wave-usb-stick) Nortek GoControl HUSBZ-1 (http://www.gocontrol.com/detail.php?productId=5) Tried both adding through XCP-NG Center and following the procedure above. I can see it added to the vm, but nothing shows in the guest (CentOS7 and Ubuntu Server 1604 and 1804). This stick contains both an 02 device type and 0a, both CDC device types it appears.

@olivierlambert Okej, its that part that's tricky Yea maybe so, but it's cool. And makes the uptime better even if it's just a lab. I've been using vmware for a while at my last work. But the licensing is not nice for a homelab. So this is my first time with xcp-ng (xenserver). I'll try updating tomorrow. Thanks.

@KapilBandlish I don't understand. You are using XCP-ng and talking about Citrix support recommending something? As @borzel said, thin pro on block device via GFS2 is NOT support in XCP-ng, because the storage drivers aren't open source.

Hi, so some people have been able to do it https://gridforums.nvidia.com/default/topic/9108/# https://gridforums.nvidia.com/default/topic/8934/#

Thank You for the update.

Update: The same VM crashed again, the others are working fine as of this post. I left it up as a remote desktop session last night and I came back to my office today and it was still up as a RDP session, but not responsive. I checked XCP-NG Center and the same blue screen with a cursor was there. Still trying to find the cause of this.

Thin Pro on block is very very very immature in XenServer. You can't even migrate VDIs on this SR to another one (nor toward it). Frankly, it's still messy, avoid it.

@jedimarcus Network configuration (IP, subnet, gateway) only works for Windows guests because there is proper support for it in XenServer Guest Tools for Windows. There is no such support (as far as I know) in XenServer Guest Tools for *nix based systems. Unlike tools for Windows, tools for *nix based systems only contain a few xenstore tools and a daemon (xe-daemon) that collects OS metrics. There is no management agent. My idea is to write a proper agent for *nix based systems at some point but it won't be any time soon. Maybe Citrix (or Vates ?) will implement one before I do. For now, you can use custom based network configuration trough xenstore and custom scripts. It's described in Notes section of the module documentation.