@borzel In my humble opinion, I would say no because then you are deviating from industry standard naming. The reason for standards is so that everyone will know what you are talking about as long as you follow the standard. Lowercase b always means bit and uppercase B always means Byte. Please do not change this. It is trivial to learn the standard. It is less than trivial when people start making up their own abbreviations for things (though admittedly this one isn't rocket science to figure out).

@blafuente said in XenApp or similar on XCP-ng?: @nikade Great! Hope it meets your expectations and needs. If you need any help we'll be more than happy to help you out I havent gotten my free serial yet so I havent been able to test it out, but it looks pretty neat in the videos.

Xen is doing all the CPU and memory sharing, so Xen is a type 1. Network and storage are delegate to the privileged domain (dom0).

Thanks for the info. That really helps

@stormi Thanks for the links and I will start to dig in to them more to learn how it can be done. In a quick review of the links, this may be what I need since I do not think that I will actually need to re-compile XCP-ng, but just add for the setup of some additional installation steps via rpms and yum as well as some configurations at this point. This is really an experimental endeavor for the moment while it also allows me to learn more about the whole installation and setup of XCP-ng along the way.

Hi All, In some of the latest read that I have been doing, it seems that the XenServer folks were also investigating the ideas of so called "Sub Domains" or "Driver Domains" via Mini-OS and MirageOS as minimal OS's to deaggregate Dom0 to take drivers out and make them independently sufficient such that if something happens to one of them then the rest of the system remains unaffected. This links into the ideas of Unikernels but I think that a lot of this is still in the R&D phase although some great ideas, to be sure. I could see a whole set of Sub-Domains to handle just about all of the functionality that Dom0 currently manages in perhaps a future evolution. Cheers

@MajorTom Yea, I see what you mean. Just tried it yesterday with similar results.

Thanks again. I will dig into XAPI and the XO CLI to get a better feel for things. Best

From Vbox to XCP-ng: export in OVA then import with XO.

Thanks. I sure will. Hopefully the project design will go well.

@olivierlambert I did a bit of light digging. General consensus is that Dell's servers are not ready for this kind of stuff, but then again I've seen crowds get things wrong before: https://www.reddit.com/r/homelab/comments/6mafcg/can_i_install_a_gpu_in_a_dell_power_edge_r810/ This is the method described for KVM: http://mathiashueber.com/fighting-error-43-how-to-use-nvidia-gpu-in-a-virtual-machine/ Additional KVM docs (plus a small description of the vendor ID problem): https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#"Error_43:_Driver_failed_to_load"_on_Nvidia_GPUs_passed_to_Windows_VMs An updated methodology for Ryzen on-chip GPU: http://mathiashueber.com/ryzen-based-virtual-machine-passthrough-setup-ubuntu-18-04/ This is the method described for VMWare: http://codefromabove.com/2019/02/the-hyperconverged-homelab-windows-vm-gaming/ Hyper-V documentation is a bit more sparse, but this hints that Microsoft may have simply worked around the issue (ala vendor license agreements), at least when using RemoteFX: http://techgenix.com/enabling-physical-gpus-hyper/ (Optional) Get CUDA working for cheap-o cards: https://medium.com/@samnco/using-the-nvidia-gt-1030-for-cuda-workloads-on-ubuntu-16-04-4eee72d56791 So it looks like the common factors are: The GPU device must be isolated on the host with the vfio kernel driver. To ensure this, the vfio driver must load first, prior to any vendor or open source driver. GPU must be connected to the guest VM via PCI pass-through. No surprise. The CPU must not be identified as a virtual one, it must have some other identity when probed. This appears to be the key to preventing the dread NVidia Error 43; it suggests the driver is just examining the CPU assigned to it, although some documentation mentions a "vendor" setting. The work-around is to make it into a string it doesn't match against, and it just works. Even a setting of "unknown" is shown to work. I don't know if there is a way to specify in a XCP guest "please don't identify yourself as virtual". For cards that are CUDA capable but "unsupported" by NVidia, you install the software in a difference sequence (CUDA first, then driver). Disclaimer: I'm just compiling a list to get an idea about what to do; I haven't done the actual install, nor do I have the hardware. Hopefully this helps.

From my admin-view: I wonder about the benefits of that (and if work shouldn't be put into other usefull things). If no monitoring is connected / some autonotify via E-Mail or such, to me it's rather useless. I don't really care since when a device is broken, when it already happened $somewhen ago - I need ASAP notify of it, when it happens. Like some health monitoring for XCP, however realized (via XenCenter, central Mail service, SNMP, Nagios/Montoring plugins...)

Got that, thanks. What about the Debian server VM which didn't start? It's enabled in XOA.

Since ZoL 0.8 is here, supporting O_DIRECT, everything might just work out of the box. We'll try it and report

@maxcuttins oops

How about doing your own matrix?

Don't be sorry: there is some tool designed to do something, and other for other things. You don't expect that your everyday car will fly. It would be the same thing if XO was working in the browser only. We made that choice (to have a server part) because we knew we'll push for features requiring to run 24/7.

You can boot a VM on PXE by selecting the right boot order (enabling "Network" in boot order in XO for example) Then you need to setup a PXE server, you can fine various guides by googling "PXE server setup", eg this one)

@Ced76 Ced thanks for the script.