Windows 7 Qcow2 File
Bran Cardello
What is "better" for such a gaming VM? `raw` or `qcow2` as vdisc? From what I read, raw should be faster (more performance) then qcow2. In older benchmarks this is truly visible, but in newer qcow2 versions this seems to have only an impact of up to 5% or even less. And are 5% that bad in order not to have such big raw images lying around when not even half of them are really used?
So my question here: Is raw really better than qcow2 in UnRAID 6.9.0-beta30? And if so, what does "better" mean? (faster vm in general, better read/write performance and how much, ...)
If you install with iso file, you can refer to the instructions in this link. In our article, using the available qcow2 file is much simpler. You can read the article combined with watching the video at the end of the article to do it faster and more accurately.
By default, opening a console window uses the vnc protocol. You can choose another protocols in the options when adding a new node. If use vnc, you can download TightVNC or UltraVNC Viewer. In our lab, we use both applications.
I've a Windows 7 VM, with a 100 GB virtual drive size. Initially, this VDD spent 40 GB on the host storage. Once it's zeroized, the VDD eats for real 100 GB on the host. And qemu-img -c ... creates a 91 GB, which is not at all what I expected.
Thanks to @dyasny, I made a small test with virt-sparsity. I cleaned up the W7 VM disk, disable hibernation, so the VDD only consumes 20 GB. Degraded the disk again, and ran again sdelete -z. Running virt-sparsity with the --compress flag gives a 80 GB virtual drive. Far from what I would have hoped.
EDIT-2016-02-16:"Refreshing" this question because the method to shrink a VM discussed here is very efficient but has a major drawback: it deletes all VM snapshots. If someone knows how to shrink a VM while preserving snapshots, feel free to share!
To shrink a Windows Guest OS, you have to shrink the partition inside the guest, shutdown the VM, create a new smaller disk of the desired size, copy the data from the old disk to the new smaller disk, swap the disk names and reboot the VM.
In this step, we'll just reduce our windows partitions directly from Windows. The resulting disk image at the end of this step will be the sum of the boot partition, the C: drive (reduced) and a leftover unused space that we will delete (by not copying it over to a new disk).
The procedure is not really a shrinkage, but instead we're going to create a new disk (of the final size) in which we will copy the two partitions from the original disk, and skip carrying over the unused space.
The goal is to create a disk whose total size = boot partition + C: partition. We'll also end up with some tiny leftover space (unless your math was perfect) not to worry about because we'll deal with in the last step.
Notice that we have /dev/sda1 which is our windows boot partition of 350 MB, /dev/sda2 which is our C: partition of now 34 GB and that the total disk image /dev/sda/ is of 100 G leaving us with a bunch of space to trim.
Notice the tool found the surplus of space... recall the comments about Math... So you can cancel that and recreate the disk or just move on as we do here and expand the sda2 partition as is done on STEP 3.
I finally managed to really shrink the VM space. At the beginning, the W7 VM ate 107 GB on the host storage. The virtual HDD size is 100 GB and currently, the VM only eats 18 GB of its virtual storage.
When you run qemu-img -c, you compress the image, which, while being able to reduce some space, can really hurt performance. If you want to deduplicate the zeroes on the disk, you need to run qemu-img convert, basically as if you're trying to convert the image from one format to another (even if the src and dst formats are the same).
You just need to "hole punch" or "sparsify" the empty space. To do that, you need the space to contain only 0's and holes. A filesystem's "empty space" is just unallocated, but may contain old junk data, not 0's. So the first step is to zero it. There are tools to do that, but here's an easy minimal way to do it...
Punch holes. There are a few ways to do this... here is a fast way, using a python script. First stop the vm, then run the script on the disk file(s). If it's a qcow2 file or another format, it should work the same, but there might be something I am forgetting, or simply an easier way.
And be aware that a hole is not allocated, so the file is not all in one place; the filesystem may become fragmented, hurting performance. This should not be in any way noticable on typical Linux/UNIX filesystems unless you were very low on space while writing files, but just be aware of the possibility. It is recommended to keep at least 10% free space to avoid fragmentation.
Also, there are tools that do other things too... like zeroing only the non-zero empty space (so they don't grow before you punch holes), zeroing swap too, doing it while online (probably requires hypervisor support), etc.. I tried these ways and found they all were terribly unreliable, sometimes barely shrinking 5% as much as manually zeroing it does, so I won't even bother listing the tools; others can list their favorites.
You may want to disable System Restore or delete any existing volume shadow copies in the VM disk. That alone can take up lots of space, and will appear hidden to the filesystem. Then run sdelete and zero out the free space, after a vm reboot.
Recently I had an assignment that asked us to use Qemu. It took me some trouble to get it running on Windows so I thought I could document it here in case I need it in the future. It would be nice if this helps someone, too!
Click here to download Qemu and download your desired .iso file. After installing Qemu, open Windows Powershell and type qemu-img. Now you might see that it does not recognize the command. This takes us to number 2.
Copy the Qemu path (should be C:\Program Files\qemu if you didn't change anything) and open environment variables settings by Right click on "This PC" -> Properties -> Advanced system settings -> Environment Variables.
Click on path once and click "Edit...". Click "New" and paste the Qemu path.
For Windows, there are two options: HAXM and whpx. Note that HAXM can only be used on Windows Enterprise/Pro/Education so I'm not going to introduce it here. Although I did get it working for whatever reason and after a Windows update, it just stopped working.?
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.
The second time you start up the machine you don't need to type -cdrom anymore. Just qemu-system-x86_64 -accel whpx -hda .\[name].qcow2 -m 512 -net nic,model=virtio -net user -vga std -boot strict=on should do it.
You might get stuck when rebooting after installing the OS
My friend and I both encountered the problem and we both used Ubuntu 16.04 for the VM. Just close the window and restart it and it should work fine. Pretty sure this is not best practice, though.
You can't seem to do migration using whpx
I got this error when trying to do migration. I found this Github code and I think it has something to do with whpx. I'm not sure how to resolve this. My TA simply allowed me to do migration on the server.
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:
Manipulating only from the host side, may leave the guest file system corrupted.Thus, before any changes from the host you need to change the VM's storage partitions sizes with partitioning tools like gparted from inside of the guest. So that the total size of the virtual disk becomes less than desired size of the virtual storage. After that, you can do converting and resizing and converting back the virtual storage file from the host.
Ok, thanks for the follow up. If they possibly think they need the windows desktop for a specific app is mostly what I was curious about on the chance we provided that app for use already as an interactive app.
where the context variables are formed as usual using form.yml and the qemu-wrapper-ood is a script that contains the logic to run qemu on the basis of what the user requested in the submission form, for instance
I just started using qemu now but the options I have with RHEL 8 are not the same as what was given by Leonado. The qemu-system-x86_64 is replaced by qemu-kvm. I can get a windows desktop running inside of an xfce interactive desktop using virt-manager but I would like to know how to use the qemu-kvm to start the windows desktop without the RHEL8 interactive desktop. Does anyone have any insight into converting what Leonardo has here with the equivalent in qemu-kvm? I can come close but the display elements are for the virt-manager viewer and not with gtk.
It seems that the gtk display is not available with the RHEL 8 version of qemu-kvm so I will have to use the spice display agent just like the virt-manager app does when it sets up a vm but I have not been able to do that even after starting up the vdagentd on a server to create a display for the Windows Desktop.
Hi @rsand, perhaps you can try installing the pkg qemu-ui-gtk available in the Raven Extra third-party repo (Raven's RPM packages repository). That package provides the additional GTK UI for QEMU and should make the -display gtk available to your qemu-kvm I think. Note though that Raven is not an official repository and comes with no warranty. Alternatively, please take a look at the official fedora repos which usually have more pkgs than rhel including qemu-ui-gtk.
c80f0f1006