Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
On Wed, Jun 3, 2015 at 9:18 AM, Andriy Gapon wrote: > On 03/06/2015 18:53, John-Mark Gurney wrote: > > JIMO, bhyveload(8) could be just merged into bhyve(8) and the latter should > behave like vmrun.sh does. bhyve(8) should retain an option to run a > preloaded > kernel, so that things like bhyve-grub keep working. > I understand why bhyveload(8) and bhyve(8) exists. However, from a usability perspective, the fact that I need to invoke two commands to start a VM is unfortunate. >From a end-user usability standpoint, this is no good. vmrun.sh is not bad for simple usage, but its limitations become apparent quite quickly. For anyone doing serious stuff with bhyve, you end up having to write your own replacement for vmrun.sh. I've done it, and I am sure others have as well. What I would like to see is a single command that I can type with all the command-line options to start a bhyve VM, instead of multiple commands that need to be stitched together via a script. For example, if bhyve(8) could be enhanced with a flag "--loader" (or choose another flag name that you prefer): (1) If "--loader" is not specified, then by default, bhyve uses bhyveload (2) If "--loader" is specified, then valid options are bhyveload and grub-bhyve (3) bhyve(8) will internally fork the loader specified in (1) or (2) (4) If (3) fails, then stop. If (3) succeeds, then bhyve(8) will continue to start the VM I would also like to see: -> command-line option parsing for bhyveload and grub-bhyve changed, so that they silently ignore command-line options that they don't grok. That would make it easier to implement (3), since bhyve(8) could pass its full command-line arguments to the forked loader. I don't have time to work on this, but it would be nice if this could be implemented. -- Craig ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
On 03/06/2015 18:53, John-Mark Gurney wrote:
> Andriy Gapon wrote this message on Wed, Jun 03, 2015 at 10:10 +0300:
>> On 03/06/2015 02:04, John-Mark Gurney wrote:
>>> Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 21:15 +0300:
I guess you are running bhyve through the shell script vmrun.sh?
I am doing everything by hand.
>>>
>>> Correct:
>>> sh /usr/share/examples/bhyve/vmrun.sh -g 6444 -d mach10s.img -t tap0
>>>
>>> It's nice.. shutdown -r now and shutdown -p now both work exactly as
>>> you'd expect them to... :)
>>
>> Yes, it's quite convenient. The only drawback is that currently it can't
>> pass
>> multiple -d options to bhyveload and I need that from time to time.
>
> Hmm... Looking at the script, it looks like you can (at least on HEAD):
> d)
> eval "disk_dev${disk_total}=\"${OPTARG}\""
> disk_total=$(($disk_total + 1))
This was only half of the equation, please see this:
https://reviews.freebsd.org/D2723
>> Probably not hard to change that.
>
> It'd also be nice to allow you to switch the default from virtio-blk
> to ahci when you're image doesn't support it..
>
> Hmm.. It wouldn't be hard to try to use environment vars for the defaults
> either...
>
> Maybe it's time to move vmrun.sh to bhyverun, install it and give
> it a proper man page?
JIMO, bhyveload(8) could be just merged into bhyve(8) and the latter should
behave like vmrun.sh does. bhyve(8) should retain an option to run a preloaded
kernel, so that things like bhyve-grub keep working.
--
Andriy Gapon
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
Andriy Gapon wrote this message on Wed, Jun 03, 2015 at 10:10 +0300:
> On 03/06/2015 02:04, John-Mark Gurney wrote:
> > Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 21:15 +0300:
> >> I guess you are running bhyve through the shell script vmrun.sh?
> >> I am doing everything by hand.
> >
> > Correct:
> > sh /usr/share/examples/bhyve/vmrun.sh -g 6444 -d mach10s.img -t tap0
> >
> > It's nice.. shutdown -r now and shutdown -p now both work exactly as
> > you'd expect them to... :)
>
> Yes, it's quite convenient. The only drawback is that currently it can't pass
> multiple -d options to bhyveload and I need that from time to time.
Hmm... Looking at the script, it looks like you can (at least on HEAD):
d)
eval "disk_dev${disk_total}=\"${OPTARG}\""
disk_total=$(($disk_total + 1))
> Probably not hard to change that.
It'd also be nice to allow you to switch the default from virtio-blk
to ahci when you're image doesn't support it..
Hmm.. It wouldn't be hard to try to use environment vars for the defaults
either...
Maybe it's time to move vmrun.sh to bhyverun, install it and give
it a proper man page?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
On 03/06/2015 02:04, John-Mark Gurney wrote: > Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 21:15 +0300: >> I guess you are running bhyve through the shell script vmrun.sh? >> I am doing everything by hand. > > Correct: > sh /usr/share/examples/bhyve/vmrun.sh -g 6444 -d mach10s.img -t tap0 > > It's nice.. shutdown -r now and shutdown -p now both work exactly as > you'd expect them to... :) > Yes, it's quite convenient. The only drawback is that currently it can't pass multiple -d options to bhyveload and I need that from time to time. Probably not hard to change that. -- Andriy Gapon ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
On 2015-06-02 19:04, John-Mark Gurney wrote: Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 21:15 +0300: On 02/06/2015 19:49, John-Mark Gurney wrote: Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 14:20 +0300: I am very new to bhyve, so sorry if I am asking something silly or obvious. I am using bhyve to speed up my testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually booting the VM with bhyve. It seems that I have to do this even if I don't change th kernel between reboots. My first naive impression was that the point of bhyveload was to load the kernel once. Seems it ain't so? Hmm... I'm not seeing that here... I just scp a new kernel into the vm, install it, and run shutdown -r now which drops bhyve back to loader, and loads the new kernel... I've been doing this quite successfully over the last few months... I am running a month old HEAD though... I guess you are running bhyve through the shell script vmrun.sh? I am doing everything by hand. Correct: sh /usr/share/examples/bhyve/vmrun.sh -g 6444 -d mach10s.img -t tap0 It's nice.. shutdown -r now and shutdown -p now both work exactly as you'd expect them to... :) yes, vmrun.sh puts bhyve in a while loop. -- Allan Jude ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 21:15 +0300: > On 02/06/2015 19:49, John-Mark Gurney wrote: > > Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 14:20 +0300: > >> I am very new to bhyve, so sorry if I am asking something silly or obvious. > >> I am using bhyve to speed up my testing and it seems that each time I need > >> to > >> restart a VM I need to go through the cycle of destroying it with bhyvectl > >> --destroy, then re-loading a kernel with bhyveload and then actually > >> booting the > >> VM with bhyve. It seems that I have to do this even if I don't change th > >> kernel > >> between reboots. My first naive impression was that the point of > >> bhyveload was > >> to load the kernel once. Seems it ain't so? > > > > Hmm... I'm not seeing that here... I just scp a new kernel into the > > vm, install it, and run shutdown -r now which drops bhyve back to > > loader, and loads the new kernel... I've been doing this quite > > successfully over the last few months... > > > > I am running a month old HEAD though... > > I guess you are running bhyve through the shell script vmrun.sh? > I am doing everything by hand. Correct: sh /usr/share/examples/bhyve/vmrun.sh -g 6444 -d mach10s.img -t tap0 It's nice.. shutdown -r now and shutdown -p now both work exactly as you'd expect them to... :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
On 02/06/2015 19:49, John-Mark Gurney wrote: > Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 14:20 +0300: >> I am very new to bhyve, so sorry if I am asking something silly or obvious. >> I am using bhyve to speed up my testing and it seems that each time I need to >> restart a VM I need to go through the cycle of destroying it with bhyvectl >> --destroy, then re-loading a kernel with bhyveload and then actually booting >> the >> VM with bhyve. It seems that I have to do this even if I don't change th >> kernel >> between reboots. My first naive impression was that the point of bhyveload >> was >> to load the kernel once. Seems it ain't so? > > Hmm... I'm not seeing that here... I just scp a new kernel into the > vm, install it, and run shutdown -r now which drops bhyve back to > loader, and loads the new kernel... I've been doing this quite > successfully over the last few months... > > I am running a month old HEAD though... > I guess you are running bhyve through the shell script vmrun.sh? I am doing everything by hand. -- Andriy Gapon ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 14:20 +0300: > I am very new to bhyve, so sorry if I am asking something silly or obvious. > I am using bhyve to speed up my testing and it seems that each time I need to > restart a VM I need to go through the cycle of destroying it with bhyvectl > --destroy, then re-loading a kernel with bhyveload and then actually booting > the > VM with bhyve. It seems that I have to do this even if I don't change th > kernel > between reboots. My first naive impression was that the point of bhyveload > was > to load the kernel once. Seems it ain't so? Hmm... I'm not seeing that here... I just scp a new kernel into the vm, install it, and run shutdown -r now which drops bhyve back to loader, and loads the new kernel... I've been doing this quite successfully over the last few months... I am running a month old HEAD though... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
On 2015-06-02 12:16, Andriy Gapon wrote: On 02/06/2015 17:51, Peter Grehan wrote: Hi Andriy, I am very new to bhyve, so sorry if I am asking something silly or obvious. I am using bhyve to speed up my testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually booting the VM with bhyve. It seems that I have to do this even if I don't change th kernel between reboots. My first naive impression was that the point of bhyveload was to load the kernel once. Seems it ain't so? bhyveload does the job of what BIOS/boot0/1/2/loader would do on real h/w, so it has to be executed each time on restart. One optimization to the cycle you mentioned is that bhyvectl --destroy only has to be done when the VM is no longer needed i.e you can loop with bhyveload/bhyve. I see now. Thank you very much! BTW, and probably you are already aware of this, the documentation could use some work :-) I noticed at least the following: - bhyvectl is not documented - bhyve(8) and bhyveload(8) refer to vmm(4), which does not exist - bhyveload(8) does not mention that -d can be used multiple times - bhyve(8) has at least one incorrect reference to bhyveload(*4*) - bhyve(8) mentions vmnet - does that exist? But these are very minor things. bhyve rules :) vmnet does exist, it is a type of tap, I'll get it hooked up as an alias to the tap man page. -- Allan Jude ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
On 02/06/2015 17:51, Peter Grehan wrote: > Hi Andriy, > >> I am very new to bhyve, so sorry if I am asking something silly or obvious. >> I am using bhyve to speed up my testing and it seems that each time I need to >> restart a VM I need to go through the cycle of destroying it with bhyvectl >> --destroy, then re-loading a kernel with bhyveload and then actually booting >> the >> VM with bhyve. It seems that I have to do this even if I don't change th >> kernel >> between reboots. My first naive impression was that the point of bhyveload >> was >> to load the kernel once. Seems it ain't so? > > bhyveload does the job of what BIOS/boot0/1/2/loader would do on real h/w, so > it has to be executed each time on restart. > > One optimization to the cycle you mentioned is that bhyvectl --destroy only > has > to be done when the VM is no longer needed i.e you can loop with > bhyveload/bhyve. I see now. Thank you very much! BTW, and probably you are already aware of this, the documentation could use some work :-) I noticed at least the following: - bhyvectl is not documented - bhyve(8) and bhyveload(8) refer to vmm(4), which does not exist - bhyveload(8) does not mention that -d can be used multiple times - bhyve(8) has at least one incorrect reference to bhyveload(*4*) - bhyve(8) mentions vmnet - does that exist? But these are very minor things. bhyve rules :) -- Andriy Gapon ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
Are you running -CURRENT, 10-STABLE, or 10.1? I think there was talk recently of removing the requirement to destroy the VM before running bhyveload again. That's been the case in 10.1/STABLE and CURRENT for quite a while (the original change was r267216). later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
On 2015-06-02 07:20, Andriy Gapon wrote: > > I am very new to bhyve, so sorry if I am asking something silly or obvious. > I am using bhyve to speed up my testing and it seems that each time I need to > restart a VM I need to go through the cycle of destroying it with bhyvectl > --destroy, then re-loading a kernel with bhyveload and then actually booting > the > VM with bhyve. It seems that I have to do this even if I don't change th > kernel > between reboots. My first naive impression was that the point of bhyveload > was > to load the kernel once. Seems it ain't so? > Are you running -CURRENT, 10-STABLE, or 10.1? I think there was talk recently of removing the requirement to destroy the VM before running bhyveload again. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: bhyve: bhyveload, bhyve, bhyvectl --destroy
Hi Andriy, I am very new to bhyve, so sorry if I am asking something silly or obvious. I am using bhyve to speed up my testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually booting the VM with bhyve. It seems that I have to do this even if I don't change th kernel between reboots. My first naive impression was that the point of bhyveload was to load the kernel once. Seems it ain't so? bhyveload does the job of what BIOS/boot0/1/2/loader would do on real h/w, so it has to be executed each time on restart. One optimization to the cycle you mentioned is that bhyvectl --destroy only has to be done when the VM is no longer needed i.e you can loop with bhyveload/bhyve. later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
bhyve: bhyveload, bhyve, bhyvectl --destroy
I am very new to bhyve, so sorry if I am asking something silly or obvious. I am using bhyve to speed up my testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually booting the VM with bhyve. It seems that I have to do this even if I don't change th kernel between reboots. My first naive impression was that the point of bhyveload was to load the kernel once. Seems it ain't so? -- Andriy Gapon ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
