One post tagged with "1.9.1"

1.9.0 Major Release Items​

What's New​

First-Time Setup Wizard​

New appliances now boot into a guided Setup Wizard that walks you through every first-run step in the browser: hostname, network (DHCP or static IP with DNS), timezone, TLS certificate, licence activation, admin password, authentication method, and the initial storage pool. There is no more manual bootstrapping over SSH.

See the Setup Wizard guide for the full step-by-step walkthrough, including DHCP vs static IP networking and installing your own TLS certificate.

End-to-End iSCSI Agent Orchestration​

vME can now drive the SQL Server iSCSI workflow remotely and automatically. A lightweight Windows agent (installed from an MSI, run as a background service) enrols each SQL Server host with vME and then picks up and runs onboarding, migration, and clone mount/unmount jobs on demand - with no one logging in to run PowerShell.

Agents are managed centrally from the new Agent Manager in the web console: create one-time enrollment tokens, watch each agent's live status, and rotate keys - all over an outbound-only connection (port 443), so no inbound ports need to be opened on the SQL host.

See the iSCSI Connector - Automated (Windows Agent) guide for setup and usage.

Application Onboarding Wizard (Beta)​

A new Onboard Application wizard (Beta) guides you through cloning a production database onto another vME appliance end to end - pairing the two appliances, discovering the source host, and driving the iSCSI agent through prep, snapshot, clone, and mount. This is an early Beta; we'd love your feedback.

See Onboard Application (Beta) for the full workflow.

Container Connection Details​

vME now surfaces each database container's connection details - host, port mappings, mount paths, database type, and environment variables (such as POSTGRES_USER / POSTGRES_PASSWORD) - in the web UI, so you can connect to a running database without hunting for its settings. The container list API (GET /docker/container/list) returns the port mappings, mounts, database type, and environment variables as well.

See Getting container connection info for details.

Consistent Snapshots​

When you snapshot a source or clone that has running database containers, vME now stops those containers first, takes the snapshot, and restarts them - so the captured data is consistent rather than mid-write. The UI shows a container-aware confirmation listing exactly what will be stopped.

See Snapshots for more info.

Rename Sources and Clones in the UI​

You can now rename sources and clones directly from the web console, instead of destroying and recreating them. (Renaming is not supported for iSCSI sources and clones.)

Unix CLI Install​

The vME CLI can now be installed on Unix, in addition to Windows, so you can run it from the command line on either platform. The CLI is also up to date with the 1.9.0 API. See the CLI guide to download and install.

Improvements​

• Clearer LDAP errors - a failed LDAP login now shows the actual error returned by the directory, instead of a generic message.
• Licence errors surfaced - operations blocked by an unlicensed or expired appliance now show a clear licence error.
• Longer sessions - the web session timeout has been extended to 24 hours.

Fixed Issues​

iSCSI connector

• Snapshots now flush the LUN write cache before the snapshot is taken, so clones are no longer occasionally created RAW/empty.
• Skip-backup no longer crashes when pointed at a single backup file.

Platform

• Login now signs in correctly on the button press after a session timeout.
• Fixed a UI refresh glitch when switching between menu items.
• Fixed cross-appliance API calls failing due to certificate handling.
• Resolved intermittent stale database-connection errors.

API Changes & Upgrading​

The 1.9.0 REST API is documented in the vME API reference. A few endpoints changed shape in this release - if you maintain a custom REST integration, review these before upgrading. (The vME web UI and CLI ship updated with the release and need no changes.)

Grab the updated vME Postman collection to get all the new and changed endpoints ready to run - it also includes an Onboarding (API) folder that replicates the full Onboard Application flow as ordered, chained requests.

Breaking changes

• POST /user/modify now requires your current_password, and a password change is sent as a structured object:

  - { "username": "jane", "password": "NewPass456!" }
  + {
  +   "username": "jane",
  +   "current_password": "OldPass123!",
  +   "password": { "current": "OldPass123!", "new": "NewPass456!", "confirm": "NewPass456!" }
  + }
  
• DELETE /user/delete now requires your password and a typed confirmation:

  - { "username": "ubuntu123" }
  + { "username": "ubuntu123", "password": "MyPassword123!", "confirm_text": "DELETE ubuntu123" }
  
