I agree. Ideally we should also contribute such changes to the xe-guest-agent upstream repository.

Welcome @BenjiReis !

@siodor thanks for the hint, I added it to https://github.com/xcp-ng/xcp/issues/152 borzel created this issue in xcp-ng/xcp open Windows Guest Tools: pre-install checker #152

sim, SVM esta habilitado. vou reinstalar pra tentar resolver. EDIT: Agora que eu vi. baixei o netinstall.iso na transferência deve ter havido algo que corrompeu. pode ser isto. vou baixar a versão completa pra poder refazer...

So: The updates have been made available by Citrix on last wednesday We've published update candidates for testers on thursday Updates for XCP-ng 7.6 have been made available to everyone yesterday Updates for XCP-ng 7.5 have been made available to everyone this morning Blog post published: https://xcp-ng.org/blog/2019/03/12/xcp-ng-security-bulletin-vulnerabilities-pv-guests/

@scboley nice. It should work straight as mentioned in 2nd post of this thread.

@jedimarcus Network configuration (IP, subnet, gateway) only works for Windows guests because there is proper support for it in XenServer Guest Tools for Windows. There is no such support (as far as I know) in XenServer Guest Tools for *nix based systems. Unlike tools for Windows, tools for *nix based systems only contain a few xenstore tools and a daemon (xe-daemon) that collects OS metrics. There is no management agent. My idea is to write a proper agent for *nix based systems at some point but it won't be any time soon. Maybe Citrix (or Vates ?) will implement one before I do. For now, you can use custom based network configuration trough xenstore and custom scripts. It's described in Notes section of the module documentation.

Luckily (or not) XenServer is a tiny part of Citrix strategy/revenue/business. So I'm not concerned by this hack.

@schories It should be noted here that the emulated BIOS in XCPNG7.6 seemingly doesn't care about the bootflags. If the first one (per device id) isn't bootable it will fail, even if xvdb is bootable! So if you e.g. have swap on xvda, move it to another device id at the end (and temporarily disable it in fstab or so)

All tests are done with a local NVMe Optane drive, no network anywhere.

Thank You for the update.

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

We got an ext4-ng driver already working. But benchmarks are… not good so far. So now the goal is to investigate to find the bottleneck. Oddly enough, even while using what we thing the same datapath than SMAPIv1 (yes you can do that), it's still slower. In the end, we must really understand exactly how this whole stuff works, so we could improve it ourselves (there is no public master branch for some repo, thanks Citrix…) edit: we are using the datapath coded by Citrix, so they should suffer the same problem than us for GFS2. I don't understand how this could be "production ready", but that's another story.