@John-Nicholson There is probably a lot of things you don't realize about XO, but I don't bother to be forgotten in a niche market

1. Even when quiesce is calling the VSS service (via the guest tools of XS)? if it's not enough, it's broken from my point of view. Hint: I'm a Linux/BSD guy, and I'm often baffled by (dis)order of magnitude when you are dealing with MS world. But that's my turn to not realize a lot of things about this, you are the pro on that! PS: about why backup is expensive: is it your opinion as a VEEAM or VMWare developer?

2. Yes, despite XO is a recent backup products, we are able to execute quite fast And in fact, it's in the pipe to have "proxies" on remote site to improve the global traffic flow in a distributed architecture. Adding compression into it could be a good idea indeed. Thanks for the tip, this will be trivial to implement I'll open an issue to not forget that! (WAN accelerator is also a cool name for this!)

3. Bigger issue + MS apps in the same sentence: I trust you on this. For my curiosity, cf my first question in 1

Anyway, if you are from VMWare, I'll be glad to ask you some questions regarding licensing, segmentation is crazy and I have some difficulties to compute in head to head scenario the cost of XO/XS vs VMWare/VEEAM. I'll send you a message in private if you have a bit of time Thanks!

@John-Nicholson said in Why is VMWare considered so often:

@DustinB3403 said in Why is VMWare considered so often:

@Carnival-Boy I must've missed that part.

But still the justification of cost for such a tiny deployment of a single host and 2 VM's to have to pay even the $500 seems insane.

Why do you need the Backup API's for 2 VM's. Just use in guest agent backup tools (Unitrends, ShadowProtect). There are backup options for ESXi Free (Trilliad, and GhettoVCB).

The backup API's (CBT/VADP) are only valuable at scale, and given that Hyper-V hasn't had a CBT API Until 2016 (which isn't wildly supported yet by backup products) Arguing that you NEED essentials license to get a comparable functionality isn't actually true. Xen doesn't have a CBT based backup API (Doing external backups still requires doing a full read). XO does have a non-application consistent forever reverse incremental snapshot system, but that's still going to require a full read of IO for synthetic roll ups, and the lack of application consistency makes it un-usable for transnational workloads.

For some reason everyone on SW and ML seems to think that the Backup API's are CRITICAL when your talking about a tiny SMB (they aren't) and ignores their value at scale (Where they are critical to reducing backup windows by 95%). I've never really understood this...

I'm not sure to understand if you understand (^^) XO delta backup.

1. We are using quiesce snapshots by default (if the VM support it, it will be consistent on VM level).
2. What do you mean about "require a full read of IO for synthetic roll ups"? We are exporting only the changed blocks between 2 snapshots (therefore, generating a small VHD file). Then, the oldest delta VHD will be merged into the full VHD, on the remote storage (so without the XenServer assistance).
3. We don't have any report of issues in restore even for DBs.

edit: you are a vendor from which company?

@scottalanmiller It's planned to release file level restore in next release (~15 days) if everything go smooth.

@Danp Thanks!

@Danp Your storage is on your host right?

Hey there,

If anyone can make some quick benchmark if you have any Windows based VM: using Crystal Disk Mark (latest, 5.2 I think) with the default parameters (5/1GiB)

Done tests on Windows Server 2016 (TP5, yeah I know I'm late) and I would like to compare how much I can lose in a hyperconverged scenario.

Also, telling the SR type and the physical device underneath would be great Thanks!

edit: no worries, I'm not here to compare apples to apples, just want a quick order of magnitude.

SMB share are not mounted in the system, we are talking directly to the share in Javascript using SMB protocol.

About the OP, I don't understand what is the issue.I need more input to understand why you "can't add a SMB share"

@BRRABill Nothing. It means the patch was probably installed via another patch (some patches "embed" previous patches). So this exact patch doesn't use space.

That's a bit strange but that's how XS patches work.

Should be the same behavior everywhere (at least since we fixed it)

Explanation: a "soft" reboot will try to live migrate the running VMs on this host to another one.

But if it's not possible, the XenServer exception will be NO_HOSTS_AVAILABLE. Now, we are able to catch it and display a extra message to ask for force.

@BRRABill Advanced tab, force reboot.

This is fixed in next-release coming soon in stable (we catch the exception in XenServer and display a modal to confirm force if normal reboot can't be done)

@momurda Yep that's a solution IIRC.

@BRRABill Maybe but if it's possible it's not trivial. I'm afraid you'll have to do it a bit manually until we work on that.

We started to implement a way to catch this message properly to give more feedback when it happens (and ideally one day, unmount automagically all guest tools ISO)

@BRRABill If there is an error in Xenserver, it stops the update process, just reclick on the button and it will resume to the last patch.

Unmount guest tools on all your VMs.

If it stopped (no pending tasks related to patches), there is probably something that stopped it.

Check in settings/logs to see if there is something.

edit: you can re-click on the update button. It won't explode.

Yes, it means it will be only applied after a reboot. But it's not the end of the world to apply everything and reboot after

At least a modular storage "API" for XenServer: http://xapi-project.github.io/xapi/futures/smapiv3/smapiv3.html

It will allow to plug any filesystem/share into XenServer via "simple" plugins.

For me, that's the best "neat" solution coming, but it's not yet ready.

@FATeknollogee It doesn't work like that.

Playing/exploring a technology is one thing, releasing a minimal viable product is another one. Maybe my exploration will finish by a "it will be better to wait for SmapiV3 in XenServer" verdict.

I set some goals, I'll try to reach them but I can guarantee anything. About the file level restore, our lead dev work on it, not me. So I try to have my "tech time" on this (which is a bit hard considering I'm doing a lot of not technical work)