• POST /db/receive is now asynchronous - it returns 202 Accepted with a task_id. Poll GET /tasks/<task_id> for completion instead of expecting a synchronous result.

New and improved

• New endpoints: POST /db/send/cancel, POST /user/changepass, POST /db/network/create, DELETE /db/network/delete, and GET /tasks/<task_id>.
• iSCSI sources & clones over the API: POST /source/create and POST /clone/create accept a network_info block (type: iscsi, with auto_grow / vsize), and the iSCSI target is provisioned automatically as part of creation.
• System-to-system db send no longer needs an SSH/PEM key - vME establishes trust with the receiver automatically using its admin api-key.

1.9.1​

Version 1.9.1 is a focused update to the Onboard Application workflow and the iSCSI connector, based on feedback from teams using them day to day.

What's New​

Choose Your Own Database Name Prefix​

Databases ingested onto iSCSI storage were always named with a fixed ISCSI_ prefix. The ingest step now has a Target database prefix field (under Advanced options) so you can pick a naming scheme that suits your environment. The default remains ISCSI_, already-ingested databases are detected using your chosen prefix, and teardown detaches using the same prefix the workflow ingested with.

Tear Down the Source Host​

Once an application has been onboarded and cloned to the target appliance, you can clean up the source SQL host with one click. Tear down source detaches the staging databases, disconnects the workflow's iSCSI sessions, and frees the drive letters on the source host - without touching the source dataset on the appliance, so you can keep cloning from it. Only the workflow's own sessions and databases are affected.

Recognisable Snapshot Names​

Snapshots created in the wizard now default to a name derived from your source name (for example SalesDB-20260729103000) instead of the generic prepared-<timestamp>. The name stays fully editable, and invalid characters are rejected with a clear message.

Automatic Drive Letter Assignment​

The ingest and clone-mount steps now pick free drive letters automatically instead of defaulting to fixed letters that may already be in use. The pickers prefer the host's recommended letters when free, and never assign the same letter to data and log. Selecting an in-use letter manually still asks for confirmation before reformatting.

Improvements​

• P: and S: are now assignable as data/log drive letters across the wizard and the Windows connector.
• Teardown is kinder to shared hosts - a full iSCSI cleanup no longer restarts the Windows iSCSI service, so other iSCSI workloads on the same host are not interrupted, and mount-point cleanup only touches the drive letters the workflow owns.

Fixed Issues​

Onboard Application​

• Workflow steps completed directly via the REST API (for example with the Postman collection) are now recorded on the workflow and shown on the wizard's stepper, which refreshes live - previously the stepper only updated for actions taken inside the wizard itself.

iSCSI Connector​

• Tearing down a clone could leave the iSCSI session reconnecting automatically: persistent target registrations are now parsed and removed correctly, so a torn-down target stays disconnected.
• Sessions are now disconnected reliably even when the target is no longer in the discovered-targets list.
• Disks are taken offline before their session is disconnected, so volumes dismount cleanly during teardown.
• The teardown's database-detach step can be skipped cleanly when there is nothing to detach, instead of stalling the run.

API Changes & Upgrading​

Update the Windows connector to use the new features. The custom database prefix and the teardown fixes live in the Windows iSCSI connector - update the connector (MSI) on your SQL Server hosts as part of this upgrade. Until a host's connector is updated, ingests on that host keep the default ISCSI_ prefix regardless of what is set in the wizard.

Behaviour change for direct connector use: in the teardown script, the disconnect selection now takes Windows disk numbers (as shown in the script's disk listing) instead of session list positions. ALL and MATCH selections are unchanged, and wizard-driven teardowns are unaffected.

API additions (all optional, backwards compatible):

• The ingest and teardown jobs accept a dbPrefix value (migrate.dbPrefix / unmount.dbPrefix).
• The snapshot, clone, source, and send APIs accept optional workflow tracking fields (workflow_id, wizard_step, role) so API-driven onboarding steps appear on the wizard's stepper.
• The vME Postman collection's Onboarding (API) folder has been updated to use these fields.