@ryan0413 no, nothing.. I have abandoned this

@olivierlambert then I will make this happen today and report back. I will check for a trial but I do believe it is over (for my address),

@olivierlambert I think I cannot switch XO just like that. I will try to get some demo XCP-ng to get some testing done and try to reproduce the error.
But for the sake of discussion - is LVM supported (in either version) for a file-level restore?

@olivierlambert XO from sources

Hello,

I enabled Delta backups for some VMs, mainly, where I predict I would need file-level restore. The backup is working, I can use functionality to the point, I start to select files to restore, where I can select none, there is a triangle next to the "/" - I figured out, I think that this is due to that some of the servers are set up to use LVM. Is the LVM file level restore not supported or must I set something else?
If this functionality is used and it is very interesting to us, should we switch to a simple layout and ditch LVM?

Here is some tech info:

backupNg.listFiles
{
  "remote": "70cc277b-7a40-4be1-b3bb-af6694d7fd77",
  "disk": "/xo-vm-backups/d6abcfc8-3337-9e66-c175-f58533d688f1/vdis/d91f37df-35a4-4739-b874-8ddfebabe7ff/42718aed-3400-433e-af30-cf516a6c11f2/20230506T230845Z.vhd",
  "path": "/"
}
{
  "code": -32000,
  "data": {
    "code": 32,
    "killed": false,
    "signal": null,
    "cmd": "mount --options=loop,ro,norecovery --source=/tmp/1uvkqhp2qbq/vhd0 --target=/tmp/6ahkt5lz58w",
    "stack": "Error: Command failed: mount --options=loop,ro,norecovery --source=/tmp/1uvkqhp2qbq/vhd0 --target=/tmp/6ahkt5lz58w
mount: /tmp/6ahkt5lz58w: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

    at ChildProcess.exithandler (node:child_process:419:12)
    at ChildProcess.emit (node:events:513:28)
    at ChildProcess.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202305081615/@xen-orchestra/log/configure.js:52:17)
    at maybeClose (node:internal/child_process:1091:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)
    at Process.callbackTrampoline (node:internal/async_hooks:130:17)"
  },
  "message": "Command failed: mount --options=loop,ro,norecovery --source=/tmp/1uvkqhp2qbq/vhd0 --target=/tmp/6ahkt5lz58w
mount: /tmp/6ahkt5lz58w: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
"
}

Thank you!
rgD

@lawrencesystems I am looking at it right now. Thank you!!

@splastunov said in File restore not finding any option:

If nothing will help and you can't import xva with import VM, I have solution.

1. Deploy new VM with disk x4 times greater than backup file. OS Ubuntu 16.04 or later.
2. Copy backup. Take attention. You need always copy backup. Do not move it.
3. Install xva-img https://github.com/eriklax/xva-img

add-apt-repository ppa:ubuntu-toolchain-r/test && apt-get update && apt-get install -y gcc-7
cd to xva-img dir and run next command
cmake ./
make install

4. Extract xva file

tar -xf my-virtual-machine.xva -C my-virtual-machine
chmod -R 755 my-virtual-machine

5. In folder my-virtual-machine you will find some directory like Ref :1, but maybe with another number. Remember this number.
6. Create raw disk from extracted. Replace 1 with number from previous step.

xva-img -p disk-export my-virtual-machine/Ref\:1/ disk.raw

7. Install qemu-utils

apt install qemu-utils

8. Convert raw to vhd

qemu-img convert -f raw -O vpc disk.raw [vhd-name-you-like].vhd

9. Copy vhd to some SR. I'm using local SRs, so in my case path is /var/run/sr-mount/[sr-uuid]
10. Go to the host, cd to SR folder, get VHD uuid, rename VHD

cd /var/run/sr-mount/[sr-uuid]
vhd-util read -p -n [vhd-name-you-like_from-step-8].vhd
mv [vhd-name-you-like_from-step-8].vhd [uuid].vhd

11. Rescan SR
12. Attach VHD to existing VM or deploy new one
13. Get you files

wow. I am getting on with this in parallel. Thank you again! Results for both suggestions and requests are coming!

@damjank said in File restore not finding any option:

