Download Windows 10 Qcow2 Image
Alexander Rodriguez
Now insert a USB stick to your Linux system, make note of its /dev/sd* device name, and run virt-p2v-make-disk to create a bootable virt-p2v environment, from which you will later boot the Windows machine. (Or see the man page for other options for creating the bootable image.)
I use an unassigned SSD to store/run my 10GB docker image and also a 50GB Windows VM. I picked 50GB originally just because I had the room, but now I'm wanting to install another VM on the same drive, and I don't have enough room to do so. I have almost 20GB of free space on the current windows install, so there's plenty of room available, but I dont' know if I can, nor how to shrink the qcow image.
If it's not possible, could I just copy the VM and docker images onto the array, then format/clear/wipe the SSD, then recreate the images but smaller? If so, is there a guide for doing this? I hate to screw up my otherwise good Windows VM.
It seems like there might be 2 separate things I need to do then. The first one is to make the image smaller, using the steps just above, then use the qemu-img resize command to make the allocation smaller.
Personally, id trust gparted more than windows to resize the partition prior to resizing the qcow file. gparted will move any data that needs to move as part of the partition resize operation. no need to do any defrag etc inside windows.
Well, I haven't had much luck with this, plus I want to upgrade my windows 8 to windows 10, and the 3 times I've tried to update from within the VM, all efforts have failed, so I can't even upgrade my windows install.
Upload your qcow2 image to the qcow2 Datastore you just made above:
Screen Shot 2016-02-25 at 12.43.23 PM.png19361150 56.5 KB
Also, add these attributes:
DEV_PREFIXvd # this is to kick in virtio drivers
DRIVERqcow2 # this is to tell opennebula which transfer driver to use, by default its ssh i think. Set everything else to default.
My question is about to resize the qcow2 VM image.I have a image with packages and applications built in.For example when creating the image, the size is 40G, but for now it in reality use about 5G disk space. So i would like to shrink it.
If your guest OS is windows, you can expand the partition from within the guest, while it is booted. First copy your original image (for safety) and use qemu-img resize to add space to the disk image:
If sysprep still fails, you can check the log file c:\Windows\System32\sysprep\Panther\setuperr.log. The most probable error is the installation of some applications or updates in language files. In case you find anything like Error SYSPRP Package XXX was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image this is your case.
If anything goes as described in this tutorial, VirtualBox should have shut down your VM at the end of the previous step, and you should be ready to transfer the virtual disk to your OpenStack deployment. In my case, the name for the disk is windows10foropenstack.qcow.
My advice is to change the format from qcow to qcow2. This is because OpenStack uses the command file to get the format of the file that contains the disk and then forces qemu-img to use that format instead of leaving qemu-img to deal with the file. That makes that, if it is needed to convert the file at a further time, such conversion may fail because some versions of qemu-img believe that they cannot deal with qcow format (which is different from qcow).
In my case, I am setting hw_cpu_max_sockets to 2 at the image level so that OpenStack will calculate the other values. Moreover, as my disk is 60Gb, I am setting the minimum size for the disk to that value, just to make sure that Windows can run. The command in the CLI would be similar to this one: openstack image set 93f656a8-529d-41a1-9f92-96983e7d47bb --min-disk 60 --property hw_cpu_max_sockets=2.
Now you need to instruct OpenStack to use UEFI with your image, which is done by setting metadata variable hw_firmware_type to uefi. In the CLI, the command is similar to this one: openstack image set 93f656a8-529d-41a1-9f92-96983e7d47bb --property hw_firmware_type=uefi.
Go to Windows Features and tick Windows Hypervisor Platform. After that, restart the computer and type this command in the powershell (in the directory where the image and .iso resides): qemu-system-x86_64 -accel whpx -hda .\[name].qcow2 -m 512 -net nic,model=virtio -net user -cdrom .\[name].iso -vga std -boot strict=on. It should start up and you can proceed to install the OS.
I would create backup image with Macrium Reflect and try to restore the backup image in there. I know that this somehow works in VirtualBox, because I once did something like this before (however, cannot remember much of the details)
I googled and I found that the only real way to fix windows boot is to download windows, and run an upgrade on the current windows system.so I did that, I downloaded the ISO, booted it on virt-manager but I could not upgrade, it failed to detect a previous windows installation on the drive.
The failure that I had with that is that the current drive is divided to UEFI, Windows and data partitions and it gave me an error that it could not install Windows on the partition that the previous Windows installation existed it, then I mounted the qcow2 image of the main drive, deleted all the partition table, reinstalled Windows on that drive while allowing the Windows installation to re-partition the drive automatically and then to replace the files, but after replacing the files Windows did not boot again and showed exactly the same symptoms.
So I created a new Windows 10 VM with Q35 Chipset and Firmware UEFI x86_64: /usr/share/qemu/edk2-x86_64-code.fd created 2 SATA drives and pointed them to the original VHDX files instead of converting it to qcow2 first, and allowed to boot from all drives and set the CDROM to boot from first.
First I booted with Linux Gentoo mini CD just to confirm that the drives are readable from the VHDX files and they are not, so I re-created the qcow2 files, booted from Gentoo Linux and the drives where readable. (For some reason I thought that QEMU supports VHDX out of the box).
I am trying to use cloudbase windows 2012 image on Kubevirt that is running on top of Openshift based Kubernetes cluster. Since Kubevirt supports only .qcow2 and .img format, I had to use gunzip to uncompress the .gz file available on your website. Unfortunately that uncompressed image (in .qcow2 format) doesn't work and fails with below kind of EOF message. Since there is no direct URL to wget this image on my Linux server, I am downloading it on windows desktop and transferring it in binary mode using winzip and then uncompressing it using gunzip.
You might encounter an issue with the size of the volume where you want to import the image. Make sure you have defined a large enough storage volume. The decompressed image size is around 16GB. Please set at least 20Gi (20 GigaBytes) to be on the safe side.
I have a windows 7 guest created using KVM on Red hat linux and I'd like to use it on Fusion or workstation (preferably fusion). Is that possible? If not can you point me to another program that will run the image on Mac or Windows? I have fusion 5 and the image is a qcow2 file. Thanks.
Questions regarding using KVM qcow2 images with VMware products have already been asked and answered before and a search of the forums and or Google have the answer to your question! You need to convert qcow2 to vmdk or if you still have it running try using VMware vCenter Converter Standalone installed under Windows 7.
Well I no longer have access to the linux laptop so I can no longer run the image hence the reason why I created this thread. That means that I can't use the converter correct? Without a linux system or Vmware server what can I do?
The qemu-img command is what you use to convert the image and there are plenty of examples already on the Internet, as well Wil also already posted one in this thread, and a further search of Google will yield even more. Once installed then in a Terminal you should be able to type man qemu-img for its man page.
Trying without the -f qcow2 the command ran and created the vmdk file but stopped after about 15 minutes. The new image is about 4 mb and nothing is on it. Trying to boot it I got OS not found. When attaching it to another Windows VM the disk shows up as unallocated space in disk management.
That sounds like from the Terminal prompt you are not in the directory that contains the .qcow2 file. In other words if the .qcow2 file is not in the current working directory you need to include its fully qualified pathname.
The qemu-img program should be able to determine its a qcow2 image without using -f qcow2 however I personally would not omit it. Looking at the size of the .qcow2 image, and I'd assume it's more then 5 GB, why would you even waste time messing with a 4 MB .vmdk file as there isn't going to be anything of worth being so small in comparison to the source size!? The source and converted file should be about the same size.
That said if your doing this through a VMware Shared Folder then personally I would not do it! I'd instead copy the .qcow2 file to the VM's filesystem or external USB connected then to the VM and that's properly formatted for Linux to read/write to the volume. I just do not like the VMware Shared Folders feature, just have has to many issues over the years with it for my liking, and almost always use some other method especially when large files are involved.
Woddyz I had performed a cd to the directory. Following your advise I tried on the usb drive with the same error then I figured out how to access the original file and converted that. I don't think that the image was copying properly and was causing that error. Now it is converted and functional. Thanks for your help.
df19127ead