When you boot in UEFI mode, press "e" to edit the boot command line, you have a line to change the memory for dom0.

I did the manual installation via the XVA. It worked for me.

@akurzawa said in Extrlemy slow backup speec = about few MB/s: @nikade said in Extrlemy slow backup speec = about few MB/s: Maybe you saw the same thing I did - I also had major issues with backups. Then in the summer of 2019 I upgraded our XOA (Yes, we have the paid version) and everything was going 3-4x times faster. Must have been some major improvement in the XOA code. So maybe some official info that if you have XO from source Your backup speeds will be as low as 3-4 MB/s? Or what? Sorry if I was unclear - XOA is built from the same sources so there is no difference in that aspect. All tho, there was a big performance issue regarding backups which was resolved. I am using XO from sources in my "private" infrastructure and I can assure you there are no "limits" on purpose.

I'm not sure Unitrends is supporting XCP-ng. Please refer to your backup vendor. Current backup solutions claming to support XCP-ng: https://xcp-ng.org/docs/backup.html

How about doing your own matrix?

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

@stormi Edit: Thank you! Got it working and looking good. Troubleshooting non related to Netdata. I remember I change my upstream DNS to Quad 9 recently (1 week ago) and I just change it to Cloudflair (1.1.1.1) and it was the problem. Look like Quad 9 (9.9.9.9) does not like the Mirrors for some reason.

P.S.: I gave my latest "trick" another run: Did a full copy of the VM within xo to the other host. While that job ran, I started the delta backup that finished OK. After the copy was done I deleted the copy and saw - as last time - that the host was coalescing. After finishing the sr's advanced tab is empty again and stayed empty.

@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

anyone can request a change in https://github.com/xcp-ng/xenadmin/issues

@stormi dd stands for disk dump and does exactly that: Copy a stream of data. Fio however can be configured for precise workloads and read/write mixes, parallel workloads etc. So the first thing will only give you streamline benchmarks, what almost nobody cares about. The second can simulate realworld (VM/database...) workloads, where (controller) Caches and non magnetic storage (Flash, Optane, MRAM...) makes the real difference. Also use big amount of data, since caches can impact small ones extremely. Don't get me wrong: We need them and they can make huge differences, but as long as your benchmarks fully fit into them, it gives your nonsense/fake results. Also (consumer) SSDs start throttling after some 10 to a very few 100 GB of data written. Their caches fill up and they 'overheat'. You can spend days on benchmarks and how to do what.

Not my area of expertise. Perhaps this will point you in the right direction -- http://kb.eclipseinc.com/kb/can-i-safely-ignore-io-errors-on-dm-devices/

