FWIW -- I had a similar problem with VMs going randomly down -- it wasn't windows but various BSD and Linux VM's. Sometimes they would run a few days, other times they would lock up every other day. Logs didn't help because when the VM locked, logs were not written. I even had the xcp-ng installation lock a few times, although it was usually on of the VMs. I started searching for faulty hardware and eventually SMART tested all the drives and mem86 the RAM. Turns out I had some bad RAM modules which I later RMA'd. With new RAM (after after thoroughly testing it), I haven't had any lock ups. I'm not sure this will help you at all.

Thanks you Oliver!

@stormi said in XCP-ng 8.0.0 xsconsole doesn't show Host Performance Information nor VM's CPU and Memory Usage: I wanted to have a look at the commit history for xsconsole but the github repository at https://github.com/xenserver/xsconsole Thank you, @stormi I've opened a bug report at bugs.xenserver.org about it Specifically: https://bugs.xenserver.org/browse/XSO-961 . Now you may want to open a bug report there about the missing information in the console. This could allow to know if it's a bug or a "feature". Good idea. My bug report: https://bugs.xenserver.org/browse/XSO-962

I did contribute on the RBDSR plugin (v1). Creating a LVMoRBD would be easy. The other good point using LVM over RBD is the native fsfreeze when doing snaps and co which is not the case with rbd snaps. VM has to be paused (which issues fsfreeze) before rbd snaps. But LVMoRBD would put all VM on 1 single RBD. Difficult to maintain regarding dev size. Best would be qemu-rbd. I did use it like 10 years ago over native xen and it did work fine (ensures fsfreeze etc). There were a tech preview using libvirt with xenserver. Didn't test if it works on upstream version 8.

@araxy said in security breach MDS processor XEON: @olivierlambert said in security breach MDS processor XEON: hyper-threading Disabling hyper-threading is losing half the power of the server ... If people have access to VM but not root, is it good? Do You have logs for CPU usage? In my VM environment the CPU utilization is not exceeding 25% for all the time. IDK how it looks on Your site but if I would disable HT I think it wouldn't be even noticeably in a matter of performance of VM's.

@borzel Indeed, the command "xe vm-cd-eject --multiple" worked! All VMs now correctly auto boot on reboot/startup!

I am starting Knoppix 8.2 and taht was running, bit i am not shure about the SAS/Raid Controlle. all other parts are found. I will send some Infos next week when i was in my office

@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...)