@olivierlambert The update has fixed it, thanks!

@olivierlambert Thanks for your reply. I gather that it's supposed to "just work" when I add the tag to the VM?

We are not on the latest commit, so I will try updating our XO and see.

Edit: Fixed by updating to latest version.

Hi, I'm using XO community edition.

I have a DR backup task and a Delta Backup task successfully running in "smart mode" on all VMs tagged "production".

Recently, I've added the "production" tag to a new VM. When I click "Sample of matching VMs" in the DR task, the new VM shows up as part of the list.

However, there's no backups of this new VM, nor is there a corresponding VM on the DR server, unlike all the other VMs with the tag.

I have tried editing and then saving the Backup and DR tasks, in the hope that it will pick up the new VM at that point, but no luck.

Is there something additional that I need to do, to add the new VM into the DR / Backup tasks?

@jaayb Amazing, TYSM!

@olivierlambert I think the other commenter put it nicely - we are using snapshots a little bit like version control for the VMs. One of the things we use VMs for is to build golden images for desktop PCs, so maybe that's an unusual use case...

Putting aside how it works under the hood, it's also a GUI thing - it's a nice way to view and organize past versions of the VM, by having a list inside the VM's snapshots tab. It would be messier and less clear if they were separate VMs in the main list or exported XVAs.

Not being able to backup and restore the snapshots list is a little bit like losing our version control if a disaster happened to XO. I guess we'll have to stop using this feature in this way, or make more effort to manually export the snapshots we really need to back up.

Also, can you please confirm / deny what the previous commenter (gsrfan01) said? Is there a performance reduction when having snapshots on a VM's list?

@olivierlambert Thanks for the reply.

Hmm, we use snapshots as a specific record of certain named changes to our VMs, which we sometimes need to revert back to. Eg. (1) Base OS (2) Drivers and Apps installed (3) Prior to OS update (4) Post OS update, etc. Retention based on dates doesn't quite cover our use case.

There doesn't seem to be a way to backup a snapshot via the regular backup system, the only way is to export as XVA or copy it into its own VM entry?

Is there any way to populate the snapshots tab of a VM with exported / copied snapshots?

In VirtualBox, snapshots are a series of differencing images that only consume enough HD space to record changes. Is this not the case with XCP / XO? Is each snapshot a full standalone copy of the VM?

@olivierlambert Going back to my original question, I have a VM in XO with a few snapshots in its snapshot tab.

Is there a way to backup and restore the VM, such that everything is the same as before the backup (ie. a VM in XO with those particular snapshots in its snapshot tab.)

I'm struggling to express myself more clearly than this, is it clear what I'm trying to ask? I want the snapshots to be backed up and restored along with the VM, so everything appears the same as the original in the XO GUI.

@olivierlambert Hi, I finally got around to testing this.

• In XO, I go to the "Backup" section, and out of the backup types, I choose "Backup".

• I select my NAS as the destination remote.

• I choose a VM that has snapshots.

• I select Create and manually run the backup. After its done:

• I go to the Backup section in XO and select "Restore".

• I choose the VM I just backed up, and select the "Full" backup to restore.

• I restore to another host.

• Looking at the restored VM on the new host, there is nothing in the snapshots section.

Is this supposed to work? Am I doing something wrong?

Thanks

Hi, is there any way to make a backup (or copy) of a VM, with all of its snapshots included as well?

Such that when you restore (or view its copy) the snapshot list is preserved exactly?

I came across this post in a google search.

"xe vm-param-cleaner" mentioned earlier doesnt seem to exist anymore. However the following command worked for me:

xe vm-param-clear uuid=<vm_uuid> param-name=blocked-operations

Hi, yesterday I got myself into a silly predicament when the VM I was using to run Xen Orchestra got stuck during its shutdown. It had been set to block accidental shutdowns, so I was unable to force shutdown using XCP-NG Centre, or the regular shutdown command on CLI. As far as I can tell, XCP-NG Centre is unable to toggle the "protect from accidental shutdown" setting, so I was pretty much stuck.

Google search turned up this thread:
https://xcp-ng.org/forum/topic/3885/cli-ssh-delete-vms-that-were-set-as-protect-from-accidental-deletion-in-xo

There's a post in there that mentioned "xe vm-param-cleaner", but that command doesnt exist.

As a guess, I tried this command instead, and it was able to clear the setting so I could do a force shutdown from command line:

xe vm-param-clear uuid=<vm_uuid> param-name=blocked-operations

Just posting this as a reference for future generations.

Maybe there should be a CLI command for "really force shutdown like I really really mean it", that ignores the "Protect" setting? With a confirmation prompt or something?

@fohdeesha Great, thank you!

