I'm only talking about copying, not live migration.
I have a pool on 8.2, I want to copy VMs to 8.3 and, if necessary, back to be able to run them both there and there.
As I understand it, just copying from 8.3 back to 8.2 in XOA does not work, but you need to create, for example, a CR and run it, then copying occurs. But after that, I can't start this VM on 8.2, I get an error
FAILED_TO_START_EMULATOR(OpaqueRef:61cd8d42-6dcd-4382-b41f-379129769a11, varstored, Daemon exited unexpectedly)
I still wanted to understand, is there anything wrong if I reboot from inside the VM not with XOA? Although it is written that when all shutdowns and reboots are enabled, they must be performed with XOA so that the system understands (although it is strange to me, if there is a guest-tool in the system, then XCP should understand everything that happens in the VM itself) or not?
And yet, is it possible to reboot from inside the VM itself? It will just reboot, in my opinion, HA won't even have time to work here, or even if it does, it will send a command to start the machine, but it will boot anyway
I have auto-reboot on which machines in the scheduler at night, it is necessary.
@olivierlambert
I also wanted to ask just about HA and auto reboot to VM
If HA is enabled on the VM
and auto reboot is enabled in the guest system
Then nothing bad should happen? Because there will be an attempt to start the VM, but it will reboot anyway and just start
@olivierlambert
I understood everything now what the problem was. HA is not included. As I understood it in this case, the VMs would be turned off automatically and not locked, right?
The only thing of course remains the question that dave.opc asked
@Andrew
I read this) that's why I wrote about the fact that you can not enable HA on each VM, but use this function only for automatic transfer of the master
Well, okay, you've strayed from the subject, we still have another problem...
@Andrew said in can't start vm after host disconnect:
I'll have to look into HA a little more and it's issues. It's simple to turn on, but has a few complications/consequences in normal use...
And which ones, for example? Can we just not enable it in the VM settings, then we will only have the master transfer functionality? I forgot that it doesn't work if HA is turned off)
But the rest of the situation when the machines are hanging on and nothing can be done with them is it still a bug? They should just turn off.
@Andrew Your situation is even worse. When your master disappeared, did you also lose control of the pool? Although the master should be transferred to another host automatically if it is unavailable for a long time? Why is this not happening? I didn't really understand when you deleted the host on which these VMs were running from the pool, after that your VMs started on the second host?
In general, it seems that these are very serious bugs, having a fault-tolerant system scheme, we essentially lose it because of this behavior.
@Danp said in can't start vm after host disconnect:
xensource.log
If you search for this error, which is also in XOA, then here is a piece that relates to this.
@Danp So I wrote 
The power supply is broken. Replaced, the server is working. He appeared again in the pool and these VMs began to start normally.
In which log exactly and what should I look for with such a problem?
@Danp In XOA, we only see this when starting the VM
SR_BACKEND_FAILURE_46(, The VDI is not available [opterr=['HOST_OFFLINE', 'OpaqueRef:03e275e3-56df-477d-b940-5ba78247ce2f']], )
The situation has now been resolved. We started this server, the power supply failed. But I would like to understand the situation in order to prevent such a situation in the future, because the server might not start at all...
as I understand it, is this still abnormal behavior of the system?
Otherwise, it turns out that we have backup servers and can quickly restore VM operation on them, but we cannot do this because of this lock, which we could not just remove...
@Danp Yes, I'm talking about the same situation, I'm also involved. Can you tell me what exactly and how to look at it?
So far, the situation is that we have lost all the virtual machines running on this host. They can't even be copied...
Do I understand correctly that the problem also occurs when exchanging a server with a shared NFS storage, where the VHDs are located, and not just between the VMs themselves? That is, the exchange of a virtual machine with disks attached to it on shared storage will be slowed down?
Is there any hope for a solution to this issue? How much do I understand this affects all generations?
@BenjiReis
Thanks )
But we really have already put 8.2 from iso on it with included fixes, which we gave in another topic.
Therefore, there is no way to check now.
While it was 8.3, I managed to conduct some tests.
Did I understand something wrong or is it quite possible that in some tasks 8.3 is significantly faster on the same hardware than 8.2?
From this ISO, the installation went fine
I will test further...
Thank you, I will try to check in the coming days
@stormi
This is a XOA machine on Ubuntu 22.04
@stormi
No is not enabled. I don 't use this option on any machines at all )