True. My goal is that if this works out for everyone, that someday it
might get pulled into the distribution. ZFS has it advantages, but you
are correct. Not everyone in the world wants to use ZFS (for whatever
the reason might be). Will make sure the core features stays file system
independent
Fwiw, I use zvol to create bhyve guest system disks, with ufs inside.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualiz
Il 2015-11-05 19:14 Shawn Debnath ha scritto:
> Won't be dealing with ZFS management yet.
If I can give you my two cents, if you plan on doing any kind of
management tool, please always keep in mind that ZFS is not required by
bhyve. We initially started with VMs on ZFS just to find out how
t
Yep, I chatted with Allan about this when I first got started. UCL is
definitely the way to go, and I will make that a priority. Though the
current UCL configuration for bhyve is in a state of flux. According to
him, the form is supposed to change quite a bit once bhyve gets support
for some n
Shawn,
Go forth and conquer and happy hacking!
It is quite clear that vmrun.sh, /usr/sbin/bhyve, /usr/sbin/bhyveload
are very simplistic and fall apart under more advanced usage.
It looks like there are many parallel efforts where people are writing
their own
scripts and utilities on top of bhyve
Great feedback and thank you. Looks like it might not hurt to continue
the work, at least for now.
My reasoning for a C based tool was to be able to use libvmmapi to get
deeper integration with the bhyve framework. Let's see how things go.
I will work on getting the basics functioning and ge
On Wednesday, November 04, 2015 09:56:53 PM Andreas Nilsson wrote:
> Well,
>
> in all honesty, getting vm managers to kvm equivalents ( ie virt-manager )
> should not be a goal. virt-manager and friends are terrible. Please
> envision something better!
>
> Where it is hosted and what language it
Well,
in all honesty, getting vm managers to kvm equivalents ( ie virt-manager )
should not be a goal. virt-manager and friends are terrible. Please
envision something better!
Where it is hosted and what language it is written in doesn't really matter.
Just my 2 cents.
Best regards
Andreas
On
Going back to the original message in the thread, yes, I think the more the
merrier.
I created iohyve to solve a problem I had. I wanted to store my bhyve VM's
in ZFS.
Matt C. created vm-bhyve to solve the problem of storing VM's in a manager
that didn't use ZFS.
Matt and I have traded ideas back a
>> Hello!
>>
>> Couple months ago I started writing a bhyve management tool in C for
>> our startup, in preparation for migration to FreeBSD for our servers.
>> The goal was to be able to create, drop, and auto-start/stop/restart
>> VMs, individually or all at once, and provide a plugin infrastr
On 2015-11-04 03:47, Matt Churchyard via freebsd-virtualization wrote:
Hello!
Couple months ago I started writing a bhyve management tool in C for
our startup, in preparation for migration to FreeBSD for our servers.
The goal was to be able to create, drop, and auto-start/stop/restart
VMs, indiv
> Hello!
>
> Couple months ago I started writing a bhyve management tool in C for
> our startup, in preparation for migration to FreeBSD for our servers.
> The goal was to be able to create, drop, and auto-start/stop/restart
> VMs, individually or all at once, and provide a plugin infrastructure
On Tue, Nov 3, 2015 at 4:19 PM, Shawn Debnath wrote:
> Hello!
>
> Couple months ago I started writing a bhyve management tool in C for our
> startup, in preparation for migration to FreeBSD for our servers. The
> goal was to be able to create, drop, and auto-start/stop/restart VMs,
> individually
Hello!
Couple months ago I started writing a bhyve management tool in C for our
startup, in preparation for migration to FreeBSD for our servers. The
goal was to be able to create, drop, and auto-start/stop/restart VMs,
individually or all at once, and provide a plugin infrastructure to
expose
14 matches
Mail list logo