Moderator: BarryK
Has anyone tried to run EasyOS as a virtual machine in QEMU on top of another puppy-related OS?
QEMU would normally require an ISO image of the virtual OS. EasyOS, however, ships as an img.gz file that has to be written to a flash drive:
https://easyos.org/about/why-the-iso-fo ... o-die.html
Is it possible to mount a virtual USB drive on the host OS that could then be used in QEMU?
Or would you have to create a physical USB drive with EasyOS?
Yes
Is it possible to mount a virtual USB drive on the host OS that could then be used in QEMU?
Yes, again. The flaw here is that you are referring to 'virtual' USB. QEMU sees drives (aka storage units); not USBs.
would you have to create a physical USB drive with EasyOS?
There is no requirement to do so, but if you have a bootable USB already: You can and boot that via QEMU, if you wish such.
I will try to create a new Thread on the forum showing each of the 3 cases you asks.
Before I do, have you seen the picture in this document?
BTW: Have you tried any of these?
As upstream QEMU page says:
https://qemu-project.gitlab.io/qemu/system/images.html
QEMU supports many disk image formats, including growable disk images (their size increase as non empty sectors are written), compressed and encrypted disk images.
...
QEMU supports many image file formats that can be used with VMs as well as with any of the tools (like qemu-img). This includes the preferred formats raw and qcow2 as well as formats that are supported for compatibility with older QEMU versions or other hypervisors.
...
In addition to disk image files, QEMU can directly access host devices.
One of many distro manpages for QEMU: https://man.archlinux.org/man/qemu.1.en
The following nothing to do with EasyOS, but including just FYI concerning use of QEMU and qcow2 images:
Some interesting QEMU boots given at bottom of man page. For example, despite deprecated report, following given examples worked for me straight away (except I didn't know the login user: passwd):
boot from a remote Fedora 20 live ISO image
boot from a remote Fedora 20 cloud image using a local overlay for writes, copy-on-read, and a readahead of 64k
EDIT: In the end I was able to reset the qcow2 image passwd given by method described here: https://access.redhat.com/discussions/664843
(required me installing libguestfs-tools on my Ubuntu-based system, Zorin, which I was working from)
https://www.tinylinux.info/
DOWNLOAD wd_multi for hundreds of 'distros' at your fingertips: viewtopic.php?p=99154#p99154
Αξίζει να μεταφραστεί;
Thanks for sharing the QEMU document @Clarity. I am currently using a remastered Fatdog64 loaded from DVD into RAM and have installed QEMU 6 and the visual vm manager (1.4) from the package manager. That would be interesting to see if it is possible to get EasyOS with the full container functionality running as a QEMU VM on top of a RAM-loaded OS. Would appreciate your guidance... 
Thanks for sharing those explanations @wiak. Could you also share the source of the mentioned "remote" cloud images? That sounds like an interesting idea to quickly access the latest versions of a particular OS in the cloud instead of timely downloads.
@Neo_78, That document appears feature complete and an easy structured reading. Observing, it appears as being written from an older version of Fatdog intermingled with other PUPs as it attempts at a universal Puppyland Forum appeal.
Any QEMU/KVM question(s) could be posted on the forum, here, where you should expect a quick forum response.
Reach out if we can help; OR if you choose to share you progress and tests results.
The links to these Fedora cloud images are in the already supplied link to a QEMU man page: https://man.archlinux.org/man/qemu.1.en
Scroll down the man page till near the bottom and you'll find the qemu startup code that accesses the Fedora cloud images just after line saying:
Example: boot from a remote Fedora 20 cloud image using a local overlay for writes, copy-on-read, and a readahead of 64k
I note from the code given there that the link that gets used for the download by qemu is: https://archives.fedoraproject.org/pub/ ... 4-20-1.iso
but you don't need to access that directly; I just ran the exact code lines given in the man page to boot that distro with its provided qcow2 image extra.
https://www.tinylinux.info/
DOWNLOAD wd_multi for hundreds of 'distros' at your fingertips: viewtopic.php?p=99154#p99154
Αξίζει να μεταφραστεί;
As an experiment I tried to run EasyOS in VirtualBox, installed on a virtual disk in VDI format. If that would work, one could take the VDI disk image and convert to a QCOW2 image to run in QEMU.
Not there yet but I did get a frugal EasyOS installed on a pre-existing frugal Fossapup64+LXDE install running in VBox, and booted it successfully using (a slightly modified) Barry's suggested GRUB2 script* as shown below (as I recall..):
menuentry "EasyOS Dunfell" {
MYUUID=<UUID>
insmod ext2
insmod search_fs_uuid
search --no-floppy --fs-uuid --set $MYUUID
linux /easyOS/vmlinuz rw wkg_uuid=$MYUUID wkg_dir=easyos
initrd /easyOS/initrd
}
As another experiment I tried installing EasyOS on an internal drive under QEMU running in Fossapup64.
Worked well, including the sound !!!
( These notes below assume familiarity with running QEMU using a BASH script.)
The first thing to do was create an 8GB qcow2 image using qemu-img to hold easyOS.
The second step was to run a qemu script with an ISO (fossapup64 ) adding the empty drive as < -hda easyos.img >
The idea was then to transfer EasyDD and the EasyOS ISO into the home folder using PureFTP / GFTP, but there was not enough space in the home folder.
OK, that did not work. Perhaps another ISO would have worked better??
Undeterred, I then found a second script which used a pre-existing Fossapup64 image with a frugal install, which had enough free space for the EasyOS ISO. This would become hda. I also added the empty drive, which would become hdb. The target drive images were then < -hda Fossapup64_C.img -hdb EasyOS.img >
The script was then run, booting Fossapup64 in QEMU.
EasyDD and the EasyOS ISO were copied into the home folder.
Used GPARTED in Fossapup to add a partition table into drive sdb
Used EasyDD to write EasyOS to drive sdb
Closed down Fossapup64
Changed the qemu script to remove Fossapup64 and change EasyOS to hda: < -hda EasyOS.img >
Ran the revised qemu script and EasyOS ran like a charm !
That sounds promising @Geek3579.
But you created the vHDD.img for EasyOS with qemu-img on a physical hard drive, correct? Because the EasyOS container function requires a hard drive installation, right?
My idea is to run EasyOS with container functionality in QEMU on a top of a RAM-only FatDog host booted from USB. So memory in memory...
Still trying to figure out what's the best way to store the required image. Thought about creating a separate data DVD with the guest host images of multiple OS so that they don't have to be downloaded every time. Another option would be to store those images within my remastered Fatdog iso.
Sorry for any confusion. Hope this extra info helps.
In my second experiment I created a dynamic growth disk image using qemu-img :
qemu-img create -f qcow2 EasyOS_a.img 8G
In QEMU I booted a pre-existing version of Fossapup64 (FOSS64_C.img) installed on a virtual drive (sda) which could access the virtual (blank) drive created above, which would be seen as sdb.
modprobe kvm-intel # start KVM
qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -hda FOSS64_C.img -hdb EasyOS_a.img \
-cpu host -vga std -usb -device usb-tablet -soundhw ac97
I then created a partition table in sdb (hdb in above script) and burned an image of EasyOS onto it using EasyDD, both of which were imported and stored on sda, effectively.
EasyOS_a.img could now be run as a stand alone OS under QEMU by changing the following line in the script:
qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -hda EasyOS_a.img \
The EasyOS_a.img QCOW2 image could, in theory be changed to a raw HDD image:
qemu-img convert -O raw source.img image.raw
and then burned to a USB or HDD.
Note that I had a SBC with 8GB RAM which is very helpful for tasks like this. 4GB sometimes doesnt cut it.
Also, the QCOW image+script are completely portable by copy/paste between two different machines running QEMU, which is why I like QEMU more than VBox sometimes.