Bhyve vs proxmox

NeverDie

Active Member
Jan 28, 2015
307
26
28
USA
I'm fairly happy with ProxMox, but according to this youtube video:
FreeBSD's Bhyve hypervisor can clone (or snapshot) a VM in less than a second--even if running on a 10 year old laptop computer--whereas ProxMox cannot (even if, as I have done, I install ZFS as the file system everywhere used by ProxMox). Is it because the FreeBSD ZFS is either more complete or more tightly integrated? Anyone here done a compare/contrast of Bhyve vs ProxMox? I'm also intrigued because FreeBSD/Bhyve has "jails" for added security of VM's.

My use case is to frequently create new clones of VM's for browsing purposes, where any malware I might encounter while browsing should hopefully stay sandboxed inside the VM. After completing a browsing session, I would simply "throw away" the entire VM and then instantly clone a new browsing VM from a "golden VM" when I next want to browse again. If it's true that Bhyve can clone a VM in under a second, then that would fit my use case much better than Proxmox, which no matter what I've tried takes much longer than that to clone a VM.
 

Marjan

New Member
Nov 6, 2016
14
2
3
I would say this is due to underlying file system. On TrueNAS you have ZFS file system, on your Proxmox installation I guess you don't have it.
I don't know exact technical difference but I think this is the reason.
Similar thing is on Windows. In NTFS volume Hyper-V will create snapshots much slower than on ReFS.

Hopefully someone with more knowledge will give better answer.
 

NeverDie

Active Member
Jan 28, 2015
307
26
28
USA
Could it be that in FreeBSD the ZFS is somehow "native", whereas on ProxMox, the ZFS isn't "native"? AFAIK, ProxMox is running OpenZFS to get its ZFS. Maybe it's a limitation of the OpenZFS implementation of ZFS as compared to FreeBSD's implementation of ZFS?
 

RTM

Well-Known Member
Jan 26, 2014
764
280
63
Sorry, but I am not going to watch the video, but I do want to say that it doesn't sound right to compare the two.
One is a full virtualization platform, complete with OS, webinterface and all, the other is just the hypervisor itself (AFAIK anyway).

As for why it is slower, perhaps (and this is just a guess) the webinterface executes commands asymetrically.
Meaning that you submit a request, this pushes a job into a queue, a worker polls the queue (delayed of course) at certain intervals for new jobs, when it finds them executes the job and returns the result into the queue (or DB), from which the browser (which may also be using polling, while waiting for completion) can eventually be notified of completion.
 

infidelkastro

New Member
Mar 22, 2021
11
4
3
33
North Carolina
AFAIK, ProxMox is running OpenZFS to get its ZFS. Maybe it's a limitation of the OpenZFS implementation of ZFS as compared to FreeBSD's implementation of ZFS?
Isn't Freebsd also running on OpenZFS these days? I remember reading that somewhere.

It would be fair to assume that KVM, as mature and as feature-rich as it is, probably has more cruft than bhyve. But if I was asked to guess, the "cloning lag" referenced by OP's use-case is dependent on host system configuration such as the nature of storage (flash/spinners), amount of memory installed, or even type of clone (linked/full) effected.
 

NeverDie

Active Member
Jan 28, 2015
307
26
28
USA
As for why it is slower, perhaps (and this is just a guess) the webinterface executes commands asymetrically.
Meaning that you submit a request, this pushes a job into a queue, a worker polls the queue (delayed of course) at certain intervals for new jobs, when it finds them executes the job and returns the result into the queue (or DB), from which the browser (which may also be using polling, while waiting for completion) can eventually be notified of completion.
No, that can't be the reason: 1 second clone on FreeBSD Bhyve (as demonstrated in the video at time index 3:10) vs. about a 2 minute clone on proxmox. That's too great a disparity to be accounted for by a polling delay.
 

NeverDie

Active Member
Jan 28, 2015
307
26
28
USA
Isn't Freebsd also running on OpenZFS these days? I remember reading that somewhere.
I had thought they were different, but, yes, it looks as though FreeBSD and OpenZFS were merged together for the FreeBSD 13.0 release: OpenZFS Support Merged Into Mainline FreeBSD - Phoronix

But since version 13.0 was released only recently, the comparison may have to be redone using that as the new baseline. It's conceivable It might mean that bhyve now takes 2 minutes instead of 1 second to do clone.
 

NeverDie

Active Member
Jan 28, 2015
307
26
28
USA
OK, I think I'm closer now to having this figured out. I created a VM using the TruNAS Core (version TrueNAS-12.0-U3.1, which is the most current version) GUI, because TruNAS Core runs whatever ZFS that FreeBSD is using and because TruNAS Core uses bhyve as its hypervisor. I did it that way, because I'm not a bHyve savant, and because the GUI makes the process not too difficult for a BHyve beginner.

Doing that, I was able to confirm that "cloning" the VM indeed appears to be very fast.

However, the impression I'm getting is that TruNAS/Byhve is not actually creating a true clone of the VM itself, but instead containerizing the VM and creating a clone from that. The same can be done in proxmox by first containerizing a VM and then creating a clone from the containerized VM. Creating a clone from a container is also very fast in proxmox (well, compared to creating a true clone), though so far not quite as fast as in TruNAS/Bhyve: around 9 seconds in Proxmox vs around 1 second from the TruNAS GUI. These are imprecise measurements using my wristwatch, but they give some approximation of relative speed. That said, there's a world of difference in usability between a 9 second cloning and a 1 second cloning, especially with regard to my use case (above). Actually, come to think of it, the 9 second measurement was taken on a slower computer, so the time difference is likely to be less on a true apples-to-apples comparison. I'll try to do a better comparison along those lines sometime soon. If there's interest, I can report back on the results.

