Introduced by #8491
See #10201 (same workaround)
`VM.set_VCPUs_at_startup` ran concurrently and re-added `cores-per-socket`
between its removal and its re-addition, making the VM creation fail.
The deploy form now offers Small (2 vCPUs, 4 GiB), Medium (4 vCPUs,
8 GiB) and Large (8 vCPUs, 16 GiB, default) presets. Update the sizing
table to match, and drop the manual --max-old-space-size procedure:
since 6.8, xo-server sets its heap limit to 70% of the VM RAM.
Signed-off-by: Olivier Lambert <olivier.lambert@vates.tech>
* fix(@vates/iscsi): only replace the session once the newcomer has logged in
A new TCP connection used to tear down the active session as soon as it
was accepted, before sending anything. Any peer able to reach the port,
a port scan, a failed CHAP login or a Discovery session, interrupted the
disk in use.
New connections are now kept aside until they establish a Normal session
(CHAP included when configured), and only then replace the active one.
That keeps the ability to recover from a stale connection, which is why
connections are replaced rather than refused.
Connections without a session are bounded in time (`loginTimeoutMs`,
15 s by default, also closing lingering Discovery sessions) and in number
(`maxPendingConnections`, 8 by default, oldest dropped first).
* chore: add PR number to changelog
* fix(@vates/iscsi): refuse extra connections and guard the login race
Review follow-up:
- let net.Server refuse connections past maxPendingConnections (+1 for
the one serving the LUN) instead of evicting the oldest pending one
- a connection destroyed while its final Login Response is being written
must not go on and replace the current session
* feat(@vates/iscsi): bound what a peer can make the target do
- allowedAddresses: close connections from other initiators as soon as
they are accepted, so that they cannot take the pending connection
slots and block a legitimate login
- reject a PDU whose data segment exceeds 8 KiB during login, or the
declared MaxRecvDataSegmentLength afterwards, before reading it
- maxTransferLength (8 MiB by default): advertised in the block limits VPD
page, longer READ/WRITE refused, which also bounds the WRITE buffer
- BlockDevice.readOnly: report the LUN write-protected and refuse WRITE
with DATA PROTECT before soliciting any data; DiskBlockDevice sets it
* chore: add PR number to changelog
* feat(@vates/iscsi): rename allowedInitiatorAddresses, report refused connections
`allowedAddresses` did not tell whose addresses: these are the source
addresses of the initiators. `onConnectionRefused` reports each refused
one, e.g. so that a caller can tell that an initiator connects through a
NAT.
---------
Co-authored-by: Florent BEAUCHAMP <florent.beauchamp@vates.tech>
The CHAP interop test failed on CI with ENXIO on /dev/sdb (master 641f98878,
and #10549), right after waitForDevice() returned the disk.
waitForDevice() took a nonzero /sys/class/block/<name>/size as proof the disk
was ready, but the sd driver sets the size before device_add_disk(), which
creates the sysfs entry, then the /dev node, then registers the block device:
open() fails with ENOENT or ENXIO until then. Polling sysfs in a tight loop
after login hit that window in 15 of 100 logins.
isDeviceReady() now opens the device, and treats ENXIO and ENOENT as not ready
yet.
* feat(fs, backups): don't concatenate buffers but write them directly
maximum throughput with a perfect source and no write goes from
4.5 to 9.6GB/s
* fix: remove Buffer concat in qcow2 stream generationonly needed for last block
* feat(nbd-client): support nbd insecure networks
* feat(xo-web): support insecure nbd
also add a confirm on insecure enabling
The dialog is titled "Enable insecure NBD?" and says: "The disk data of the backups will travel unencrypted on this network. Only enable it on a network dedicated to backups and isolated from the VMs and the users (dedicated VLAN or physical network)." Both texts are new entries in messages.js, and the dialog itself is a new confirmInsecureNbd() helper in xo/index.js.
It appears in two places:
Pool Network tab (tab-network.js):
The dialog only appears when switching a network to insecure NBD. Reselecting it on a network that already has it, or switching to "NBD" or "No NBD", doesn't ask.
On cancel, nothing is sent and the drop-down keeps showing the network's current setting.
Network creation form (new/network/index.js):
The dialog appears on "Create" when insecure NBD is selected (bonded and private networks are never affected).
On cancel, the network isn't created and the form stays as is, with no error and no redirect.
* feat: update xo5,xo6 and lite ui for this settings
---------
Co-authored-by: MlssFrncJrg <119158464+MelissaFrncJrg@users.noreply.github.com>
* feat(xo6): add edit form BR
* type disable
* wip
* fix post rebase
* form initial data ok
* form ok
* add tests dans finalize edit
* refacto for PR
* refacto for RP
* rebase ok
* feedback
* PR ok
* add changelog
cargo deny fails on master since RUSTSEC-2026-0346, 0347, 0348 and 0349
were published against rustls 0.23.45. 0.23.46 fixes all four.
vectura has no custom session store, no ECH and no brotli feature, so
only 0349 (later connections downgraded to classical key exchange through
the resumption cache) applies, in theory.
vectura 0.1.3, bumped and rebuilt with scripts/release.sh patch.
The binary in git is now the build of its sources. build.sh keeps the paths
of the machine out of the binary and refuses another zig or cargo-zigbuild
version, and the Vectura workflow fails when its build differs from the
committed binary. The binary is rebuilt with this build.sh: only its paths
change, the version stays 0.1.2.
vectura is no longer released on its own. release.sh runs once at the end of
the pull request which changes vectura and no longer commits. bump-pkg,
gen-deps-list.js and check-changed-pkgs.js drop the vectura pseudo-package: a
change under vectura/ requires a release of @xen-orchestra/vmware-explorer,
which ships the committed binary as is. release.sh puts Cargo.toml and
Cargo.lock back when the build or the check of the binary fails.
