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?
@sid It seems I have to get my hands dirty and take a deeper look into Terraform / OpenTofu. I am not shure how well the other folks at work partially will have fun working with commandline versus the easy to use XO web GUI.
Tailoring down the CloudInit files used is not really the basic idea behind this. I was rather going the oposite way and install / configure the stuff we usually bake into our templates on the fly while generating the VM via CloudInit.
Thanks a lot for all the responses !
Hi Pechkin000,
Try this :
npm install url-loader
yarn install v1.22.11
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info fsevents@2.3.2: The platform "linux" is incompatible with this module.
info "fsevents@2.3.2" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@1.2.13: The platform "linux" is incompatible with this module.
info "fsevents@1.2.13" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
Done in 22.66s.
Just a quick FYI, XOA means "Xen Orchestra virtual Appliance" and it's only available via https://xen-orchestra.com or auto deploy. That's the only one with pro support
Okay so it's indeed a certificate issue on your side. Double check your certs. Sometimes, you need to have a cert file with the intermediate authority.
@jmccoy555 I updated both the XO deployments to current code just now. Both were the same BTW before.
one still asks for the SR on every migration. One does not.
[info] Updating xen-orchestra from '4bed8eb86' to '175be4482'
I would REALLY like to figure this out. Annoying.
Thanks
Tim
@olivierlambert Ok cool, iSCSI is on its own Network on a Direct connection with Multipathing. In the past i have had problems with VMs going in Read Only Mode.
Thanks for your reply.
That's the issue. Why they don't have it is the problem/mystery.
Try to check if new replicated VMs got it. If not, I would check if you are correctly up to date.
@joearnon The browser javascript logs may give you useful information about what issue happened during the import as seen from XO's side.
However the disappearing SR issue makes me think you should look at XCP-ng logs, in particular /var/log/SMLog for storage-related logs and /var/log/daemon.log.
@jsawyer77 Did you follow the documentation when building XO? If not, then what process did you use?
Also, check to see if libvhdi-utils is installed and which version.
