Posts made by olivier

I'm not sure to get Kimchi architecture. Do you need to install it on each node? There is no "pool" concept in KVM world?

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.

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

It's not overkill on user side, and we built it to be able to grow in one click. Have you ever even just checked how easy it's easy to deploy XOSAN? It's really few clicks

And it's second time I heard about the "intelligent split brain" management on StarWind but didn't see any paper nor a start of explanation about how it works (nor even a simple link). Can you elaborate please? If it's the witness node, it's the classical thing, but I'm curious about the split brain protection without using a witness node.

That's why I asked if you have better knowledge of community on this solution because I really don't. So if it's the case, that it's not stable (darn, it's here since a long time!), that's indeed not an option.

@scottalanmiller said in Xenserver and Storage:

@olivier said in Xenserver and Storage:

I don't see the logical connection. Right now, he owns 2 hosts, XS can work with HA lizard or XOSAN in few weeks. No need to buy extra hardware. That's an option. Not maybe a perfect option, but it's not an absurd one.

Right, and we covered, a few times I thought, that HA-Lizard really isn't up to snuff and not all that viable. So we can't keep repeating that as an excuse for things working.

XOSAN we can evaluate when it is on the market and tested.

So again, at this time, didn't we just come back to "no solutions today on Xen"?

I personally don't like solutions that doesn't scale, but if he want to stick on 2 hosts, that's an option. People said it works when it's backed with support. I never heard nor bad or good stories about it. So I wouldn't discard it just after one or two people saying something here. Maybe you have a better knowledge on HA Lizard community and feedback of users? I don't.

Regarding XOSAN, it's already available to test since 6 months and commercial release is in just weeks.

I just said you are really prompt to discard options but again I can be mistaken because I don't have the deep knowledge on HA Lizard community. And again, I wasn't aware of 2 node capability of Starwind.

@scottalanmiller said in Xenserver and Storage:

@olivier said in Xenserver and Storage:

I didn't know about the potential 2 nodes capability of StarWind (I still need to understand how ), so the only absurd thing is to make me tell stuff I never said

You asked why adding extra nodes wasn't an option. So I answered.

No, maybe I wasn't clear (EN not my main language).

You said: HA Lizard is only available for 2 nodes.
I answered that's exactly what he wanted (2 nodes) so why discarding HA lizard?

I don't see the logical connection. Right now, he owns 2 hosts, XS can work with HA lizard or XOSAN in few weeks. No need to buy extra hardware. That's an option. Not maybe a perfect option, but it's not an absurd one.

I don't understand why you are speaking about a 50% hardware overhead to make XenServer work.

I didn't know about the potential 2 nodes capability of StarWind (I still need to understand how ), so the only absurd thing is to make me tell stuff I never said

@scottalanmiller said in Xenserver and Storage:

@olivier said in Xenserver and Storage:

And in short, because Starwind doesn't support XenServer, you think it's better to discard XenServer Why not, maybe in 2 nodes scenario it's an acceptable point of view ^^

What's the other option? HA-Lizard is only available for two nodes. Nothing else is on the market. Starwind, like everyone else, is expected to have something out for Xen in the future, but no one seems to have solutions today. DRBD does work, but isn't ideal and XenServer specifically disavows it. Leaving a weird situation where we can come up with solutions, but we lack elegance or support. When switching out Xen seems to be the obvious solution making all of this moot.

2 node isn't the objective? So why discard that option?

And in short, because Starwind doesn't support XenServer, you think it's better to discard XenServer Why not, maybe in 2 nodes scenario it's an acceptable point of view ^^

I would be curious to understand how it's possible to deal with a replication link failure in 2 nodes scenario. I don't see a lot of options:

• you stop writes to avoid split brain
• you write data in both nodes but if you have one LUN for mutliple VMs, you are doomed to discard one node data

Do you have more details or documentation on how it works?

XOSAN is just weeks from release

How Starwind deals with split brain in 2 nodes scenario? Why it would be better than VSAN? (which is somehow a leader in the VMWare market itself IIRC)

edit: those are true questions, not rhetorical. I'm curious about how to deal with some cases in 2 nodes.

DRBD is working with XS via HA Lizard, XOSAN coming in stable soon, people also working on Ceph (don't know the progress on this one, won't be hyperconvergence however).

I'm not sure there is a ton of solution for a 2 node setup anyway. Even in VMWare (you need a "witness appliance" which is basically the arbiter node of Gluster).

Maybe I missed something?

I don't know about VSAN, but for XOSAN, it will be:

• a virtual shared SR is exposed to XenServer (for XenServer, it's a bit like a NFS shared SR)
• data is chunked (how depends on XOSAN mode, replicated or disperse) on various nodes
• if one host is down with its VM, XS will boot those VMs to other hosts
• each node decide to stop or not their write operations if they can meet the quorum. Eg on 3 hosts, it means 2 VMs can still communicate: it's OK. The isolated host (running but cut of from the rest) will be read only. Luckily, XenServer HA knows it, the host will stop and its VM started elsewhere.

You won't have split brain scenario (data written "independently" on various sides). If quorum is not met: go back to read only. Data integrity is more important than being able to write.

@storageninja It's all explained here:

FIO is used to make the benchmarks, on a Debian 9 VM. It's done on a 10GiB file (enough to avoid caching). Throughput is fetched from XenServer VDI RRDs values, which is pretty accurate and close to the "reality". IOPS are fetched from FIO directly. You can find some FIO examples in this Sam's blog post.

4k for IOPS and 4M used for throughput.

HA is automated and more "dangerous". Live migration is a manual process. That was the context I meant.

I'm not speaking about HA right now, I'm speaking about live migration

HA is another beast, I agree it should be used only after thinking benefits/problems.

Think priorities. It will impact some users (because the updater in XOA), not dramatic for the business but it's better to avoid that. So the cost to have it is negligible (already using virt). And I don't have the resource to make the service app HA (because live migration is free…)

edit: in the end, if I follow your arguments, virtualization is also useless for SMBs.

Eg XS patching for critical sec reasons, I don't have the resources to make our apps redundant at their level, so I rely on virt (and live mig) to avoid outage.

So I should be an exception then

edit: in the end, your perception doesn't really matter if the "market" think otherwise.