Re: RHEL virtualization
On Sat, Jan 23, 2021 at 03:14:53PM -0800, John Kennedy wrote: > At work, we have RHEL (-ish; some RHEL, some CentOS, some OEL). Mostly v7, > some v8. Since I'm doing the Covid work-from-home telecommute, I'm trying to > recreate some of my work infrastructure while trying to plan a bit towards > the future (migrating a lot of VMs to Azure). > > What I'd like to recreate is my existing kickstart infrastructure, where I > PXE boot the system, feed it anaconda goodness which dovetails into puppet > and I can generate a clean system from a template. Works great for VMWare > and HyperV, not so much for Azure but if I can generate a snapshot disk > image Azure can ingest, I'll be happy on that score. > > I've been very happy with bhyve for FreeBSD. I messed with VirtualBox for > a while (a long time ago), but with my tendency to track stable (think: > kernel modules) and keep very current on ports-from-source (frequent > package updates, upon which VirtualBox has MANY dependencies) made that a > poorer experience than I had with it on Windows. I've been very happy with > bhyve since it's basically baked right in. Let me restate some of this in a different way to maybe get some more thinking. Using the BHYVE_UEFI.fd from uefi-edk2-bhyve, I can boot my OEL8 (RHEL8 clone). That currently worries me because it has the big python-2.7 warning on it (as does uefi-edk2-bhyve-csm). On physical boxes, I've been able to grab a PXEBOOT ISO when the firmware lacks PXE booting, but I haven't got that to work yet for these. Those python worries are basically what is driving me to look elsewhere (like fighting with grub-bhyve and away from the only UEFI booting that I know about). I personally like PXE-booting a new system (and possibly making a gold image from that, depending on what I'm doing) because it basically answers that little auditor-voice in the back of my head that, in the event of some possible security problem, how do I know that my backups haven't been compromised. In all of those gigabytes, after all of the toxic recursive mindless non-logic, how do you *know*? My happy answer to myself is: "here is a configuration file that I can review, all the binaries are on the vendor's site or re-downloaded, here are the puppet customization rules, blam! done! 10 minutes later I have a clean system." In any case, that is why I'm chasing PXE booting, although I'd be interested in the way other people solve that problem. That really doesn't work that way in Azure, thus the gold images approach I'll probably have to take with them in the future. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
RHEL virtualization
At work, we have RHEL (-ish; some RHEL, some CentOS, some OEL). Mostly v7, some v8. Since I'm doing the Covid work-from-home telecommute, I'm trying to recreate some of my work infrastructure while trying to plan a bit towards the future (migrating a lot of VMs to Azure). What I'd like to recreate is my existing kickstart infrastructure, where I PXE boot the system, feed it anaconda goodness which dovetails into puppet and I can generate a clean system from a template. Works great for VMWare and HyperV, not so much for Azure but if I can generate a snapshot disk image Azure can ingest, I'll be happy on that score. I've been very happy with bhyve for FreeBSD. I messed with VirtualBox for a while (a long time ago), but with my tendency to track stable (think: kernel modules) and keep very current on ports-from-source (frequent package updates, upon which VirtualBox has MANY dependencies) made that a poorer experience than I had with it on Windows. I've been very happy with bhyve since it's basically baked right in. That being said, RHEL on bhyve has been a pain to figure out. The best I've done so far is using sysutils/grub2-bhyve to set up the boot CD, using BHYVE_UEFI.fd as UEFI firmware (sysutils/bhyve-firmware I think) and then getting at the console via net/tigervnc-viewer. Currently I'm fighting grub-bhyve's issue finding the kernel to load (if I'm finding the right problem reports, it doesn't seem to like modern XFS or ext4 partitions). I couldn't get net/ipxe to PXE boot anything, and I din't manage to get very far with sysutils/uefi-edk2-bhyve. And of course some of these are flagged with python2.7 isses. I'm not a fan of grub-bhyve, but that's mostly because you have to specify the full kernel-with-version path (changes every kernel update), but I figure I could make an expect-script that would figure it out if I could find a /boot filesystem type that grub-bhyve could "ls" properly. Ignoring my own setup details right now, what would someone currently bhyving RHEL recommend that I be doing right now? There is so much old information/documentation out there that I'm really second-guessing myself and probably chasing a bunch of dying ports. But someone on here must be happy with what they've got going for them. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: resizing a FreeBSD-12.1 vm on Azure
On Wed, Dec 23, 2020 at 01:48:09PM +, Wei Hu via freebsd-virtualization wrote: > Hello, > > You can use resize option on Azure portal to increase the CPU and RAM of your > VM. I believe you don't need to shut down the VM. Once you start the > resizing, Azure will take care of rebooting the VM for you. The public IP > will not change after the resizing. > > If you want to grow the disk size, you will have to shut down the VM. Find > the disk for your VM on the portal. It should have option to grow the size. > You may need to increase the FreeBSD filesystem size manually once the guest > boots up again. I have not done this. I just heard from someone who has done > this for Linux VM on Azure. I don't have a FreeBSD azure host, but I do have linux azure hosts. Yes, you can try to resize on the fly but there is a big banner up top that says: "If the virtual machine is currently running, changing its size will cause it to be restarted. Stopping the virtual machine may reveal additional sizes." My general experience with other hypervisors (HyperV, VMWare) and linux is that you can't resize CPU and memory without rebooting the host. For disks though, I've done that a lot. All my resizes on azure have, so far, required reboots. To be fair, I'm usually starting out with something small and then resizing it something appropriate (like a D2s_v3 -> DS3_v2), so there might be some resizing that wouldn't require a reboot. If you've got the VM tools installed on linux, it looks like it hooks the systemd process for orderly shutdown. Not sure what the equivalent for FreeBSD would be, but if "shutdown -r now" does an orderly shutdown for you (be careful... some things like databases interpret that as a request to do a quick-crash-stop), you're probably Ok. > > -Original Message- > > From: owner-freebsd-virtualizat...@freebsd.org > virtualizat...@freebsd.org> On Behalf Of tech-lists > > Sent: Tuesday, December 15, 2020 11:57 AM > > To: freebsd-virtualization@freebsd.org > > Subject: resizing a FreeBSD-12.1 vm on Azure > > > > Hello, > > > > Has anyone ever resized a freebsd vm on Azure? I don't mean just the disks. > > Really the whole point is to have more CPU and RAM. I have the option to do > > this via their portal, just select whats required and hit 'resize' but I'm > > a bit > > hesitant. I guess it'll work on a windows VM but anything else? > > > > If you did manage to do this, did you need to shut the VM down before > > resizing > > it? Was your external IP preserved or did it force you to have another one? > > Did > > you have to run anything else, like growfs? > > > > The author of https://forums.freebsd.org/threads/azure-vm.62440/ tried to do > > this in 2017 but wasn't able to at the time. All the IPs seem to survive reboots and even extended shutdown as long as you don't delete the network interface. If you delete the network interface, azure acts like it is throwing it back into the free pool and your chances of getting the same IP back are probably pretty slim. I've staticly assigned private IPs via the portal (which it'll let you do as long as nobody else has it assigned), but never tried that with a public IP. If you're just trying to play with RAM+CPU for some temporary workload and you don't want to play with disk at all because you're going to reduce it later then you won't need to worry about disk at all. If not... On linux, when I resize disk without rebooting, I try to set it up so that my disks are just XFS with no partitions on anything I know will grow. A non- issue with HyperV and VMWare where I can have lots of individual disks. In azure, you're sort of motivated to have everything on one disk, both for IOPS (you get more as the disk size goes up) and cost (you're charged in ^2 size ranges). That means partitions. For linux, I just lump everything dynamic into the last partition on the disk. When I resize live, I delete the entire partition (aiugh!), then recreate it making sure the type and start match up to what it used to be. If you haven't rebooted, you may need to partprobe or done your SCSI rescan tricks to get the OS to notice that you have more space, extra disks, etc. Then you grow the filesystem (xfs_growfs doesn't require reboot) and you're good! If your heart still isn't in your teeth for deleting a live partition while the OS is using it. For FreeBSD, I'm almost always using ZFS. In the cloud, I'm not using an encrypted GELI disk. That has been a show-stopper for me in home testing because you somehow need to resize that before resizing. For my Digital Ocean VM, I think I just tracked down the auto-resize on boot option and things generally worked. In Azure, it seems like you would want to make sure that is disabled. With new native-ZFS-encryption, maybe non-issue? I don't think azure in any way bundles CPU+RAM sizing with disk, so I don't thing you have to worry about any irreversible upsizing
