[ovirt-users] Re: [External] : Re: Cannot successfully import Windows vm to new ovirt deployment

virt-v2v identifies the MBR but it’s not able to mount :) was the VM properly shutdown on VMware when you did the export ? An alternative plan could be to: * extract the OVA content (by “tar” command) * convert the vdisk to qcow2 format (by qemu-img) * import the vdisk * create one new Windows VM and add the imported disk * try to boot :) ps: once the disk is imported you can also evaluate its status by presenting the same to an other VM (and there try to mount) Simon > On Oct 26, 2023, at 11:49 PM, Michaal Rutledge <netracerx(a)mac.com&gt; wrote: > > But previously, Tomas said that he could see where virt-v2v DID > properly identify the OS, so why is virt-v2v unable to determine how > to mount the disk to load the OS? Even during the import stage, it > properly identifies the partitions, so why is it failing is what I'm > not seeing. It boots in ESXi just fine, that's where the OVF was > exported from. Disk has no errors there. So I kinda need a little > more to go on here. Nice to know it can't mount the boot partition, > would be nicer to know WHY it can't mount the boot partition when it > boots in VMware without issue. Is there something that needs to be > done to the VM and it's OS drive before it's exported? > Michaal Rutledge > netracerx(a)mac.com > 972-896-4948 > On 10/26/2023 4:31 PM, Simon Coter wrote: >> It’s failing due to this error: >> >> import-75636d68-d067-4570-84b3-3829c5cf1963-20231026T153906.log:content: >> DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 >> "Invalid partition table" at offset 0x17b "Error loading operating >> system" at offset 0x19a "Missing operating system"; partition 1 : >> ID=0xee, start-CHS (0x0,0,2), end-CHS (0x1fb,254,63), startsector 1, >> 4294967295 sectors >> >> So, “virt-v2v” is not able to get your Windows-7 disk mounted to >> load the OS. >> >> Simon >> >>> On Oct 26, 2023, at 11:23 PM, Michaal R via Users <users(a)ovirt.org&gt; >>> wrote: >>> >>> Okay, it seems it got a bit further, but still errored out. I >>> watched it get past the disk import (or what looked like the disk >>> import), but I couldn't see in the vdsm.log file where it failed >>> the remaining import. I tried as both Other OS and as Linux (just >>> in case the latter had a chance), but still failures. There were >>> errors from vdsmd like "cannot lookup default selinux label for >>> /var/tmp/.guestfs-36/appliance.d/initrd" and some SELinux errors >>> with access control from qemu-kvm (the latter of which I ran the >>> fix scripts for as suggested by Cockpit). Below are the log file >>> links from this run. >>> >>> vdsm.log: >>> https://urldefense.com/v3/__https://www.dropbox.com/scl/fi/aylya0u16l55ef... >>> import log 1: >>> https://urldefense.com/v3/__https://www.dropbox.com/scl/fi/xuwslr1sz9lrvb... >>> import log 2: >>> https://urldefense.com/v3/__https://www.dropbox.com/scl/fi/yuimr3j0hwdpkz... >>> import log 3: >>> https://urldefense.com/v3/__https://www.dropbox.com/scl/fi/ipeol7uk00gimy... >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-leave(a)ovirt.org >>> Privacy Statement: >>> https://urldefense.com/v3/__https://www.ovirt.org/privacy-policy.html__;!... >>> oVirt Code of Conduct: >>> https://urldefense.com/v3/__https://www.ovirt.org/community/about/communi... >>> List Archives: >>> https://urldefense.com/v3/__https://lists.ovirt.org/archives/list/users@o... >> >