Capturing a [live] Windows system while it is running has become trivial with Volume Shadow Copy and Disk2vhd. As long as the Volume Shadow Copy is checked it can even store the captured volume images on one of the disks that is "itself " being captured.
The only restrictions being that VHD is specifically intended for use with Windows 2008r2 or earlier and has a final VHD size limit of 127 GB. That does not not mean the total potential storage space of its contents must be less than 127 GB. You [can] capture a 149 GB disk or partition as long as the resulting VHD does not end up more than 127 GB VHD size limit.
VHDx is specifically for Windows 2012 or above, but Windows 2012 also has tools for backwards converting a VHDx to a VHD as long the resulting VHD does not end up more the 127 GB VHD size limit. VHDx supports up to 64 TB volumes, but partitioning schemes and file systems inside those volumes may have to be divided up into, smaller sizes than the total Volume limiting them something to less than 64 TB. For example an MBR is practically limited to 2 TB. A GPT has larger size limits. But the file system put into those partitions may have their own size limitations.
Once it is in the VHD format, converting it to a RAW image which KVM can use will require a tool.
The traditional qemu-img tool "could be used"
qemu-img
convert -f vpc -O raw \
/kvm/images/disk/disk.vhd \
/kvm/images/disk/disk.img
however earlier editions of this tool had bugs when working with large VHD files which can result in unusable RAW files.. If you use qemu-img to perform the format conversion, be sure to test the RAW format volume as soon after the conversion as possible to avoid potential data loss from assuming the volume is usable.
Another tool is the free Starwind V2V image Converter
it actually supports many formats, and helpfully calculates the resulting image size after a conversion. (remember that 127 GB VHD size limit? this tool will warn you if you cross it)
One thing to be "aware of " is that VPC - or "Virtual PC" is a synonym for the VHD file format. So wherever you see Virtual PC mentioned they are referring to the VHD format when speaking about storage.
note: this tool does not support the VHDx format
RAW volumes are not growable or expandable and converting to this format will result in a larger on disk file system object than the original.
Once this is done getting the raw image file from the Windows system to a Linux host or storage server can be done from Windows 2008r2 by installing the [Services for Network File System] [Role].
And the RSAT [Service for Network File System Tools][Feature]
Then "Start" the NFS client service
Then "Mount" the Linux NFS share
And copy the raw image file from the Windows system to the Linux host or storage system
Additional details might include setting up the Linux exports to
1. allow the IP address of the Windows server to mount the exported share
2. allow no_root_squash such that an anonymous user can read write from that Windows server
3. Set a Windows registry setting to map the Windows "pseudo UID and GID" for the Anonymous user if not using AD user mapping (it defaults to -2 and -2, somewhat like Mr. Nobody and the Root Squash problems.. but enough about errant vegetables..)
4. if your Linux KVM system is using the luci and rcci clustering solutions, you will need to login to the luci web control and configuration for the cluster - then add a new nfs client "resource" - then add that newly created "nfs client resource" as a [child] to your cluster "nfsexports" service
5. any "Error 53" messages from Windows will indicate "path not found or resolved" which - might be true - but its the bit bucket for errors, it could mean many things, like simply "Access Denied" because the exports file does not have a pattern to grant access to the Windows server IP address, or the permissions for Anonymous mounting from that IP address, or the UID/GID is unknown - any problems reading/writing after mounting are likely due to no_root_squash or the automatic assumption that UID/GID "0" should be treated at the 65536 "nobody" user with few permissions (there are not a lot of logs or diagnostics for nfs on the Windows or Linux, since Linux will often default to "NFS3" and uses UDP which isn't very chatty about problems.. "NFS4" has even more advanced "issues" but might offer a performance boost if you have the experience to get it working properly, changing up the read/write buffers on the mount options from Windows for the nfs mount might be a more efficient use of time. You can also capture the traffic with wireshark and let it decode the nfs data packets to gleen useful information from the nfs protocol error messages.