Let's give it another try to give my host its USB controller back and pass-through just the USB devices. In this case we're going for a virtual machine hosting common USB devices for home domotica. The devices we want to pass-through: Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Which apparently is technical speak for a RFXtrx433XL USB 433.92MHz Transceiver Prolific Technology, Inc. PL2303 Serial Port Which apparently is technical speak for a ZiGate USB-TTL Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB I'm using XCP-ng Center 20.04.00 to help me out and XCP-NG 8.1 on the host. Let's start with a good old: [12:56 vmhost ~]# xe pusb-list host-uuid=***** uuid ( RO) : 2ba8de5b-8fe1-0262-f741-35b4ed350ae0 path ( RO): 1-2 vendor-id ( RO): 067b vendor-desc ( RO): Prolific Technology, Inc. product-id ( RO): 2303 product-desc ( RO): PL2303 Serial Port serial ( RO): version ( RO): 1.10 description ( RO): Prolific Technology, Inc._PL2303 Serial Port uuid ( RO) : 08b23122-e01b-9ab2-e72d-185648ae19d7 path ( RO): 1-7 vendor-id ( RO): 0403 vendor-desc ( RO): Future Technology Devices International, Ltd product-id ( RO): 6015 product-desc ( RO): Bridge(I2C/SPI/UART/FIFO) serial ( RO): ******* version ( RO): 2.00 description ( RO): Future Technology Devices International, Ltd_Bridge(I2C/SPI/UART/FIFO)_DO2VQGDG Ok, we have 2 devices already ready to be passthrough. Let's try to make the third one show up! Using the follow commands and some reading I could identify the DENY rules in "/etc/xensource/usb-policy.conf", which prevent my Aeotec Z-Stick from showing. [13:06 vmhost ~]# /opt/xensource/libexec/usb_scan.py -d [13:06 vmhost ~]# cat /var/log/user.log | less I've adjusted my "/etc/xensource/usb-policy.conf" to the following: # When you change this file, run 'xe pusb-scan' to confirm # the file can be parsed correctly. # # Syntax is an ordered list of case insensitive rules where # is line comment # and each rule is (ALLOW | DENY) : ( match )* # and each match is (class|subclass|prot|vid|pid|rel) = hex-number # Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF # # USB Hubs (class 09) are always denied, independently of the rules in this file DENY: vid=17e9 # All DisplayLink USB displays ALLOW:vid=0658 pid=0200 class=02 # Aeotec Z-Stick Gen5 (ZW090) - UZB DENY: class=02 # Communications and CDC-Control ALLOW:vid=056a pid=0315 class=03 # Wacom Intuos tablet ALLOW:vid=056a pid=0314 class=03 # Wacom Intuos tablet ALLOW:vid=056a pid=00fb class=03 # Wacom DTU tablet DENY: class=03 subclass=01 prot=01 # HID Boot keyboards DENY: class=03 subclass=01 prot=02 # HID Boot mice ALLOW:vid=0658 pid=0200 class=0a # Aeotec Z-Stick Gen5 (ZW090) - UZB DENY: class=0a # CDC-Data DENY: class=0b # Smartcard DENY: class=e0 # Wireless controller DENY: class=ef subclass=04 # Miscellaneous network devices ALLOW: # Otherwise allow everything else but also tried: # When you change this file, run 'xe pusb-scan' to confirm # the file can be parsed correctly. # # Syntax is an ordered list of case insensitive rules where # is line comment # and each rule is (ALLOW | DENY) : ( match )* # and each match is (class|subclass|prot|vid|pid|rel) = hex-number # Maximum hex value for class/subclass/prot is FF, and for vid/pid/rel is FFFF # # USB Hubs (class 09) are always denied, independently of the rules in this file DENY: vid=17e9 # All DisplayLink USB displays ALLOW:vid=0658 pid=0200 # Aeotec Z-Stick Gen5 (ZW090) - UZB ALLOW: class=02 # Communications and CDC-Control ALLOW:vid=056a pid=0315 class=03 # Wacom Intuos tablet ALLOW:vid=056a pid=0314 class=03 # Wacom Intuos tablet ALLOW:vid=056a pid=00fb class=03 # Wacom DTU tablet DENY: class=03 subclass=01 prot=01 # HID Boot keyboards DENY: class=03 subclass=01 prot=02 # HID Boot mice ALLOW: class=0a # CDC-Data DENY: class=0b # Smartcard DENY: class=e0 # Wireless controller DENY: class=ef subclass=04 # Miscellaneous network devices ALLOW: # Otherwise allow everything else After some playing around we got: [13:14 vmhost ~]# xe pusb-scan host-uuid=***** [13:15 vmhost ~]# xe pusb-list host-uuid=***** uuid ( RO) : 0f7d6f12-6c4e-4f71-0c81-f7a7503a75f1 path ( RO): 1-8 vendor-id ( RO): 0658 vendor-desc ( RO): Sigma Designs, Inc. product-id ( RO): 0200 product-desc ( RO): Aeotec Z-Stick Gen5 (ZW090) - UZB serial ( RO): version ( RO): 2.00 description ( RO): Sigma Designs, Inc._Aeotec Z-Stick Gen5 (ZW090) - UZB uuid ( RO) : 2ba8de5b-8fe1-0262-f741-35b4ed350ae0 path ( RO): 1-2 vendor-id ( RO): 067b vendor-desc ( RO): Prolific Technology, Inc. product-id ( RO): 2303 product-desc ( RO): PL2303 Serial Port serial ( RO): version ( RO): 1.10 description ( RO): Prolific Technology, Inc._PL2303 Serial Port uuid ( RO) : 08b23122-e01b-9ab2-e72d-185648ae19d7 path ( RO): 1-7 vendor-id ( RO): 0403 vendor-desc ( RO): Future Technology Devices International, Ltd product-id ( RO): 6015 product-desc ( RO): Bridge(I2C/SPI/UART/FIFO) serial ( RO): ***** version ( RO): 2.00 description ( RO): Future Technology Devices International, Ltd_Bridge(I2C/SPI/UART/FIFO)_DO2VQGDG Well we're ready for some pass-through, right? Using XCP-ng Center we can see these 3 devices and "Enable pass-through" for all of these 3 devices. After shutting down the VM, using properties we can attach all 3 USB-devices and start the VM again, but not before running the following command as was recommended: xe vm-param-set uuid=**** platform:device-model=qemu-upstream-compat Let's start and monitor dmesg: [ 742.309309] block tda: sector-size: 512/512 capacity: 20971520 [ 742.727012] device vif6.0 entered promiscuous mode [ 742.961272] device tap6.0 entered promiscuous mode [ 743.068536] usb 1-8: reset full-speed USB device number 4 using xhci_hcd [ 743.217985] cdc_acm 1-8:1.0: ttyACM0: USB ACM device [ 743.376482] usb 1-8: reset full-speed USB device number 4 using xhci_hcd [ 743.525903] cdc_acm 1-8:1.0: ttyACM0: USB ACM device [ 743.571126] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 743.571136] ftdi_sio 1-7:1.0: device disconnected [ 743.700284] usb 1-7: reset full-speed USB device number 3 using xhci_hcd [ 743.851993] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected [ 743.852018] usb 1-7: Detected FT-X [ 743.852171] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0 [ 743.984286] usb 1-8: reset full-speed USB device number 4 using xhci_hcd [ 744.137611] cdc_acm 1-8:1.0: ttyACM0: USB ACM device [ 744.138491] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 744.138500] ftdi_sio 1-7:1.0: device disconnected [ 744.268258] usb 1-7: reset full-speed USB device number 3 using xhci_hcd [ 744.420007] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected [ 744.420029] usb 1-7: Detected FT-X [ 744.420464] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0 [ 744.465529] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1 [ 744.465539] pl2303 1-2:1.0: device disconnected [ 744.592213] usb 1-2: reset full-speed USB device number 2 using xhci_hcd [ 744.741634] pl2303 1-2:1.0: pl2303 converter detected [ 744.742254] usb 1-2: pl2303 converter now attached to ttyUSB1 [ 744.876149] usb 1-8: reset full-speed USB device number 4 using xhci_hcd [ 745.025388] cdc_acm 1-8:1.0: ttyACM0: USB ACM device [ 745.025629] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 745.025636] ftdi_sio 1-7:1.0: device disconnected [ 745.156079] usb 1-7: reset full-speed USB device number 3 using xhci_hcd [ 745.307475] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected [ 745.307495] usb 1-7: Detected FT-X [ 745.307652] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0 [ 745.308046] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1 [ 745.308054] pl2303 1-2:1.0: device disconnected [ 747.307309] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [ 747.307318] ftdi_sio 1-7:1.0: device disconnected [ 747.435543] usb 1-7: reset full-speed USB device number 3 using xhci_hcd [ 747.586967] ftdi_sio 1-7:1.0: FTDI USB Serial Device converter detected [ 747.586987] usb 1-7: Detected FT-X [ 747.587202] usb 1-7: FTDI USB Serial Device converter now attached to ttyUSB0 [ 756.026324] device tap6.0 left promiscuous mode [ 756.744069] vif vif-6-0 vif6.0: Guest Rx ready [ 757.925017] usb 1-2: reset full-speed USB device number 2 using xhci_hcd [ 758.321147] usb 1-2: reset full-speed USB device number 2 using xhci_hcd [ 768.745084] pl2303 1-2:1.0: pl2303 converter detected [ 768.746207] usb 1-2: pl2303 converter now attached to ttyUSB1 [ 769.803089] device vif6.0 left promiscuous mode And xensource.log as txt file while the VM started and got shutdown. Oh and so far everything looked good, right? Everything got attached, the VM booted and the properties of the VM shows that all 3 devices are "Attached". On the VM running ubuntu I get the following: vm@vm:~$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 12M |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M My USB 1.1 device (ZiGate) is present! The other 2 devices are USB2.0 and those are magically missing?! Why? How? What did I do wrong!? What can I try to make this work? Ah well, time to pci-pass-through my USB controller into that device again, although I would have prefered USB-passthrough! I did also apply scottyXCPNG's workaround, but not allow my USB 2.0 devices to be passed into the VM with those applied.

We can write a simple "driver" like we did for Gluster

@Professor-X-Tech I'm back to report that although it working, I am having issue with the USB 3 Nic. Don't have time to troubleshoot it but I will get to it and if I find anything to share I will.

Trying something new... Remove all servers from XO and log out. Host 1 is powered off. On host 2. xe task-list uuid ( RO) : 727ecb6b-6f2e-15eb-601b-110b2478996b name-label ( RO): Async.host.power_on name-description ( RO): status ( RO): pending progress ( RO): 0.000 xe task-cancel uuid=727ecb6b-6f2e-15eb-601b-110b2478996b Task is still there. From XCP-NG Center. Shutdown all VMs and host2 (All powered off). Powered up both servers. Wait 15 minutes to make sure no tasks are pending (xe task-list). Logging output to file via putty of; tail -f /var/log/audit.log Added host2 (master) to XO Settings/Servers. The Async.host.power_on task hasn't come back.