Hi Brett, I'm not an expert on oVirt, but from my experience I would say you probably want to run the engine as a VM rather than on the bare metal. It has a lot of moving parts (PostgresSQL, jBoss, etc...) and they all fit well inside the VM. You can run it right on the bare-metal if you want though, as that was the preferred means for versions prior to 3.6 Also, you don't need to allocate the recommended 16GB of RAM to it if you are only running 5-10 VMs. You can probably get by with a 2-4GB VM which makes it more palatable. The thing to realize with oVirt is that the Engine is not the Hypervisor. The engine is just a management tool. If it crashes, all the VMs continue to run fine without it, so you can just start it back up and it will just resume managing everything fine. If you only have one physical host you don't need to really worry too much about redundancy. I don't think you can assign a host to two engines at the same time, but I might be wrong about that. If you want to migrate between a hosted engine and bare metal (or vice versa) you can use the engine-backup command to backup and then restore (same command, different arguments) the configuration. I've never done it, but it should work fine. For a system shutdown, I would shutdown all of the VMs (do the hosted engine last) and then just shutdown the box. I'm not sure if maintenance mode is actually required or not, so I'd defer to someone with more experience. I know I have done it this way and it doesn't seem to have caused any problems. For upgrades, I'd say shutdown all of the VMs (including the hosted engine) then apply your updates, reboot as necessary, and then start the VMs back up. Once everything is up ssh into the hosted engine, update it (yum update), reboot as necessary, and you are good to go. If you have a multi-host system that's a bit different. In that case put a host into maintenance mode; migrate all the VMs to other hosts; update it and reboot it; set it as active; migrate the VMs back and move on to the next host doing the same thing. the reason you want to shutdown all the VMs is that upgrades to the KVM/qemu packages may crash running VMs. I've seen this happen on Ubuntu, so I assume it's the same on RedHat/CentOS. As for the 4.0 branch, I'd give it a month or two of being out before you use it for a production system. I started with oVirt just as 3.6 came out and ran into some bugs that made it quite complicated. On the positive side, I learned a lot about how it works from getting advice on how to deal with those issues. :) On 2016-06-02 10:23 PM, users-request@ovirt.org wrote:
Message: 4 Date: Thu, 02 Jun 2016 21:23:49 -0400 From: "Brett I. Holcomb" <biholcomb@l1049h.com> To: users <users@ovirt.org> Subject: [ovirt-users] Questions on oVirt Message-ID: <1464917029.26446.133.camel@l1049h.com> Content-Type: text/plain; charset="utf-8"
After using oVirt for about three months I have some questions that really haven't been answered in any of the documentation, posts, or found in searching. ?Or maybe more correctly I've found some answers but am trying to put the pieces I've found together.
My setup is one physical host that used to run VMware ESXi6 and it handled running the VMs on an iSCSI LUN on a Synology 3615xs unit. ?I have one physical Windows workstation and all the servers, DNS, DHCP, file, etc. are VMs. ?The VMs are on an iSCSI LUN on the Synology.
* Hosted-engine deployment - Run Engine as a VM. ?This has the advantage of using one machine for host and running the Engine as a VM but what are the cons of it?
* Can I run the Engine on the host that will run the VMs without running it on a VM? ?That is I install the OS on my physical box, install Engine, then setup datastores (iSCSI LUN), networking etc.
* How do I run more than one Engine. ?With just one there is no redundancy so can I run another Engine that access the same Datacenter, etc. as the first? ?Or does each Engine have to have it's own Datacenter and the backup is achieved by migrating between the Engine's Datacenters as needed.
* Given I have a hosted Engine setup how can I "undo" it and ?get to running just the Engine on the host. ?Do I have to undo everything or can I just install another instance of the Engine on the host but not in a VM, move the VMs to it and then remove the Engine VM.
* System shutdown - If I shutdown the host what is the proper procedure? ?Go to global maintenance mode and then shutdown the host or do I have to do some other steps to make sure VMs don't get corrupted. ?On ESXi we'd put a host into maintenance mode after shutting down or moving the VMs so I assume it's the same here. Shutdown VMS since there is nowhere to move the VMS, go into global maintenance mode. Shutdown. ?On startup the ?Engine will come up, then I start my V Ms.##SELECTION_END##
* Upgrading engine and host - Do I have to go to maintenance mode then run yum to install the new versions on the host and engine and then run engine-setup or do I need to go into maintenance mode? ?I assume the 4.0 production install will be much more involved but hopefully keeping updated will make it a little less painful.
Thanks.
On Fri, 2016-06-03 at 03:49 -0300, Charles Tassell wrote:
Hi Brett,
I'm not an expert on oVirt, but from my experience I would say you probably want to run the engine as a VM rather than on the bare metal. It has a lot of moving parts (PostgresSQL, jBoss, etc...) and they all fit well inside the VM. You can run it right on the bare-metal if you want though, as that was the preferred means for versions prior to 3.6 Also, you don't need to allocate the recommended 16GB of RAM to it if you are only running 5-10 VMs. You can probably get by with a 2-4GB VM which makes it more palatable.
The thing to realize with oVirt is that the Engine is not the Hypervisor. The engine is just a management tool. If it crashes, all the VMs continue to run fine without it, so you can just start it back up and it will just resume managing everything fine. If you only have one physical host you don't need to really worry too much about redundancy. I don't think you can assign a host to two engines at the same time, but I might be wrong about that.
If you want to migrate between a hosted engine and bare metal (or vice versa) you can use the engine-backup command to backup and then restore (same command, different arguments) the configuration. I've never done it, but it should work fine.
For a system shutdown, I would shutdown all of the VMs (do the hosted engine last) and then just shutdown the box. I'm not sure if maintenance mode is actually required or not, so I'd defer to someone with more experience. I know I have done it this way and it doesn't seem to have caused any problems.
For upgrades, I'd say shutdown all of the VMs (including the hosted engine) then apply your updates, reboot as necessary, and then start the VMs back up. Once everything is up ssh into the hosted engine, update it (yum update), reboot as necessary, and you are good to go. If you have a multi-host system that's a bit different. In that case put a host into maintenance mode; migrate all the VMs to other hosts; update it and reboot it; set it as active; migrate the VMs back and move on to the next host doing the same thing. the reason you want to shutdown all the VMs is that upgrades to the KVM/qemu packages may crash running VMs. I've seen this happen on Ubuntu, so I assume it's the same on RedHat/CentOS.
As for the 4.0 branch, I'd give it a month or two of being out before you use it for a production system. I started with oVirt just as 3.6 came out and ran into some bugs that made it quite complicated. On the positive side, I learned a lot about how it works from getting advice on how to deal with those issues. :)
On 2016-06-02 10:23 PM, users-request@ovirt.org wrote:
Message: 4 Date: Thu, 02 Jun 2016 21:23:49 -0400 From: "Brett I. Holcomb" <biholcomb@l1049h.com> To: users <users@ovirt.org> Subject: [ovirt-users] Questions on oVirt Message-ID: <1464917029.26446.133.camel@l1049h.com> Content-Type: text/plain; charset="utf-8"
After using oVirt for about three months I have some questions that really haven't been answered in any of the documentation, posts, or found in searching. ?Or maybe more correctly I've found some answers but am trying to put the pieces I've found together.
My setup is one physical host that used to run VMware ESXi6 and it handled running the VMs on an iSCSI LUN on a Synology 3615xs unit. ?I have one physical Windows workstation and all the servers, DNS, DHCP, file, etc. are VMs. ?The VMs are on an iSCSI LUN on the Synology.
* Hosted-engine deployment - Run Engine as a VM. ?This has the advantage of using one machine for host and running the Engine as a VM but what are the cons of it?
* Can I run the Engine on the host that will run the VMs without running it on a VM? ?That is I install the OS on my physical box, install Engine, then setup datastores (iSCSI LUN), networking etc.
* How do I run more than one Engine. ?With just one there is no redundancy so can I run another Engine that access the same Datacenter, etc. as the first? ?Or does each Engine have to have it's own Datacenter and the backup is achieved by migrating between the Engine's Datacenters as needed.
* Given I have a hosted Engine setup how can I "undo" it and ?get to running just the Engine on the host. ?Do I have to undo everything or can I just install another instance of the Engine on the host but not in a VM, move the VMs to it and then remove the Engine VM.
* System shutdown - If I shutdown the host what is the proper procedure? ?Go to global maintenance mode and then shutdown the host or do I have to do some other steps to make sure VMs don't get corrupted. ?On ESXi we'd put a host into maintenance mode after shutting down or moving the VMs so I assume it's the same here. Shutdown VMS since there is nowhere to move the VMS, go into global maintenance mode. Shutdown. ?On startup the ?Engine will come up, then I start my V Ms.##SELECTION_END##
* Upgrading engine and host - Do I have to go to maintenance mode then run yum to install the new versions on the host and engine and then run engine-setup or do I need to go into maintenance mode? ?I assume the 4.0 production install will be much more involved but hopefully keeping updated will make it a little less painful.
Thanks.
Thanks for the input. That helps. I spent a lot of time with VMware and Vcenter so I'm having to readjust some thinking to fit with the oVirt model. As for 4.0 I have no intention of trying it until it's released and been out a while.
participants (2)
-
Brett I. Holcomb -
Charles Tassell