We already have a partner program @DustinB3403

We are in the process of working on commercial side for the next months, with some great business specialists.

I'll keep you posted.

I don't want to make an argument from authority, but I think there is a real gap between theory and the reality. Closed Source is like the dark side: easier and faster. But in the end, it's not good.

Open Source is therefore the opposite.

That's my opinion/experience after 2y on the Open Source business (as a primary thing for my company I mean). Feel free to not share this point of view, but it cames from the field

@scottalanmiller RH is really an exception. The way today is:

• go big (millions of $) to have enough power to be critical for millions of users
• go with Freemium model
• or die

@scottalanmiller said in What Are You Doing Right Now:

@olivier said in What Are You Doing Right Now:

@scottalanmiller Careful, that's exactly that kind of talk that would destroy Open Source done by small companies. I have a lot of work to convince investors that's a possible business, same with consultant helping with business. If they read this, tomorrow every new stuff will become closed source

The biggest, most successful open source investors do so by embracing it, though. Look at Red Hat, Ubuntu and Suse. They make their "free and open" message as loud and clear as possible. They know that the money is and always has been in support, not in software. You want to sell your investors on investing in your support business. Just explain that the software is the marketing tool for your support business, not the business itself. If they are looking at your software as what you are selling, they are not very smart investors (not that dumb money is a bad thing, but you know.)

You don't want big investors who are irrational and emotional and don't understand the marketplace. That's a dangerous place to be.

I don't know where do you find your investors/business consultant, but everyone know that Red Hat is really the exception in that business. We aren't Canonical either (lot of money to start).

I don't want to be a "realist" and leave Open Source world, but it won't work for small companies without support of people believing in it, and not reducing the value of it.

@scottalanmiller Careful, that's exactly that kind of talk that would destroy Open Source done by small companies. I have a lot of work to convince investors that's a possible business, same with consultant helping with business. If they read this, tomorrow every new stuff will become closed source

XO is the software, XOA is the product. That's not a miracle, you pay for a service to enjoy XOA (turnkey, updates, QA and support). When you are running a reasonably sized company, time is even more important than a relatively small monthly fee.

But yes, we'll add more services in XOA, to help people people to understand more the real value of it

Yes, XOA is bundled with certs (autosigned but still).

Anyway, doc is here: https://xen-orchestra.com/docs/configuration.html

Even antivirus software are a pain with websocket protocols. That's why we recommend to go in HTTPS before going further in debug.

It seems you have side issues with connection between you browser and the server. Are you in HTTPS?

I'm blaming myself for doing multiple things at once. Got a trip early tomorrow, so I'm going to bed See ya!

\o/

@scottalanmiller said in Someone doesn't like local storage for large amounts of data:

@olivier said in Someone doesn't like local storage for large amounts of data:

The thing, initially, was about having VMs with large VDIs. Which is for me not a good practice.

But if you need to store a large amount of data, it's better to connect to a remote file share in the VM and keep small system disks (excepts for db/web usage, which are not huge in general).

That's all.

edit: is it more clear now?

Let's see if I reword it correctly....

If your VM needs a lot of file storage.... then it is better to mount that from a file server rather than keeping it in the original VM?

Yup, that's it. Because a lot of file storage will mean a large VDI, which is "dangerous".

The thing, initially, was about having VMs with large VDIs. Which is for me not a good practice.

But if you need to store a large amount of data, it's better to connect to a remote file share in the VM and keep small system disks (excepts for db/web usage, which are not huge in general).

That's all.

edit: is it more clear now?

@scottalanmiller Because that's not my point aaarrrgghh. I don't care, that's a not something I wanted to focus in my opinion at the first place.

@scottalanmiller That's not my point. A big virtualized NAS is doable if you like. I was talking about the architecture. Damn, I have the impression to speak Chinese. Sorry if I can't express clearly my ideas in English.

Okay, let's imagine your NAS is on a larger VMs talking all space of your local storage of your XenServer/ESXi/whatever host. And exposing mounts to all other VMs on other hosts. That's doable but that's not my point. For me, this setup is almost the same of having a physical NAS/SAN.

My point is: for ALL your VMs, it's better to have smaller VDIs everywhere and mount a filer elsewhere if needed.

@scottalanmiller I think there is a misunderstanding somewhere, I don't get your point. I'm not talking about performances limits at all.

@scottalanmiller What's the point of a virtual filer if you can't easily move it. Very large VDIs defeats the flexibility of virtualization.

@scottalanmiller I don't agree and that's not my point either. If a filer is overcrowded, that's not a virt vs physical issue, that's a capacity planning issue.

Here, I'm talking about general architecture, not implementation details.