Topics created by mauzilla

@mauzilla There is no easy way to achieve that, it requires updating a number of other_config entries manually.

If you have a paid subscription, open a support ticket and I'll take care of it for you 🙂

You can try to "attach" broken VIF to some network and then delete it.
Try to use this command

xe vif-move

If that doesn't work, you can shut down the XO VM, detach the disk, deploy a new VM without a disk, attach the XO disk to the new VM.

works like a charm, thank you gents!

@dredge999 yeah in hindsight thats what I should have done 🙂 I wonder if I can restore the config files and have the VM operational again. It's more getting it to stop now without a host restart

@mauzilla I personally think having the CR job operate between 2 different pools is a better idea.

I am curious though, are these servers located in the same physical location? If so why not try going with high availability instead of a CR job? https://xen-orchestra.com/blog/xenserver-and-vm-high-availability/

I haven't really done HA setups with XCP-ng before, so can't really speak to how good it is. But IMO CR and other backup jobs like that are more meant for geo replication and stuff like that (i.e. a disaster recovery scenario with some offsite XCP-ng host). Which is why I'm asking about location, personally don't see the benefit to CR if in the same physical location, I'd be more interested in HA at that point.

This is just my two cents though.

Yes you can do that, there's a tag on a replicated VM to avoid being replicated again.

The XO team is also bringing the magic!

Even a fresh XOA without its configuration is able to "discover" and restore the backup. You'll just need to remember the backup repository share access.

@kevdog You can force a host to be ejected even if the host is not reachable any longer from the pool master using:
xe host-forget uuid=UUID
If there is any issue because VMs are thought to be running still on that host,
you may need to do a power state reset on such before you can get rid of that host.
See if that works for you.

You may want to review this thread.

@mauzilla In the past, I have run into this problem when introducing a new host into a pool and the primary management interface was picked up on the non-primary bond. To properly add a new host to a pool, only the primary management interface should be configured on the host and correspond to the subnet of the primary on the pool master. Just mentioning this because I ran into it before, even if it turns out not t pertain to your specific case.

Also, I have run into a host before - the exact same hardware as another - where one Ethernet NIC showed up in a different order than on the other server -- even though it was on the same card! I had to use the interface-rename application to switch it around and make it match.
Strange things happen.

@mauzilla The change will only apply at the next run, it will not impact any current run.

You can't add a host into another pool until it's "blank". It's hard to "merge" two pools together.

So first, migrate VMs to the destination, clean the host and THEN add it to the pool.

@mauzilla
Just an FYI, I have not tested the latest Scale 22.12 RC1 for performance but the previous versions of scale under some conditions was quite a bit slower. I have a video covering this topic here with the benchmarks and methodology used for testing.

https://youtu.be/BoiHHnBDg0E

haha that's exactly the purpose of the remote test button 😛 No grand mastery, just experience 😉

It's more a less that. In short, the new disk is created on both sides, and blocks mirrored on both sides.

First, the read only "parent" VDI with frozen blocks is copied, when it's done, the VM is briefly paused, the memory migrated to the destination and then unpaused on destination.

Consequently, only the blocks written during 11 hours will use space for new blocks on the source SR (and destination, since it's mirrored).

@mauzilla nevermind google to the rescue 🙂

@mauzilla To boot an ISO in a VM, you need to select "DVD" in the boot order, put it first, and hit "Save". Then boot the VM.

For ANY system (real or VM), you need boot it with the same type of bootstrap as it was installed to use. BIOS or UEFI. If you change the boot type then you have to make the OS ready to use the new/different settings (not just a VM problem).

If you created a Windows image from a working system that booted with UEFI then you have to copy ALL partitions (the whole disk), not just the C windows drive.

Weird… Can you remove the snapshot of the failing VM and try again to see if you still have the error?

To me it's like the delta capability on XCP-ng side is failing on a specific disk 🤔

@mauzilla You can copy the template to the new SR using XO.

Here's how --

Go to Home > Templates Select the desired template(s) using the checkbox Press the "Copy" button that appears in the header Complete the dialog