On Tue, 2018-10-02 at 10:11 +0200, Gionatan Danti wrote: > On 02/10/2018 09:19, Andrea Bolognani wrote: > > Your assessment looks correct, and the controller is indeed compiled > > out downstream. Filing a BZ sounds like a reasonable next step, but > > you might also want to investigate virt-v2v, which I believe will > > take care of switching to the more performant virtio-scsi (including > > installing the necessary drivers) for you when moving guests off > > VMware. > > Hi Andrea, thanks for the reply. > > From my understanding, virt-v2v use virt-win-reg to open the disk image > and install new drivers in the registry. I am doing a very similar thing > by manually using virt-win-reg to add the mergeide.reg file to enable > booting from any IDE controller. > > That said, both virt-v2v and manual virt-win-reg have a significant > shortcoming: when used on non-cleanly-shutdown images, the act of > opening the NTFS filesystem alters the journal/filesystem state. In one > planned lab test I found some file to be corrupted after running > virt-win-reg, and I traced back the cause to the unclean NTFS > shutdown/mounting. > > Adding a supported controller will prevent any issue: even with an > unclean shutdown, the machine will boot and replay its NTFS journal. If > needed, it can also run the proper Windows filesystem checking tool > (chkdsk) which is, as far I know, better positioned to correct any > filesystem problem. > > Am I missing something? I have very little knowledge of how virt-v2v achieves its goals and even less when it comes to running Windows guests, so I'm afraid I'm in no position to help you. I'd suggest asking on the libguestfs mailing list. -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
