[ovirt-users] Re: Recovering from corrupted hosted-engine
And why did you loose your Linux VMs ? The disks are still there unless you lost storage domain . Also, the restore procedure of the hosted engine is straight forward. Best Regards,Strahil Nikolov OK. To bring this to a close... There were some casualties, but ultimately I was able to salvage a dozen or so virtual machines using the "qemu-img convert -O vmdk vmdiskfile vmdiskfile.vmdk" command. In case anyone else finds themself in a similar situation, this involved the following steps: 1) Give up on the hosted-engine. 2) SSH into RHEV and navigate to the VM storage domain. 3) Go into each UUID folder and run # qemu-img convert -O vmdk vmdiskfile vmdiskfile.vmdk 4) Secure-copy vmdiskfile_converted.vmdk to VMware. 5) SSH onto the VMware host. 6) Run # vmkfstool -i vmdiskfile.vmdk new_file_name.vmdk. 7) Attach new_file_name.vmdk to a new VM in VMware. Make sure "Firmware" is set to "BIOS", under Edit Settings > VM Options > Boot Options. 8) Boot the VMware VM, and Windows should automatically load and you should be good to start removing the RHEV-related VM tools and install the VMware tools. ** Note: Remember my situation involved migrating away from RHEV over to VMware. So, I really wasn't concerned about recovering the hosted-engine. And, prior the hosted-engine going down, in preparation to migration to VMware I had already removed all snapshots from all RHEV VMs. This all made what's below possible, and a lot easier. Also, these steps didn't always work. I was able to recover 75% of Windows VMs. Unfortunately, I experienced a 100% lost for Linux VMs. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YY7DIWFCOGKSOD2RLXR2AHAB5OMZGCBJ/ ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZPSMUWMUF6AZBSJXNNJP3LURFZDXXX7H/
[ovirt-users] Re: Recovering from corrupted hosted-engine
If anyone else runs into this issue, I've been able to recover one of the VMs using the "qemu-img convert -O vmdk vmdiskfile vmdiskfile.vmdk" command outlined in Howard Johnson's response linked below: https://access.redhat.com/discussions/881153 Tried the same actions on a Linux machine, but CentOS is not loading, throwing errors saying it can't find the /root or /boot partitions. I'm hopeful that I can at least salvage a few of the Windows VMs currently held hostage in RHEV. The UUID folder structure is hard to navigate for someone that doesn't know what he's looking at (i.e. me) so I'm likely to have mixed results. Other articles I've come across suggest that it should be possible to redeploy the hosted-engine and import the existing Storage Domain, and the VMs should reappear. I've not had success with this because I haven't been able to make "IP.Address:/path/to/storage/domain" accessible, which is likely what faulted the original hosted-engine. Now that I've nuked the original hosted-engine, I'm stuck down the path I've created for myself, either a) continuing with "qemu-img convert", or b) figuring how to to make "cd IP.Address:/path/to/storage/domain" stop saying: "No such file or directory". If anyone has any tips, that would be much appreciated. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZQUBTEKGV3VHPYZ47KQ5HSPB4P5C4C53/
[ovirt-users] Re: Recovering from corrupted hosted-engine
OK. To bring this to a close... There were some casualties, but ultimately I was able to salvage a dozen or so virtual machines using the "qemu-img convert -O vmdk vmdiskfile vmdiskfile.vmdk" command. In case anyone else finds themself in a similar situation, this involved the following steps: 1) Give up on the hosted-engine. 2) SSH into RHEV and navigate to the VM storage domain. 3) Go into each UUID folder and run # qemu-img convert -O vmdk vmdiskfile vmdiskfile.vmdk 4) Secure-copy vmdiskfile_converted.vmdk to VMware. 5) SSH onto the VMware host. 6) Run # vmkfstool -i vmdiskfile.vmdk new_file_name.vmdk. 7) Attach new_file_name.vmdk to a new VM in VMware. Make sure "Firmware" is set to "BIOS", under Edit Settings > VM Options > Boot Options. 8) Boot the VMware VM, and Windows should automatically load and you should be good to start removing the RHEV-related VM tools and install the VMware tools. ** Note: Remember my situation involved migrating away from RHEV over to VMware. So, I really wasn't concerned about recovering the hosted-engine. And, prior the hosted-engine going down, in preparation to migration to VMware I had already removed all snapshots from all RHEV VMs. This all made what's below possible, and a lot easier. Also, these steps didn't always work. I was able to recover 75% of Windows VMs. Unfortunately, I experienced a 100% lost for Linux VMs. ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/YY7DIWFCOGKSOD2RLXR2AHAB5OMZGCBJ/
