@stevewest15

I believe this issue was resolved when the health check system was changed to detect network connectivity at startup so it did not need to wait for then entire VM to boot. Needs the Xen tools to be installed. I have not had an issue since this change.

@olivierlambert

The server had high memory usage so I expect lots of paging, which could explain the block writes. I've increased the mem and want to see what difference that makes.

@olivierlambert

Results are in...

Four VMs migrated. Three using warm migration and all worked. 4th used straight migration and BSOD but worked after a reboot.

@olivierlambert

Thanks Oliver. We have used GFS with Veeam previously and will be a great addition.

@acebmxer

Perfect thanks. The issue is we have an IP address locked to that host so the router needs to live there. The host affinity looks like the correct solution.

Does host affinity also prevent the VM being migrated manually?

@Danp @DustinB @ph7

This host does not run any VMs, just used for CR

I've increased the dom0 ram to 4GB with no more alarms.

@dinhngtu

Thank you so much. If you want me I'll be at the pub.

@olivierlambert

We have successfully installed using:

rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/7/x86_64/zabbix-release-latest.el7.noarch.rpm
yum install zabbix-agent2 zabbix-agent2-plugin-* --enablerepo=base,updates

@BenjiReis

Worked perfectly. Thanks guys.

@olivierlambert

Thanks Oliver, lots to learn.

p.s. Congrats on the 8.3 launch.

@acebmxer

Perfect thanks. The issue is we have an IP address locked to that host so the router needs to live there. The host affinity looks like the correct solution.

Does host affinity also prevent the VM being migrated manually?

@ph7

When a rolling pool update is performed I imagine the VMs are moved off the host being updated to another host. When the update is completed are the VMs moved back again?

I ask as I have a VM that must run on a particular host.

@olivierlambert

Thank you. I never thought of using an automation. I'll look into that.

OVH does allow you to associate an additional IP with either a server or a vRack. We use vRack for the LAN so I think we can only associate the additional IP with the server.

We have recently implemented shared storage for VMs and they are now agile, this works well.

We have xcp-ng hosted on OVH Cloud and have "Additional IPs" for various VMs to allow external access.

In OVH the additional IPs are associated with a server (xcp-ng host) so if an agile VM is moved to another host the additional IP no longer connects. The only solution I have found is to move the additional IP to the new host when the VM is migrated. This is possible however a more seamless solution would be better.

Is there a better way to manage VM migration when the VM has an additional IP?

@ph7

To automatically update the hosts? I expect, to work, a host reboot would be required however how can this be automated if the host has running VMs?

@Danp @DustinB @ph7

This host does not run any VMs, just used for CR

I've increased the dom0 ram to 4GB with no more alarms.

When I check "Health" in XO everything appears fine but I do see a number of Alarms, problems is I have no idea what they mean. I do not think I have any system performance issues but am sure these should not be ignored.

HST150 is a host for disaster recovery using CR

@olivierlambert

Why did I not do this sooner

I have recently changed our setup to use FreeNAS shared storage for VMs. Now I have shared storage and two hosts I can move running VMs between hosts. This makes it easy to patch & restart a host by moving the VMs off it first.

As opposed to moving the VMs, I could schedule a maint windows and down the VMs then patch and reboot the host. In this scenario, if the host was to fail I expect nothing will be lost as the shared storage is independent. Then I can simple start the VMs on the remaining host, meaning there is no hard link between the host and VM.

Does this sound correct?

@stevewest15

I believe this issue was resolved when the health check system was changed to detect network connectivity at startup so it did not need to wait for then entire VM to boot. Needs the Xen tools to be installed. I have not had an issue since this change.