Weekend with Qemu
Welcome, Guest.
"When tyranny becomes law, rebellion becomes duty." -Thomas Jefferson

Author Topic: Weekend with Qemu  (Read 620 times)

Offline Spatry

  • Benevolent Dictator
  • Administrator - Sysop
  • **********
  • Posts: 5839
  • Cup of Linux Founder
    • Cup of Linux
Weekend with Qemu
« on: July 26, 2020, 04:12:35 PM »
As stated in Off Topic, I wanted to spend some time with Qemu-kvm this weekend. I can say that the hype is true, The performance is amazing I tried 2 front ends and my choices were Virt-Manager (redhat) and gnome-boxes.

In my experiment, I wanted to run a Windows 7 virtual machine for running game modding tools. I was pleasantly surprised by the speed. The only caveat is folder sharing. Virt-manager does not support this unless you do a samba file share. Gnome boxes on the other hand DOES once spice is properly installed but the latency (i/o errors) in the shared filesystem is unforgivable. The mod software I use must read a shared folder which contains a WINE installed game on my Linux SSD.

Qemu definitely looks promising... I need to spend more time learning how to optimize file sharing with my VM before I can kick Virtualbox and VMware to the curb. Definitely a great option for testing other Linux operating systems though so Qemu is a nice addition for that purpose... MORE TO FOLLOW =D
Windows assumes the user is an idiot... Linux DEMANDS Proof!

Offline CwF

  • Elite Member
  • *****
  • Posts: 474
Re: Weekend with Qemu
« Reply #1 on: July 26, 2020, 05:29:45 PM »
There are some kludges for file sharing, and I don't like setting up a samba server either.

One heavy simple way is to run another instance of some windows OS to do be the samba server. If you set things up carefully with image layering, you could run two instances of a common windows image - that could take some explaining.

An easy shortcut is to use a usb thumb drive of some kind and pass it around with usb redirect.
More advanced is to make the usb drive a virtual one and pass it around - nothing more than a qcow2 image that can be mounted to the vm. This can be done 'live', and can be attached to faster buses like an emulated sata.

Don't forget you can drag-n-drop any file from the host 'onto' the vm desktop without any file sharing, a function of the spice channel. And if you have memory to burn, you can have a ramdrive on windows for a temp shared directory on the single windows instance. The host can always access the windows shares, so you can load the windows share from the host, you just can't call in from the guest.

You can pull things off the vm with a --read-only guestmount on the host.

Or- we wait for configs with qemu 4.2+ and kernel 5.4+ to offer virtiofs, then hope for a windows driver that will likely be Win10+ only if ever - but then the host can virtiofs share with a lite linux guest that does a samba relay temporarily...

I've become somewhat literate in qemu magic!

Offline Spatry

  • Benevolent Dictator
  • Administrator - Sysop
  • **********
  • Posts: 5839
  • Cup of Linux Founder
    • Cup of Linux
Re: Weekend with Qemu
« Reply #2 on: July 27, 2020, 12:59:49 AM »
It is not feasible to use usb with qemu for the file share as the game is over 40gigs. Right now I am using VMware for running the game modding tools. When I have more free time to tinker with it, I will. My goodness, it is promising =D
Windows assumes the user is an idiot... Linux DEMANDS Proof!

Offline CwF

  • Elite Member
  • *****
  • Posts: 474
Re: Weekend with Qemu
« Reply #3 on: July 27, 2020, 10:16:49 AM »
Sure you can! One question would be do you need to access the game files from 2 or more systems at the same time? Then it does need to be a share. qemu does have a built in samba system of sorts with share option in the storage section, but different vmm versions have different options, and that's going away with virtiofs coming.

But, if you work on the game files exclusively from one instance at a time then a virtual drive works better than anything. Convert the game files to a qcow2 or img(raw) disk image file. Mount it where you need it when you need it! You can keep a compressed qcow2 file as a backup - might not be 40GB's!

You can use the command line, convert those into button actions in the host UI, or use VMM.

I assume Win7 will act like XP, so you can actually hot plug the sata bus and a drive image to a running vm. The machine type should be a Q35 and Win need the drivers already installed (9DO sata I think). Or use USB as the device bus, slower. The first time win might want to reboot, but subsequent times it is hot pluggable. User error is a concern - don't forget where it's mounted!

Obviously this virtual drive needs to be NTFS for windows.

There is obvious overhead here that makes it sluggish on a weak computer. If a qcow2, the system would like to have a few free cores for the compression stream, etc. On a powerhouse machine it's very transparent. Such a drive could be much smaller than the 40GB depending on comprehensibility, again a few spare cores please...and with use the image file will grow to uncompressed data size -and even slightly larger. You can use standard tools within any OS operating on the image, and occasionally when not in use use virt-sparsify to 'trim' the drive image, then copy to a new file with compression to start the image fresh again and at maybe half size. As an example, my OS images average 1-2GB, an i386 32GB image with wine and more than 10GB of game stuff - last refresh the image was 7.8GB! A drive of photos is 10%+ smaller, my records drive is 80-90% smaller, etc. They are available to any vm and host - just not concurrently - and best of all they can be 'off'.

I do this with nearly everything, actually everything. In this format it's easy to keep a backup, it's a single file - so it's like a big file, still just a file. Each OS I have has a qcow2 file backup, even windows. Many things compress down pretty far, you're familiar, and even things that don't you are still eliminating slack space in the filesystem. Qcow2 is very mature and reliable. I did a post awhile back device=disk=directory=file or something like that, this is what I was talking about. Commercial use includes virtual drives in the hundreds of GB's. With this technique ransonware is a hour inconvenience at most.

Enjoy.