mirror of
https://github.com/vatesfr/xen-orchestra.git
synced 2026-11-09 17:06:13 -06:00
e2ca66130c4f69cda6b65820d4fc4d30a4c8f036
* refactor(mixins,proxy,xo-server): pass the XAPI names as one xapiLabels object The SR name was a lone `nameLabel` threaded through xo-server, xo-proxy and the mixin; the VDI names are about to join it. No change in behavior: the proxy API still takes `nameLabel`. Also export OC_MOUNT from _utils.mjs, the cache module will need it. * feat(iscsi): FileBlockDevice can serve a block device node With `size`, the path must be a block device (e.g. a VDI hot-plugged onto the appliance, /dev/xvdX): its inode reports a size of 0, so the capacity comes from the caller, and a short read is an I/O error instead of a sparse tail. Also add unit tests for FileBlockDevice, which had none, and integration tests against a loop device. * feat(iscsi): advertise read-only LUNs as write protected A read-only BlockDevice now sets the Write Protect bit of MODE SENSE, so the guest mounts the disk read-only instead of failing on its first write. This is the case of a live mounted disk, served by a read-only DiskBlockDevice. * feat(live-mount): name the SR and VDI after the backed up VM and restore point The SR is now `[XO live mount] <VM> (<backup date>)` and the VDI keeps the name of the backed up disk, so a live mounted disk reads like the disk the user knows. The VDI is also tagged with `xo:live-mount`, like the SR. The proxy API takes them as `xapiLabels`; `nameLabel` is still accepted from older XOs. * feat(live-mount): optional local VDI cache, making the mount read/write Without a cache, a live mounted disk is read-only and every read goes to the backup repository. With `cacheSrId` (xo-server) / `cacheSr` (proxy API), the disk is materialized block by block into a VDI of that SR, hot-plugged onto the appliance serving the mount (XOA or the proxy): - a block is read from the backup repository at most once; - the LUN is read/write, writes land in the cache VDI and the backup is never modified; - the VDI is created with the mount and destroyed with it: what was written is lost on unmount. The appliance must be a VM of the target pool, and the SR plugged on the host running it. On a local SR, the appliance must not be migrated while the mount lasts, since the cache VDI cannot follow it: this is documented, not enforced. The cache VDI is tagged `[NOBAK] [NOSNAP]` to stay out of the appliance's own backups, and the SR of a cached mount is named `[XO live restore] …`. The cache device is opened with retries, since its node may lag behind the hot-plug.
Xen Orchestra
Manage, Backup and Cloudify your XCP-ng/XenServer infrastructure
XO (Xen Orchestra) is a complete solution to visualize, manage, backup and delegate your XCP-ng (or XenServer) infrastructure. No agent is required for it to work.
It provides a web UI, a CLI and a REST API, while also getting a Terraform provider among other connectors/plugins.
⚡️ Quick start
Log in to your account and use the deploy form available from the Vates website.
📚 Documentation
The official documentation is available at https://docs.xen-orchestra.com/
Documentation updates are deployed automatically once per day.
🚀 Features
- Centralized interface: one Xen Orchestra to rule your entire infrastructure, even across datacenters at various locations
- Administration and management: VM creation, management, migration, metrics and statistics, XO proxies for remote sites… XO will become your best friend!
- Backup & Disaster Recovery: The backup is an essential component for the security of your infrastructure. With Xen Orchestra, select the backup mode that suits you best and protect your VMs and your business. Rolling snapshot, Full backup & replication, incremental backup & replication, mirror backup, S3 support among many other possibilities!
- Cloud Enabler: Xen Orchestra is your cloud initiator for XCP-ng (and XenServer). Group management, resource delegation and easy group administration. The Cloud is yours!
🌍 Translations
Status of XO Lite & XO 6:
Help us translate Xen Orchestra in more languages!
📸 Screenshots
License
AGPL3 © Vates
Description
Languages
JavaScript
55.4%
TypeScript
26.9%
Vue
13.5%
Rust
3.1%
CSS
0.4%
Other
0.5%


