@borzel With my PWA manifest merged you can do further development work around it if you wish. However don't add to much extra Java script if you do so, as it can seriously affect performance and security. Also too many abstractions can affect the ability to understand how Xen Orchestra, as well as XCP-ng works and fix any issues, by thus limiting the number of people who can understand the code and its workings in order to fix them. As read any code from libraries and frameworks used in order to understand them and avoid any vulnerabilities in the code. Not to mention that people who wish to use it may not have Java script enabled browsers or have Java script disabled (maybe even blocked). If the software can't work at all without Java script in the browsers currently support available at the moment now, then they will boycott using the software or website.

@gskger https://xcp-ng.org/forum/topic/8202/eol-xcp-ng-center-has-come-to-an-end

@ryzen3 feel free to open a feature request on XO GH repository with many details as you can, so we can create the feature

So far working great!

@olivierlambert Excellent! Thanks!

@olivierlambert said in XCP-ng Center 20.03.00 released: why it's not the opposite (XenCenter should change this) This would be the logical change, which would allow all existing snapshots to work as designed. Making the change in XO would require maintenance on all existing XO-created snapshots.

Just to know the headline and interesting points, not to make a copy here

@Appollonius @borzel They've been saying that it'll be relevant for 20 years, though.

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

@stormi Yes, it's present in both. That's what drew me to the 8.0.1 release - I hopping this was fixed from version 8. I will go ahead and open an issue on github.

@ThierryC01 said in XCP-ng Windows PV Drivers 8.2.2: Why is there no video drivers for Windows, I have a Windows 10 Pro VM and the video lags a bit compared to my Linux Desktop VMs despite having 8GO RAM and 16MO (?16 max???) video memory. Because it's rudimentary GFX and has no acceleration at all. It's not made for what you might expect.

It's Javascript, so there's no really mandatory tools: Any text editor supporting editor config for basic rules formatting is a good start A GitHub account Same recommendation for the dev env than running XO from the sources: NodeJS 8 and yarn That's pretty much it.

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

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

And also: https://github.com/xcp-ng/xenadmin/issues/186 ducarpit created this issue in xcp-ng/xenadmin closed Cannot change VM RAM memory from XCP-ng Center 20.04.00.32 #186

@borzel Does this still work with current versions of the guest tools?

Thank You for the update.

@r1 the way the rook-ceph works that you pass raw disk to the Debian host and then it creates the OSD and cluster, I have few issues with this: Adding and removing k8s nodes is just few commands and very quick and zero downtime for apps, but if I am running rook-ceph, I need to rebuild the cluster every time I do that and thats extremely time consuming and extra over head. The size of each VM that is being backed up daily/weekly is also extremely big and consumes a lot of resources and storage space. Instead if you get a xcp-ng native local cluster that can be used by VM's as local block type SR that would simplify the implementation many times.