Best posts made by olivier

@DustinB3403 Don't forget to tell there is a commercial solution for companies wanting to have a turnkey+update+support with it

@black3dynamite I'm not sure to understand the question.

So far, the "stack" is:

• Local Storage in LVM (created during XS install)
• on top of that, filling it by a big data disk used by a VM
• the VM will expose this data disk
• XenServer will mount this data disk and create a file level SR on it
• VMs will use this SR

It sounds like a tons of extra layers, but that's the easiest one I found after a lot of tests (you can see it as a compromise between modifying the host too deeply to reduce the layers VS not modifying anything into the host but have more complexity to handle on VM level). You can consider it as an "hybrid" approach.

Ideally, XenServer could be modified directly to allow this (like VMWare do with VSAN), and expose the configuration via XAPI.

I think if we (XO project) show the way, it could (maybe) trigger some interest on Citrix side (which is only into XenDesktop/XenApp, but hyperconvergence even make sense here)

Hi there,

XOSAN beta is meant to be done on XOA only because it uses mechanism related to xen-orchestra.com (you need a valid account there, with a valid token). So it's not possible to try XOSAN via XO on the sources.

It's still in a really early phase right now, so before going further we'll validate all the Phases explained in the blog post.

About the StarWind thing, I don't know the product at all, but on our side it's:

• XenServer only
• Thin provisioned
• Pool wide, ie working from 2 nodes up to 16 (well in theory more, but it's pool-wide not across pools)
• Uses Duplication/Triplication but also Disperse mode, depending of your need
• Auto heal (when a host/node is coming back online, it fetches all the missing data)
• Easy install/deploy (thanks to XOA)
• And more (basically, everything you can do with GlusterFS but "in a box", so think about HDD+SSD caching, complex disks usage to avoid any hardware RAID etc.)

@scottalanmiller said in Xen Orchestra news :

Sweet. So it installs to the Dom0?

Nope, that's a bad idea It downloads the virtual appliance, set stuff and boot it.

@scottalanmiller Especially the streaming thing

Believe me, it wasn't a piece of cake, due to the extreme old age tooling in dom0 (curl from 2006 in XS 6.5! Doesn't support SNI etc.)

edit: we even had to write our own HTTP server…

Not a published blog post (still in draft) but here is some bench done, please follow this link and keep it for yourself

We hope to make it for the end of the month (phase II) with a robust health status and flexibility (XOSAN full diagnostic, allow to replace in one click any faulty node, and everything auto heal itself).

Also, we'll try to release the Gluster driver in Open Source for those who want to connect XenServer to an existing Gluster or create their own XOSAN manually.

XOSAN will be an extra product of Xen Orchestra (but you can purchase even in XOA Free), including the turnkey side (and believe me it's not trivial) with full diag status and health + flexibility, including pro support on it obviously.

We'll try to make a Phase III before the official release, with tiering capabilities (HDD + SSD cache to get best of both world).

We started to create the official doc here: https://xen-orchestra.com/docs/xosan.html

Remember the goals of XOSAN:

• protect your data thanks to replication of data on multiple (from 2 to 16) hosts
• provide XenServer high availability without buying a NAS or a SAN
• give you flexibility to grow your storage by adding new nodes
• work on all kind of hardware, from HDDs to SSDs
• fully monitored solution

1. Doc is not completed because the product isn't. Consider it as a draft.
2. Blog post is still a draft

@francesco-provino said in Manage KVM through Cockpit:

Why everybody seems to need a GUI for KVM? Virsh can do absolutely anything, in a much more concise, fast and elegant way. It's also very bandwidth friendly.

That made me laugh a lot

@fateknollogee The need for UI in Open Source is ultra-important, and I don't get why people don't get it.

It's even possible to make some money with that So when I heard someone telling this, it's really funny and remind me some disdain I met in the past when I started Xen Orchestra.

Article is out (as 5.12): https://xen-orchestra.com/blog/improving-xenserver-storage-performances-with-xosan/

Doc updated: https://xen-orchestra.com/docs/xosan.html

Here it is with improved pics of XOSAN, I suppose it's more clear now:

What do you think?

@scottalanmiller said in KVM vs XenServer:

@kuyaz said in KVM vs XenServer:

Can memory be shared also between VM?

That depends on the hypervisor. VMware ESXi can do this. It's an extremely limited feature and of little value. It's neat and good for things like VDI, typically, but not very useful for servers and there is a reason most platforms don't work towards adding it.

I concur. For most workloads, it's more a pain than a solution.

Do you know any valid API that can be called remotely and doing also network and storage operations?

I can't figure why I can't find this.

@romo said in What is KVM Best Management Tools in 2017?:

DigitalOcean's apparently using their own built go-qemu and go-libvirt which they opensourced

https://blog.digitalocean.com/introducing-go-qemu-and-go-libvirt/

Maybe that could help as well, they mention they are not fully stable but they are using them in production.

Thanks for the precious hint! I'll take a look (right now, if I had to build something on API level, I would do it in Rust, but that's just my 2 cents)

