@stormi said in XCP-ng 8.0.0 Beta now available!:

You could test with Citrix Hypervisor and then report it at https://bugs.xenserver.org
Maybe they'll want to investigate even if the hardware is not officially supported. If someone can reproduce the issue on supported hardware, that would make things easier.

Though I doubt it was woth the effort, as the support over there is well known (especially for not supported configurations etc.) I did it - for the reason of trying to improve stuff (and giving back to OSS community):
https://bugs.xenserver.org/projects/XSO/issues/XSO-955

@stormi dd stands for disk dump and does exactly that: Copy a stream of data.
Fio however can be configured for precise workloads and read/write mixes, parallel workloads etc.

So the first thing will only give you streamline benchmarks, what almost nobody cares about.
The second can simulate realworld (VM/database...) workloads, where (controller) Caches and non magnetic storage (Flash, Optane, MRAM...) makes the real difference.
Also use big amount of data, since caches can impact small ones extremely. Don't get me wrong: We need them and they can make huge differences, but as long as your benchmarks fully fit into them, it gives your nonsense/fake results. Also (consumer) SSDs start throttling after some 10 to a very few 100 GB of data written. Their caches fill up and they 'overheat'.

You can spend days on benchmarks and how to do what.

https://xen-orchestra.com/blog/xen-orchestra-5-36/

The part about ZFS:

As there are many possibilities during the creation of a ZFS storage repository, you still need to use the command line (eg. zpool create zdata /dev/sdb) to create your SR.

Check this documentation for more information about ZFS SR creation.

Once the SR is created, you will have the option to select it during the SR creation directly in Xen Orchestra.

Since it's confusing and technically wrong, it should rather be something like:

As there are many possibilities during the creation of a ZFS storage repository, you still need to use the command line (eg. zpool create zdata /dev/sdb) to create a ZFS pool before creating the corresponding SR.

Check this documentation for more information about ZFS SR creation.

Once the ZFS pool is created and mounted, you will have the option to select the mountpoint during the SR creation directly in Xen Orchestra.

...and this forum is missing a "quote" button, as formating text in codeboxes doesn't work (and tags don't survive a linebreak, you have to mark it every line again).

Regards,
Christof

XCP-ng already ate a bunch of time, and I'm sure it'll continue for testing etc
I'm Sysadmin with very limited coding ability - I'm definately out for that.

I guess it would need someone being good at C#.NET. Also XAPI would probably need to know about it (what may already be, as you're implementing it into XOA)...

First rule of all benchmarks: The longer and more often they run, the more precise they are.
If we talk about 1G as base, why should I switch with 10 or 100 to M? That doesn't make any sense at all.

@maxcuttins did you really measure 10 and 100 MB after I said 1 G is not enough for accurate results?

Usually you set blocksize to something usefull, like 1M and set count to e.g. 10000.
Of course you can change blocksize to test a bit, but that's usually between like 64k and maybe 4M.

How about doing your own matrix?

You should consider, that efficiency of vCPUs goes down by each one you add. I don't have the link to that Citrix document handy, so you need to google that.
If you really need that many cores, you should consider a physical machine, which should make a serious bump in performance.
AFAIR it was the overhead of the Xen scheduler, which needs to balance the needs of your VM. The more vCPUs one VM has, the bigger the overhead. I'm sure it didn't change in more recent versions.

Exactly this. Not giving - especially paying customers - any feedback/info is just the worst way to do your business.

Just came in:

https://twitter.com/ismonkeyuser/status/1113783781238898688

;D

@Carlos-Raasch said in Creating local ISO SR failed -> Feature request:

One option, considering a single server, you would have a local SR. Create there a "ISO folder" and mount it, like ESXi do, using the XO interface to manage the files.

It's what the whole topic is about.

I'm just installing it on a smaller number of independent servers. I can't use an ISO share for that.
But I'm not limiting that to me: Other people have to do the same stepts manualls.
It's one change, that - in the long run - can save thousands of manual steps in the community.
The feature is pretty nice for smaller environments, especially as new servers often don't have optical drives anymore and using iLO for that requires an advanced license, which is not super cheap (relative to the price of smaller servers).

Edit: And yes, of course the 2nd thing would be an "upload" button, to use XOA to drop the ISOs there. (Or did I just miss that?)

@Biggen said in Creating local ISO SR failed -> Feature request:

How hard is it to SSH in and manually create the folder? It's 10 seconds worth of work tops. And you probably will never have to ever touch it again.

It's about optimizing things and taking away extra/manual steps that disturbs workflow with rather low effort to implement
.
I'm not feeding your negative vibes on that, so discussion is over for me. Oliver said they don't want to do things beside what XAPI can do and thereby it's done.

As XOA needs the root password and IP of the XS/XCP-ng host, it has everything, it needs.
It could be SSH'ed to create the folder (could be a manual switch without check - if it fails, it fails).

But I accept, if you don't want to go ways around XAPI.

The screenshot is an example. If the option to create a "local" SR inside a mounted filesystem is given, it makes totally sense to check if the directory exisits and - in case it doesn't - to create one. There's IMHO no need to force someone to create it by hand before.

2nd step would of course be an option, to upload the ISOs via webconsole.

Edit: Fixed the startpost.

I followed: https://github.com/xcp-ng/xcp/wiki/Create-a-local-ISO-repository but ended up with an error, all the time:

admin@admin.net	SR_BACKEND_FAILURE_226(, Invalid local path, )

Via XCP-ng console, I created the parth (in this case /isos) by hand and redid the steps -> SR created.

It's probably missing an I suggest mkdir, if the directory doesn't exist. As the howto probably worked, I guess it got lost by one of the updates?

Edit: I didn't read carefully enough, but this can still be considered as a request (as I didn't see a GH repo to make them)

Somewhere they said they want to algin numbers and XA/XD LTRS only makes sense on a fitting CH LTSR.

They removed the Hypervisor tag from their blog, so finding that posts isn't easy anmore and CH/XS posts get lost in stuff I don't care about.

Looks a bit like they only want to keep it because VMware Horizon becomes more attractive, if Citrix doesn't bring it's own HV for XenApp/XenDesktop for free.

IIRC they said this year should bring another LTSR - as the old one becomes quite old now. The last chance would be a release in Q4 - that would also fit for 7.1 LTSR -> 8.1 LTSR (basically making 8.0 evolutions mature/tested)

Then 8.1 should be the new LTSR. I'd appreciate that. Will XCP-ng follow that concept?