Maybe there's a better GUI for Byhve? The TruNAS VM GUI feels rather rudimentary (especially when it comes to editing properties of a VM that I previously created). At least in that regard, I'm preferring ProxMox. That's not a strike against bhyve per se, though, but just a commentary on the state of the trunas VM GUI. Hopefully the trunas core VM GUI will continue to improve. According to the official documentation (Basic Management |), the TruNAS VM manager is exclusively a part of the TruNAS Core release. On the other hand, TruNAS SCALE is advertised as also having both containers and VMs, and a KVM hypervisor, so presumably (?) SCALE will include a different kind of VM GUI (?). It might be worth spinning up SCALE just to have a look.
 
Last edited:

Jeggs101

Well-Known Member
Dec 29, 2010
1,506
233
63
Sorry, that is a dumb video. I'm not going to watch. Bhyve is a less complete VM solution whereas KVM is very mature. KVM is the basis for the modern cloud, Bhyve is so bad that TrueNAS Scale is abandoning Bhyve for KVM.

Silly video.
 

NeverDie

Active Member
Jan 28, 2015
307
26
28
USA
Sharpening my language a bit, the TL;DR of my earlier post (above) is that TruNAS core creates "linked clones" rather than "full clones" when you press the clone button on your TruNas vm, and so I presume the same is true for BHyve.

If you want to prove this to yourself, try creating a clone, then a clone of that clone, and then a clone of that (the most recent) clone, and so on, until you hit an error condition--which in my case happened fairly quickly. Looking at the error output, you can see that the name for each clone is concatenated to one before it, with some dashes in-between, and what causes the error condition is that the clones file name becomes too long. With full clones, I can't think of any reason why there would be a name chain of this kind. Apparently with linked-clones in BHyve, on the other hand, it appears that the chain of links are literally in the file name.

Offhand, I don't see a way to create a "full clone" using the TruNAS GUI.

Regardless, according to the SmartOS wiki, BHyve has these advantages over KBM:
"

  • Better tracking of, and integration wth, upstream FreeBSD
  • Higher performance for CPU, and I/O operations (including disk and network I/O).
  • Lower overhead, resulting in lower host CPU utilization while guests are idle."

source: Bhyve - SmartOS Docs

SmartOS gives you the choice of running VM's using either a KVM hypervisor or a Bhyve hypervisor, so maybe they draw their conclusions from that. I have no skin in the game either way, and so I'm only interested in ferreting out what is objectively true.
 

dswartz

Active Member
Jul 14, 2011
515
53
28
No, that can't be the reason: 1 second clone on FreeBSD Bhyve (as demonstrated in the video at time index 3:10) vs. about a 2 minute clone on proxmox. That's too great a disparity to be accounted for by a polling delay.
Dunno about bhyve, but proxmox does the VMDKs as zvols. Maybe that sucks, performance-wise? Although 2 minutes sounds like a lot. Is this done at the CLI? I haven't used proxmox for quite awhile, but I'm wondering if they are not doing zfs snapshots, but something else?
 

i386

Well-Known Member
Mar 18, 2016
2,658
775
113
32
Germany
Bhyve is so bad that TrueNAS Scale is abandoning Bhyve for KVM
Not really.
Truenas Scale (not to be confused with core which is still using freebsd!) is based on linux (I think it was debian?), linux doesn't have bhyve.
 

NeverDie

Active Member
Jan 28, 2015
307
26
28
USA
^^^ This.

Also,
KVM is the basis for the modern cloud
Is that really true? If anything, I thought VMware was the basis for the modern cloud. Just my perception though. Not sure as to what the relative market shares actually are, or their evolution over time. I'd be interest to know though. Surely somewhere those percentages are rigorously tracked by somebody.
 
Last edited:

i386

Well-Known Member
Mar 18, 2016
2,658
775
113
32
Germany
Vmware is huge with on premise datacenters, but cloud providers & hyperscalers operate on a totally different level and use other tools :D

Edit: Microsoft uses azure hyper visor which is based on hyper-v, other cloud providers use kvm based solutions
 
Last edited:

NeverDie

Active Member
Jan 28, 2015
307
26
28
USA
Reporting back: being careful to setup everything right with the most current ProxMox on new hardware with a Ryzen 5700G and ZFS on root, it takes less than 0.1 second to create a linked clone of a virtual machine, as reported by Proxmox's task log. Size of the VM doesn't seem to matter. Same for snapshots.

So, at least for me, that settles the debate. Due to greater familiarity, and a more complete GUI than bhyve on Trunas, I've decided to stick with ProxMox.

As to why creating full-clone VM's takes so much longer than it seems like it should, I did manage to learn something new: on this fresh hardware, which uses nvme for storage, it turns out that creating a full clone of a VM is very much CPU bound rather than storage speed bound. Using htop to gain insight, I found that creating a full-clone pushes all 8 of the ryzen cores pretty nearly to maximum, even with automatic ZFS file compression and encryption both turned off. Running some tests, I found that the time taken to create a full clone is a function of both virtual disk size as well as how "full" that disk image is with the files inside it. So, for whatever reason, creating a full clone apparently involves more than just making a straight bit-for-bit copy of the VM's virtual disk image, and apparently that's why it ends up taking so long. Given this, I'm doubtful there's a workaround tthat would speed up the creation of full clones, but if anyone knows of one, or a different approach, then please do post a comment. Apparently the one thing that probably would help is using a CPU with more cores, like a Ryzen 9 5950x or a threadripper, since it' the CPU that's the chokepoint and the htop insight suggests that even more cores could be used in parallel to speed up the full-clone process.
 
Last edited: