@olivierlambert ok I will tell you how it goes wish me luck

@enes-selcuk I didn't get your point. Do you have a problem right now or did you just want to give advice to other people? I thought your were in trouble (because I did pre-release the XCP-ng PV-Tools, I basically know this stuff (a bit))

Before applying the patch, in a new pool (during the CH8 update process to XCP8), when moving any VM to the updated host I received the error below. After installing the patch on the master host and restarting the toolstack on the host master and the source host, we no longer notice error, with the migrate process successfully completing. The error condition was the failed shutdown of the VM in the live migrate process. So I think the patch made available actually solves the problem in question. (for VMs with and without network interfaces) Nov 30 12:54:48 SECH82 xapi: [error|SECH82|946189 ||backtrace] Async.VM.pool_migrate R:29b4b31d74de failed with exception Server_error(INTERNAL_ERROR, [ xenopsd internal error: Device_common.QMP_Error(135, "{\"error\":{\"class\":\"GenericError\",\"desc\":\"Unable to open /dev/fdset/0: No such file or directory\",\"data\":{}},\"id\":\"qmp-000029-135\"}") ]) Nov 30 12:54:48 SECH82 xapi: [error|SECH82|946189 ||backtrace] Raised Server_error(INTERNAL_ERROR, [ xenopsd internal error: Device_common.QMP_Error(135, "{\"error\":{\"class\":\"GenericError\",\"desc\":\"Unable to open /dev/fdset/0: No such file or directory\",\"data\":{}},\"id\":\"qmp-000029-135\"}") ]) Nov 30 12:54:48 SECH82 xapi: [error|SECH82|946189 ||backtrace] 1/1 xapi @ SECH82 Raised at file (Thread 946189 has no backtrace table. Was with_backtraces called?, line 0 Nov 30 12:54:48 SECH82 xapi: [error|SECH82|946189 ||backtrace]

Can you try with XO Hub template of CentOS 8? This will we'll be sure it's not the template

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