@fohdeesha

Thanks for the reply. It truly sounds like the easiest and simplest solution is to require the admin to manually enter the required MAC address before booting the backup VM.

Just a question about MAC addresses, in XCP-NG and its underlying technologies, are there any restrictions on valid MAC addresses? I mean over and above the IEEE standard.

I'd like to specify some easy to type and remember mac addresses for my VMs. From reading the wikipedia article and other articles, it seems like something like 02-11-11-11-11-11, 02-22-22-22-22-22, etc would be valid? As long as I have 02 at the beginning?

Is there a range of MAC addresses where I can guarantee won't collide with the automatically generated ones? Do you have any advice on a nicely human-readable set of MAC addresses I can use? I only need a range of about 10 in total...

@auspugs

Hmm, so are you saying to have the VMs already existing on the backup site, and when we do the DR backup we only copy the VHD file to a SMB share?

When we need to boot the VM, we'd have to copy the VHD file to the host backup machine, replacing the one attached to the VM at the time?

That sounds more complex than just typing the MAC address before starting the backup VM, though. And I'm not sure if it's possible to use XO's DR backup feature to copy the VHD files only...

@auspugs

Thanks for the reply. Our setup isn't that fancy so probably ok to talk about it.

We're just doing a simple "Disaster Recovery Backup" from XO Community Edition, every night from the primary to backup site. Our data isn't so crucial so the loss of part of a day is ok. We are not using Active Directory. The VMs are stored on internal harddrives on each host.

When the primary site goes down, we make a fast clone of the DR backups in the backup site, and then start the VMs. We contact our network admin, who moves the VLAN over to the backup site, redirects external IPs etc.

The level of sysadmin knowledge is not high in my organisation (although I am a programmer, at least) so I don't want to introduce anything too complex in case I am not around.

Does XO allow us to run a script after the DR backup process? Am I able to set the MAC address on the backup VM directly? When we fast clone the DR backup to boot the VMs, can the fast clone operation be set to preserve the Mac address? Or automatically run a script to do so?

I'm trying to avoid the situation where our DR procedure requires staff to manually set the IP addresses in the VMs, or the MAC addresses in the XO / XCP Centre interface. But worst case it's possible, I guess.

Hi, we are running two XCP-NG hosts on two different locations. One site backs up to the 2nd site for disaster recovery. Our network admin has created a VLAN for us, which all the VMs are configured to access.

In the event of a failure in the primary site, the network admin will move the VLAN over to the 2nd site, and we should theoretically be able to make a copy of the DR-ed VMs, start them up, and they should keep the same static IP address and start working without realizing they are on a different host.

However, in practice there seems to be a problem. When the VMs are started on the 2nd host, they detect it as a new ethernet network, and lose their static IP addresses. On Linux, this seems to be related to the fact that the copied VM has a different MAC address. On Windows Server 2019, this seems to be related to the Network Location Awareness service. I'm not sure what triggers it to recognise a new network.

I am investigating ways to disable this functionality on the OS level, but I want to approach it from the XCP side as well in case no solution can be found on the OS side.

One idea is to stop using static IP addresses, and instead use DHCP to bind a fixed IP address to a VM's MAC address. However, is there any way to configure XO or XCP to preserve the same MAC address when copying a VM?

There's also something like this:
https://www.groovypost.com/howto/change-mac-address-windows-10-why/

However, the setting "Locally Administered Address" doesn't exist in the advanced properties of the "XCP-ng PV Network Device".

Any other ideas or suggestions would be much appreciated, thanks!

Hi, using the functionality available in XO, is it possible to create a virtual network (using New > Network in XO), that allows VMs on that network to access other local addresses (eg. a NAS on a different machine on the same LAN as the host machine), but has no access to the internet?

Or is this only possible with external equipment like changing settings on our router or setting up a dedicated firewall?

I'm a bit of a beginner when it comes to VLANs and enterprise level networking concepts, sorry.

Basically I'd like to be able to set up a XO virtual network that my VMs can assigned to by default, that will block their internet access but still allow access to our NAS and other stuff on our LAN. Without needing to configure anything extra on the guest OS.

@tony I guess that's not too hard. I created another remote just for this backup, seems to be working fine, thanks.

@julien-f Thanks for the reply. What do you mean by "restoring the XO Config"? I restored our metadata backup, what further steps do I need to do?

@olivierlambert Thanks for the reply. I just gave it a try, and it's very hard to find where the backup XVA actually ends up. It's mixed up with all the other backups, each in a folder named with ID codes that don't seem to correspond with anything visible in the XO interface.

Apart from creating a seperate target remote exclusively for this backup, is there a way of finding out (or specifying) which folder the XVA backup will go to?