@RojoLoco

1. I'm not an XO sales engineer (lol). I'm the project founder, which is 100% Open Source (and you can build it from the sources easily)
2. And I wasn't talking about XO in my post!

I understand the business model somehow, but it's really distorted by those mods I won't come back there, obviously.

Thanks for the answers guys. That makes sense now. Mangolassi >>>>>>>> Spicework.

I think they assumed the word "community" means "sheeps that you can drive toward a sales funnel"

The short term goal is to have:

• the latest XS version with "XenServer" name replaced by XCP-ng
• removal of all feature restriction
• easy upgrade path from XS to XCP-ng

Mid-term goal:

• rely on RPM repo for all operations
• validate/authorize more vanilla packages to be used on Dom0 for more integrations within Xen and XAPI

Long-term goal:

• contribute directly to mainline (XAPI/drivers)
• re-unite XAPI into a mainline without license check

Thanks for correcting the sentence @travisdh1 Indeed, SMAPIv1 is using VHD format everywhere. This format is limited at 2TiB by "design" [1] . This has nothing to do with XO or even XCP-ng because it's a fork of XenServer, ie a copy with new or improved code. So remember that regardless which filesystem you use, as long as you are using VHD format to store virtual disk, you are limited to 2TiB.

However, SMAPIv3 is using qcow2 format instead, "solving" this limitation. We (XCP-ng team) are currently working on improving SMAPIv3 to support disk import/export in qcow2 (which isn't even done by Citrix people themselves ). As soon we got that, the next step is to write drivers for ext4 for example, which is doable relatively easily.

One of main issue with SMAPIv3 (there's others) is the fact a part of the development is done privately by Citrix instead of collaborating (see this conversation on GitHub), so the goal is to catching up on our side to be able to get an upstream public faster and become the de facto upstream standard. We are working toward that but it's not something you solve in one week (you need to go deep in qemu-dp/xen blktap, see our efforts here etc.)

[1]: The VHD format has a built-in limitation of just under 2 TiB (2040 GiB) for the size of any dynamic or differencing VHDs. This is due to a sector offset table that only allows for the maximum of a 32-bit quantity. It is calculated by multiplying 232 by 512 bytes for each sector.

edit: also, as soon we got qcow2 import/export support in XCP-ng, we could use that format in XO to store backup. So far, there's only 2 options to get disk data from XS/XCP-ng: raw or vhd (that's why XO is storing VHD files, because… that's what we got from the hypervisor!)

@stacksofplates said in KVM or VMWare:

@pete-s said in KVM or VMWare:

It isn't the ability to automate that is the problem. It's the availablility of easy to use tools that is the problem.

Thats the whole point I'm making.

KVM is hard to automate. Not that it's impossible, but the tooling doesn't exist to where you can easily automate like with VMware.

And that's a very good point. That's why here at Vates, we made various efforts in XCP-ng/Xen Orchestra, providing multiple solutions: Packer, Terraform and even Ansible integration. That's also why Xen Orchestra really makes sense as a "middleware", as a single central point to consume with its API. Like vCenter in fact.

This is a true way to create value on top of it. The other aspect is all about integration, like we did with Netbox for example (sync all VMs and hosts, with their IP address, config and such to Netbox).

Automation is key.

Some links/resources:

• https://registry.terraform.io/providers/terra-farm/xenorchestra/latest/docs
• https://github.com/ansible-collections/community.general/pull/3344
• https://xen-orchestra.com/blog/netbox-sync-with-xen-orchestra/

IMHO (just read the first post): when you hire someone, it depends completely for which tasks and/or in which team you want to place it. It's a "human problem" first.

It's like having a sport team: you need to have a balance. The whole should be more than the sum of its parts (that's the key).

So when I spent time with potential candidates, it's entirely a question of feelings, ability to be not serious and have at least one interest in common with people he/she will work with. Then it's about curiosity and capability to search for itself (that's easy to spot during the trial period). That's also the time to see the "enjoy" level during working (mood is a good indicator).

Technical ability will come last.

So what about home lab? It could be something great if it fits with the rest of personality, but not a game changer per se.