Date: Thu, 28 Jan 2016 21:53:26 -0800 From: Neel Natu <neelnatu@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: dweimer@dweimer.net, "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org> Subject: Re: bhyve with Linux guest, how to safely handle updates? Message-ID: <CAFgRE9FBehiEHpnc2REW=rduHjXhwjo89rpifqNAsrP5hm-ktQ@mail.gmail.com> In-Reply-To: <56AAF721.4080009@freebsd.org> References: <790acf0350e0f10e79b4120e564a553c@dweimer.net> <20160126230338.GM4109@debian.ara-ler.com> <9ee895854c862cccc0bcc84c16eee063@dweimer.net> <20160127021348.GE1799@dendrobates.araler.com> <94df01924b1843c39aaf29a47a4fa2da@dweimer.net> <CAFgRE9FeVRF8OjNUYTA9yFpyVsnmHzZYKV=0an-1qnJYN5wfoQ@mail.gmail.com> <56AAF721.4080009@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Julian, On Thu, Jan 28, 2016 at 9:22 PM, Julian Elischer <julian@freebsd.org> wrote: > On 29/01/2016 3:13 AM, Neel Natu wrote: >> >> Hi Dean, >> >> On Thu, Jan 28, 2016 at 10:55 AM, dweimer <dweimer@dweimer.net> wrote: >>> >>> On 2016-01-26 8:13 pm, Sergey Manucharian wrote: >>>> >>>> Excerpts from dweimer's message from Tue 26-Jan-16 19:07: >>>>> >>>>> >>>>> Is there anything that normally needs to be done after a Linux kernel >>>>> update to refresh the grub2-bhyve setup? >>>> >>>> >>>> The kernel update should not have any effect since grub-bhyve uses the >>>> virtual disk mapping file, which should point to your linux drive. >>>> >>>> I'm using the following command: >>>> >>>> $ sudo grub-bhyve -m /path/to/device.map -r hd0,msdos1 -M 1024M debian >>>> >>>> where "device.map" contains the following: >>>> >>>> (hd0) /dev/zvol/zroot/linuxdisk1 >>>> (cd0) /stuff/vm/bhyve/debian/debian-testing-amd64-2015-11-30.iso >>>> >>>> "hd0" can be a real disk device, e.g. /dev/sda, or an image file (in >>>> my case it's a ZFS volume). >>>> >>>> How do you use that VM in VBox? If it's a .vdi file, bhyve will not be >>>> able to recognize it. You should use a raw HDD image file. To make it >>>> compatible with VBox you can create a .vmdk file pointing to that raw >>>> image. >>>> >>>> -- >>>> Sergey >>> >>> >>> I am back to testing again, copied my ZFS Boot Environment over to a >>> VMware >>> virtual machine, renamed it and changed IPs, removed the virtual box >>> stuff, >>> and enabled bhyve. >>> >>> I did some searching and found out that I was using >>> https://github.com/churchers/vm-bhyve to manage the bhyve virtual >>> machines >>> starting and stopping. Sticking with zvol for disk backing, I know its >>> less >>> portable. >>> >>> I have been able to install a couple of debian virtual machines and play >>> around with them. So far I have been unable to duplicate the issue I had >>> before. My current issue which maybe related to running inside a VMware >>> virtual machine. Is the Linux hwclock and system clock sync issues. If I >>> power off the vm and reboot it it believes that the disk was modified in >>> the >>> future and appears to hang. Its actually doing a fsck I just don't see >>> status if you wait long enough it finally does come up. >>> >>> Has anyone else ran into this issue? I have actually ran the hwclock >>> -systohc --utc prior to powering down and still had the issue. Tried >>> changing the hwclock to system time by excluding the --utc from the >>> command >>> no change. Incidentally whether I use the --utc or not the hwclock --show >>> always displays the local time. I couldn't seem to find any documentation >>> on >>> bhyve whether or not I should tell the guests that the hwclock is in utc >>> or >>> local time. >>> >> The "-u" option of bhyve(8) will configure the RTC to present UTC time >> to the guest (default is localtime). > > wouldn't it be best if the -u option had an argument to give the offsett? > I had this problem with two windows hosts that were supposed to be in > different timezones. > I worked around it but... > Yes, it would be more flexible. FWIW the underlying vmmapi call and the ioctl don't need to change (i.e. the changes would be limited to bhyve(9)). best Neel > >> >> best >> Neel >> >>> -- >>> Thanks, >>> Dean E. Weimer >>> http://www.dweimer.net/ >>> _______________________________________________ >>> freebsd-virtualization@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >>> To unsubscribe, send any mail to >>> "freebsd-virtualization-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to >> "freebsd-virtualization-unsubscribe@freebsd.org" >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFgRE9FBehiEHpnc2REW=rduHjXhwjo89rpifqNAsrP5hm-ktQ>