I looked at qemu/kvm briefly some years ago, perhaps a decade, IIRC.
In another thread virt-manger was highly praised and I decided to putzed around abit with it. I it hadn't improved much. In that thread I was given reasons to re-examine my experience. That led me to getting serious and re-installing installing virt-manager, qemu-system and all that they haul down the pipe.
By co-incidence I also happened to find my licensed copy of XP SP2. And, Maui1, a successor to Netrunner 17 was released, as was openSUSE-Leap41. Both are plasma5 releases. Three nice candidates to test Qemu/kvm.
My initial, and somewhat casual, first experience with the latest Qemu/kvm led to the problem of creating a fixed virtual HD, because I use btrfs and it does not like dynamically sized files. I went ahead anyway and used qcow2, the recommended dynamic drive, primarily because the virt-manager gui didn't give an unambiguous method of creating a fixed size *.img file. I tried "file" and "raw" but they seemed hit and miss, and Maui1 and openSUSE didn't perform well using either.
Then I decided to read some documentation and watch some youtube videos. The video by Dan Sheffner was long but very informative. For help installing XP I found this article.
The key to using qemu is creating your virtual HD manually, not through the gui, because the gui lacks many parameters that are necessary when installing a guest OS on btrfs or installing a Windows guest OS.
First, open a Konsole and issue "sudo su -" so that you don't have to repeatedly use the sudo command. Then cd to
/var/lib/libvirt/images/
which is a "pool" where the HD images are stored. (Ya, it's a directory) I found it a good idea to save downloaded ISO's to that directory because the gui, virt-manager, uses that location as its default "pool". Later you can create other "pools" in other locations.
The command to make an openSUSE Leap-41 fixed sized HD is:
qemu-img create -f qcow2 -o nocow=on mint18kde5.qcow2 25G
The format (-f) is qcow2 (qemu's copy on write version 2), but since I am using btrfs I need to use the parameter which turns off copy on write (-o nocow=on), followed by the name and extension of the virtual HD and then the size. It doesn't take long.
The virtual disks for Maui1 and winxp are made identically, except for the name.
I used the qemu gui, virt-manager, to install Maui1 and openSUSE by selecting their ISO for the install source, and their qcow2 HDs for the destination. I also chose to configure the setup before the install began.
The method for installing the winxp quest is different, because of the installation will be from the winxp CDROM, not an ISO file, so the command line is used.
qemu-system-i386 -m 256 -hda ./winxp.qcow2 -cdrom /dev/cdrom -boot d
I used qemu-system-i386 (I could have used the qemu-sysstem-x86_64), and set the memory at 256, and told qemu to use the cdrom at /dev/cdrom with the -boot command and "d". Winxp installed the slowest of the three, taking nearly two hours, but it loads the fastest, runs the fastest and shuts down the fastest. Maui1 takes the longest to shut down, at least 3 to 4 minutes.
It is very easy to resize the displays, openGL is available (3.1, 3.0,2.1) as is wayland. I found no setting for 3D acceleration, but I plan to try a game that uses it to see if it can run. More than likely it is in the copious amount of Konsole commands and parameters available to the user.
I was able to to use a virsh command (domiflist) to list the domains and their internet mac addresses. From that I can use the arp command in a console to pull the IP address out of the guest OS. (arp -e | grep macaddress).
With the IP address I can use SSH to log into the domain, if it is running, and do what one can usually do with a remote connection:
ssh yourdomainname@the.ip.address.wyz -l accountname
You'll be asked for the account password (you can't remotely access root) and then you are in. You can move files back and forth, make configuration changes and do other things with the CLI tools available.
All in all I love the way qemu works, its versitility and power. And, it is fast.
In another thread virt-manger was highly praised and I decided to putzed around abit with it. I it hadn't improved much. In that thread I was given reasons to re-examine my experience. That led me to getting serious and re-installing installing virt-manager, qemu-system and all that they haul down the pipe.
By co-incidence I also happened to find my licensed copy of XP SP2. And, Maui1, a successor to Netrunner 17 was released, as was openSUSE-Leap41. Both are plasma5 releases. Three nice candidates to test Qemu/kvm.
My initial, and somewhat casual, first experience with the latest Qemu/kvm led to the problem of creating a fixed virtual HD, because I use btrfs and it does not like dynamically sized files. I went ahead anyway and used qcow2, the recommended dynamic drive, primarily because the virt-manager gui didn't give an unambiguous method of creating a fixed size *.img file. I tried "file" and "raw" but they seemed hit and miss, and Maui1 and openSUSE didn't perform well using either.
Then I decided to read some documentation and watch some youtube videos. The video by Dan Sheffner was long but very informative. For help installing XP I found this article.
The key to using qemu is creating your virtual HD manually, not through the gui, because the gui lacks many parameters that are necessary when installing a guest OS on btrfs or installing a Windows guest OS.
First, open a Konsole and issue "sudo su -" so that you don't have to repeatedly use the sudo command. Then cd to
/var/lib/libvirt/images/
which is a "pool" where the HD images are stored. (Ya, it's a directory) I found it a good idea to save downloaded ISO's to that directory because the gui, virt-manager, uses that location as its default "pool". Later you can create other "pools" in other locations.
The command to make an openSUSE Leap-41 fixed sized HD is:
qemu-img create -f qcow2 -o nocow=on mint18kde5.qcow2 25G
The format (-f) is qcow2 (qemu's copy on write version 2), but since I am using btrfs I need to use the parameter which turns off copy on write (-o nocow=on), followed by the name and extension of the virtual HD and then the size. It doesn't take long.
The virtual disks for Maui1 and winxp are made identically, except for the name.
I used the qemu gui, virt-manager, to install Maui1 and openSUSE by selecting their ISO for the install source, and their qcow2 HDs for the destination. I also chose to configure the setup before the install began.
The method for installing the winxp quest is different, because of the installation will be from the winxp CDROM, not an ISO file, so the command line is used.
qemu-system-i386 -m 256 -hda ./winxp.qcow2 -cdrom /dev/cdrom -boot d
I used qemu-system-i386 (I could have used the qemu-sysstem-x86_64), and set the memory at 256, and told qemu to use the cdrom at /dev/cdrom with the -boot command and "d". Winxp installed the slowest of the three, taking nearly two hours, but it loads the fastest, runs the fastest and shuts down the fastest. Maui1 takes the longest to shut down, at least 3 to 4 minutes.
It is very easy to resize the displays, openGL is available (3.1, 3.0,2.1) as is wayland. I found no setting for 3D acceleration, but I plan to try a game that uses it to see if it can run. More than likely it is in the copious amount of Konsole commands and parameters available to the user.
I was able to to use a virsh command (domiflist) to list the domains and their internet mac addresses. From that I can use the arp command in a console to pull the IP address out of the guest OS. (arp -e | grep macaddress).
With the IP address I can use SSH to log into the domain, if it is running, and do what one can usually do with a remote connection:
ssh yourdomainname@the.ip.address.wyz -l accountname
You'll be asked for the account password (you can't remotely access root) and then you are in. You can move files back and forth, make configuration changes and do other things with the CLI tools available.
All in all I love the way qemu works, its versitility and power. And, it is fast.
Comment