I deleted backups of VMs I no longer need (Backups > Restore > Delete backups). No problems so far, but when I want to look at the backup data store, I noticed that there are still directory structures left behind that are associated with those deleted backups (though they are empty). It would be nice if those folders were also deleted so that there is less folders to worry about when creating off site backups.

@Forza Actually not all is lost. I have off site backups, so I could restore the backup target remote from it's off site backup.

I'm wondering if I power off XO, then restore the contents of the directory where my backup target remote points to, will XO then be able to see the old backups, before they were wiped? Or, will it be very confused because it's metadata is not stored on the remote but rather on the XO VM.

Hello, so I screwed up. I was playing with backups and I wanted to see if I can do a manual backup (triggered by me, no schedule). Well apparently this is not sported. I realized this after I deleted the schedule and the backup job would not save, saying I need a schedule. So I created a (default) schedule and then disabled it. I then manually triggered the backup to test this approach. Of course the backup went through just fine. Soon after I realized that I messed things up good. The default backup schedule defaults to only retaining one copy. My half a dozen previous backups have now been automatically removed. The problem is I need my first backup in case I want to start over working on my VM. Well, that gone now

I get that I caused this myself. I'm wondering if a function for manually triggered backups without deleting any previous backups can be added.

My use case is as follows. You start working on a new VM, you get the basic setup done. Now I want to be able to get back to this point at any time should the changes I make next not work out so I'd like to trigger a manual backup. Next few weeks are keeping me busy with other work. I finally come back to what I started earlier and continue my configuration. In the next few days I realize that what I have done is not going to work. At this point I would like to simply restore my first backup that already has the basic configuration done and I can go for attempt two.

I guess another way of saying this is I would like to tag certain backups as protected so that they will never be erased automatically to reclaim storage space. Does anyone agree that this would be useful?

Cheers.

@thenorthernlight Thanks! It appears I had two problems with the configuration I posted earlier that were causing the Test plugin to fail:

Use StartTLS should be off
User filter should be (userPrincipalName={{name}})

Now onto testing if actual AD logons are working.

Cheers.

I'm getting a lot of this message when examining output of dmesg. Would anyone know what this means?

I’m trying out XCP-ng 8.3. I moved a VM from a host running XCP-ng 8.2.1 to XCP-ng 8.3, that went just fine. Now I powered off the VM and I’m trying to move the VM back to the 8.2.1 host but I’m getting:

VM_HOST_INCOMPATIBLE_VERSION_MIGRATE

Is going back no supported?

@olivierlambert I just noticed this after I tried to export a large VM. The export did not complete, nothing was downloaded. Not sure if that's coincidence.

From source. Master, commit 636c8. As far as I know I don't have any scripts going.

I just noticed that about every second there is a new task popping up in the task pane and the number of items keeps increasing. Please see screen shot. Is this normal? This happens even right after rebooting xo. Is this just normal operation or is something stuck?

I have a host with 36 physical cores. On this system there will be two VMs running. Sometimes they will run one at a time, other times they will both be running simultaneously. Should I assign all 36 cores to both VMs so that each VM has access to all the cores when running on its own or will that cause horrible inefficiencies when both VMs are running and it’s better to assign 18 cores to each VM? The load will scale to as many cores as are available. Both VMs are running Windows. If I assign 18 cores to the VM and the VM is running on its own will this mean half of the CPU will be idle?

What about memory, can I over provision memory (assign the total amount of RAM to each VM) or is that no longer supported.

Any insight is appreciated.

I deleted backups of VMs I no longer need (Backups > Restore > Delete backups). No problems so far, but when I want to look at the backup data store, I noticed that there are still directory structures left behind that are associated with those deleted backups (though they are empty). It would be nice if those folders were also deleted so that there is less folders to worry about when creating off site backups.

@olivierlambert The issue started according when I attempted to do a restore of a backup. The restore failed and the rogue tasks started to happen. I waited a few days until a new Xen commit was available, I updated Xen and tried the restore again. This time the restore was successful but the tasks kept coming. I waited some more, updated Xen (today) and the failing tasks are continuing. I noticed that there are some patches available for the hosts. I applied those, rebooted the hosts but unfortunately the tasks are still coming.

@Danp Hello again. I just updated Xen to commit 42dc7. The problem is still occurring

@Danp said in Backup Restore is Stuck:

@Kajetan321 I've seen this exact behavior on a client's site, but it isn't occurring on my local install. This will hopefully be fixed soon.

Are your VM restores working correctly now?

I just tried to do the same restore that caused the initial problem. The restore worked correctly. So it looks like my restores are working.