@olivierlambert roger! I am upgrading now an testing

SO I have upgraded to latest version of open source version of XO. I am currently at:

• xo-server 5.111.1

• xo-web 5.114.0

• build afadc - https://github.com/vatesfr/xen-orchestra/commit/afadc8f95adf741611d1f298dfe77cbf1f895231

• also latest version of backup proxy

I try the restore, same result, here is the complete log (from settings -> logs):

backupNg.importVmBackup
{
  "id": "70cc277b-7a40-4be1-b3bb-af6694d7fd77//xo-vm-backups/b7f3f3b4-bbd6-c2eb-06f2-31917ac7a1a0/20230129T030711Z.json",
  "settings": {
    "mapVdisSrs": {},
    "newMacAddresses": false
  },
  "sr": "11e5da06-7f76-2a74-3040-e66887d22844"
}
{
  "message": "Cannot read properties of undefined (reading 'id')",
  "name": "TypeError",
  "stack": "TypeError: Cannot read properties of undefined (reading 'id')
    at BackupNg.importVmBackupNg (file:///opt/xo/xo-builds/xen-orchestra-202304111128/packages/xo-server/src/xo-mixins/backups-ng/index.mjs:531:21)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202304111128/packages/xo-server/src/xo-mixins/api.mjs:401:20)"
}

0 julien-f committed to vatesfr/xen-orchestra

fix(read-chunk): better not enough data error message

@olivierlambert roger! I am upgrading now an testing

@olivierlambert I am on 53e0f (https://github.com/vatesfr/xen-orchestra/commit/53e0f17c55c2f023d1f852411ecaa703ba9a3927)

0 fbeauchamp committed to vatesfr/xen-orchestra

feat(xo-server): import multiple from ESXi (#6708)

@olivierlambert all my VMs have same disk size, inside VM I attach iSCSI drive - that drive is big but it is not part of the backup.
I use XO from sources. Both screenshots are from same backup job, just different sections - one from tick on the fail icon inside backup page and second is inside settings -> logs

@olivierlambert 30GB

@olivierlambert but as you can see, target SR has several hundred GB free, I also tried to restore on completely different host that has several terabytes free and I get same response..

@olivierlambert thx for that, i will. setup new backups accordingly.

But the existing backup, that I have done, a full backup, is completely failing to restore. If I try regular restore (destination is different host as the previous failed), all I get is this:

whereas:

so hosts SR definitely can host 30GB disk... but if I look into the log section in config:

So what now - I lost the backup forever, and I should just forget about the files? I tried to open the backup file, as suggested with 7zip, and all I get is the list of many thousands of files inside the XVA...

Any pointers would be greatly appreciated.

rgD

Hello.
I have full backups from VMs. I can restore the full VM, with no issues at all:

But I want actually, from that VM particularly, a few files only. They are in total a few hundred KB but they are super important. So I wanted to give file restore a try. Now there is no option at all, no option to select any full backup or anything:

So I am wondering - how to achieve that? Do I need to use some special backup option before I am able to do a file-based restore or am I missing something?

@olivierlambert Oh it was just released when I asked that is fantastic. So for vCPUs, I am good to go. The only question remains about hot-add RAM.
Any suggestions @lawrencesystems? Any upcoming video for this?

Hello. Maby a redundant question - I cannot find any reference on hot adding hardware support or option anywhere. For instance, I am trying to add more RAM to some VMs. Also, some of them would benefit from giving additional vCPUs. Any info about this? Is it possible, maby through CLI? Or currently not possible at all?

Thank you!
rgD

@pdonias thank you!

@olivierlambert and believe me, knowing suse this is not the end - I can download and install all of then and paste them here so that we catch them all and hopefully make them last

@olivierlambert @pdonias is there any option to also add openSUSE MicroOS? It is also missing an icon...
Details are here:

xe vm-param-list uuid=c5b75080-0689-6e5b-820f-e66b77149aff | grep distro
                            os-version (MRO): name: openSUSE MicroOS; uname: 6.2.6-1-default; distro: opensuse-microos; major: 20230319; minor: unknown

I used ./install.sh -d sles -m 15 to install tools...

Thank you!
regards
D