Re: [Users] Migrate simple configuration to self-hosted
- Original Message - > From: "Bob Doolittle" > To: "Yedidyah Bar David" , "Doron Fediuck" > > Cc: "users" , "Sandro Bonazzola" > Sent: Sunday, March 16, 2014 11:01:42 PM > Subject: Re: [Users] Migrate simple configuration to self-hosted > > Thanks for the careful reading. First to repeat my start point and goals: > > > I want to migrate my existing deployment to self-hosted. I have a simple > > deployment: > > > > A: Machine Fedora 20 > > B: libvirt VM (hosted on A) RHEL 6.5 running Engine 3.3.4-1 > > C: Machine RHEL 6.5 acts as Hypervisor/Host/Node (VDSM 4.13.3-4) > > > > ISO NFS Domain is on B > > Data (Master) NFS Domain is on C > > > > I want to migrate VM B to Machine C, as self-hosted, and free up Machine A > > Comments inline: > > On 03/16/2014 04:12 AM, Yedidyah Bar David wrote: > > This document assumes the most trivial settings, where the only thing > > you care about is simplicity, stability and minimizing downtime. It > > specifically does not try to use the minimum hardware possible. > > I see two demographics interested in migrating their current Ovirt > deployment to self-hosted: > 1 Those interested in freeing up a machine to use as another hypervisor. > 2 Those (like me) interested in freeing up a machine to use for another > purpose. > > Both groups want to free up a machine, presumably because they need more > resources. So I don't think our primary How-To should involve requiring > a new machine in order to migrate. I think many (like me) will find such > a solution intractable. 1. You are probably right :-) 2. You are still left with a machine to be reused in the end. 3. Another group of users is those who do not care about the extra machine but want the High Availability feature. 4. Please realize that this feature is still rather new, and while we hope it works well, there is still not very much experience with it. When it matures we can obviously write more documentation for more interesting use cases. You can, too :-) > > For those who have resources to spare, the current How-To seems fine, > but that might not be the majority. > > > I can think of several different directions: > > > Direction 2 > > === > > If you do not care about uptime - the simplest. > > > > Backup everything(!) - engine VM, other VMs, etc., then start from scratch: > > Reinstall OS on host C, install and deploy hosted-engine there, restore > > actual engine data from backup as described in the wiki. > > This sounds like the most interesting approach for my needs. I like > simple, and I can live with some downtime. > > Can you give me a complete list of things I should back up please? Not sure I really can. Please, if at all possible, take a complete backup of all relevant machines, just in case you miss something. A partial list: 1. The engine - using engine-backup 2. The ISO domain - not sure how, should be easy to reconstruct (just keep the images, and when you create the new iso domain you can simply copy them back in). 3. The VMs - probably using an export domain, not sure if that's the best way. > > Also (and this gets back to my comment about the usefulness of some kind > of date on pages visible to people who are not logged in) there are many > pages regarding backup/restore. Is there one in particular you are > thinking of/recommend? http://www.ovirt.org/Ovirt-engine-backup I agree there is a bit of mess regarding this. Searching for 'site:www.ovirt.org engine backup' returns quite many pages - I now looked at the first few. Some are user pages. Some refer to backing up VMs. And some refer to the engine. One specifically talks about the engine db only, not sure it should be touched. One was created to help organize this subject, and it has a link to the previous one I mentioned: http://www.ovirt.org/Backup_And_Restore_Engine > For backing up VMs I imagine it will not be > sufficient for me to export my VMs to an export domain somewhere remote > to host C (which I'll be scratching/reinstalling OS in order to target > self-hosted). Later if I restore actual engine data, and then import my > VMs, I imagine the UUIDs won't match? Or is the UUID preserved across > export/import? Sorry, I don't know. I think that should be enough. Adding Liron and Maor for that - can you please comment? > > What if I were to create a new temp NFS Storage Domain with my current > oVirt, someplace other than host C, and then move my VMs to it? Then, > after I set up self-hosted and restore my engine data, I could move them > back and nuke my temp domain? IIRC you can't connect a Storage (Data) domain to a diffe
Re: [Users] Migrate simple configuration to self-hosted
Thanks for the careful reading. First to repeat my start point and goals: I want to migrate my existing deployment to self-hosted. I have a simple deployment: A: Machine Fedora 20 B: libvirt VM (hosted on A) RHEL 6.5 running Engine 3.3.4-1 C: Machine RHEL 6.5 acts as Hypervisor/Host/Node (VDSM 4.13.3-4) ISO NFS Domain is on B Data (Master) NFS Domain is on C I want to migrate VM B to Machine C, as self-hosted, and free up Machine A Comments inline: On 03/16/2014 04:12 AM, Yedidyah Bar David wrote: This document assumes the most trivial settings, where the only thing you care about is simplicity, stability and minimizing downtime. It specifically does not try to use the minimum hardware possible. I see two demographics interested in migrating their current Ovirt deployment to self-hosted: 1 Those interested in freeing up a machine to use as another hypervisor. 2 Those (like me) interested in freeing up a machine to use for another purpose. Both groups want to free up a machine, presumably because they need more resources. So I don't think our primary How-To should involve requiring a new machine in order to migrate. I think many (like me) will find such a solution intractable. For those who have resources to spare, the current How-To seems fine, but that might not be the majority. I can think of several different directions: Direction 2 === If you do not care about uptime - the simplest. Backup everything(!) - engine VM, other VMs, etc., then start from scratch: Reinstall OS on host C, install and deploy hosted-engine there, restore actual engine data from backup as described in the wiki. This sounds like the most interesting approach for my needs. I like simple, and I can live with some downtime. Can you give me a complete list of things I should back up please? Also (and this gets back to my comment about the usefulness of some kind of date on pages visible to people who are not logged in) there are many pages regarding backup/restore. Is there one in particular you are thinking of/recommend? For backing up VMs I imagine it will not be sufficient for me to export my VMs to an export domain somewhere remote to host C (which I'll be scratching/reinstalling OS in order to target self-hosted). Later if I restore actual engine data, and then import my VMs, I imagine the UUIDs won't match? Or is the UUID preserved across export/import? What if I were to create a new temp NFS Storage Domain with my current oVirt, someplace other than host C, and then move my VMs to it? Then, after I set up self-hosted and restore my engine data, I could move them back and nuke my temp domain? I'm willing to be a guinea pig here, and report back what I find, if I can get a little more guidance as to avenues that might be useful to pursue. Many Thanks, Bob ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Migrate simple configuration to self-hosted
- Original Message - > From: "Doron Fediuck" > To: "Bob Doolittle" > Cc: "users" , "Sandro Bonazzola" , > "Yedidyah Bar David" > Sent: Thursday, March 13, 2014 9:23:03 PM > Subject: Re: [Users] Migrate simple configuration to self-hosted > > > > - Original Message - > > From: "Bob Doolittle" > > To: "users" > > Sent: Thursday, March 13, 2014 8:25:51 PM > > Subject: [Users] Migrate simple configuration to self-hosted > > > > Hi, > > > > I want to migrate my existing deployment to self-hosted. I have a simple > > deployment: > > > > A: Machine Fedora 20 > > B: libvirt VM (hosted on A) RHEL 6.5 running Engine 3.3.4-1 > > C: Machine RHEL 6.5 acts as Hypervisor/Host/Node (VDSM 4.13.3-4) > > > > ISO NFS Domain is on B > > Data (Master) NFS Domain is on C > > > > I want to migrate VM B to Machine C, as self-hosted, and free up Machine A > > > > When I look at these instructions: > > http://www.ovirt.org/Migrate_to_Hosted_Engine > > > > It starts with "I installed a new host with fedora 19". > > > > I don't understand this. Won't most people doing this migration want to > > start with their existing Hypervisor/Host/Node, and migrate their Engine > > to it? Do I really need a new 3rd machine, when my goal is to free up > > one of my 2 existing machines? This document assumes the most trivial settings, where the only thing you care about is simplicity, stability and minimizing downtime. It specifically does not try to use the minimum hardware possible. > > > > Or can I go ahead and assume these instructions are fine to apply to an > > existing Host already running VDSM 4.13.3-4? Not necessarily. I can definitely tell you that I stumbled into various problems during testing when trying to deploy a "dirty" host. Current deploy assumes a clean host, and might or might not work on an existing, in-use one. > > > > I would have (naively?) imagined that the typical migration would be > > something like: > > > > 0. Upgrade Engine and Host to 3.4 > > 1. Create a new VM You probably mean a new VM managed by your existing oVirt engine, not a new libvirt VM on host A. > > 2. Install OS on new VM, start it up > > 3. Backup current Engine > > 4. Stop current Engine (leave Host and VM running), change hostname > > (local and DNS), maybe power off for good luck until done More important is to disable relevant services (ovirt-engine, maybe others) from starting on reboot. It would be rather bad if you start it up after the new engine is up and two engines try to manage the same resources. > > 5. Login to new VM (probably using ssh unless there's a way to connect > > directly to the VM via Spice/VNC while the Engine is down) to: > > A. Assign previous Engine hostname to it (local and DNS), possibly > > reboot No need to change hostname (also on the old host, for that matter). You just have to make sure that the dns points at the new machine's IP address. > > B. Set it up as a self-hosted Engine That's the tough part. How are you going to do that? 'hosted-engine --deploy' will not help you here, it's not designed for this scenario. It creates the VM by itself. > > C. Restore backup to it > > D. Start up new engine > > > > What am I missing? I can think of several different directions: Direction 1 === Most similar to what you intended. 0. Upgrade to 3.4 1. Run 'hosted-engine --deploy' on C . As I said, this has a good chance to not work and/or cause other problems - do not try this if you care about uptime and without good backups. This will create a VM for you. Install OS+engine inside it, use backup and restore to migrate the engine itself, with the dns/disabling/etc as you described (and as described in the wiki). That's an interesting direction to take, but will probably require some manual fixes etc., if successful at all. Direction 2 === If you do not care about uptime - the simplest. Backup everything(!) - engine VM, other VMs, etc., then start from scratch: Reinstall OS on host C, install and deploy hosted-engine there, restore actual engine data from backup as described in the wiki. Direction 3 === Most complex, but might be quite risk-free, and require less downtime. 1. Create a new oVirt VM on C, install OS+engine on it, and backup/restore engine data from B to this new machine. Let's call it TempEngine. Technically speaking, at this poing, you'll get a self-hosted engine. But nothing will know about that except you. So now you want to migrate
Re: [Users] Migrate simple configuration to self-hosted
- Original Message - > From: "Bob Doolittle" > To: "users" > Sent: Thursday, March 13, 2014 8:25:51 PM > Subject: [Users] Migrate simple configuration to self-hosted > > Hi, > > I want to migrate my existing deployment to self-hosted. I have a simple > deployment: > > A: Machine Fedora 20 > B: libvirt VM (hosted on A) RHEL 6.5 running Engine 3.3.4-1 > C: Machine RHEL 6.5 acts as Hypervisor/Host/Node (VDSM 4.13.3-4) > > ISO NFS Domain is on B > Data (Master) NFS Domain is on C > > I want to migrate VM B to Machine C, as self-hosted, and free up Machine A > > When I look at these instructions: > http://www.ovirt.org/Migrate_to_Hosted_Engine > > It starts with "I installed a new host with fedora 19". > > I don't understand this. Won't most people doing this migration want to > start with their existing Hypervisor/Host/Node, and migrate their Engine > to it? Do I really need a new 3rd machine, when my goal is to free up > one of my 2 existing machines? > > Or can I go ahead and assume these instructions are fine to apply to an > existing Host already running VDSM 4.13.3-4? > > I would have (naively?) imagined that the typical migration would be > something like: > > 0. Upgrade Engine and Host to 3.4 > 1. Create a new VM > 2. Install OS on new VM, start it up > 3. Backup current Engine > 4. Stop current Engine (leave Host and VM running), change hostname > (local and DNS), maybe power off for good luck until done > 5. Login to new VM (probably using ssh unless there's a way to connect > directly to the VM via Spice/VNC while the Engine is down) to: > A. Assign previous Engine hostname to it (local and DNS), possibly > reboot > B. Set it up as a self-hosted Engine > C. Restore backup to it > D. Start up new engine > > What am I missing? > > Thanks, > Bob > Hi Bob, first of all F20 is not fully supported for the engine due to the JBoss version it uses. As for your questions, as any admin will tell you fresh start is usually much better than keeping old files and configurations which may or may not effect what you're trying to install. Since you're about to free a server to become a hypervisor, you can use one of your other hypervisors as the first hosted engine node. The current engine machine is not a hypervisor (missing vdsm, and probably other packages) so you'll need to add it as a host anyway to your hosted engine setup eventually. Having said that, you can try going your own way. This is something which may be technically possible nut we did not try or tested it before. Keep us updated, Doron ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Migrate simple configuration to self-hosted
Hi, I want to migrate my existing deployment to self-hosted. I have a simple deployment: A: Machine Fedora 20 B: libvirt VM (hosted on A) RHEL 6.5 running Engine 3.3.4-1 C: Machine RHEL 6.5 acts as Hypervisor/Host/Node (VDSM 4.13.3-4) ISO NFS Domain is on B Data (Master) NFS Domain is on C I want to migrate VM B to Machine C, as self-hosted, and free up Machine A When I look at these instructions: http://www.ovirt.org/Migrate_to_Hosted_Engine It starts with "I installed a new host with fedora 19". I don't understand this. Won't most people doing this migration want to start with their existing Hypervisor/Host/Node, and migrate their Engine to it? Do I really need a new 3rd machine, when my goal is to free up one of my 2 existing machines? Or can I go ahead and assume these instructions are fine to apply to an existing Host already running VDSM 4.13.3-4? I would have (naively?) imagined that the typical migration would be something like: 0. Upgrade Engine and Host to 3.4 1. Create a new VM 2. Install OS on new VM, start it up 3. Backup current Engine 4. Stop current Engine (leave Host and VM running), change hostname (local and DNS), maybe power off for good luck until done 5. Login to new VM (probably using ssh unless there's a way to connect directly to the VM via Spice/VNC while the Engine is down) to: A. Assign previous Engine hostname to it (local and DNS), possibly reboot B. Set it up as a self-hosted Engine C. Restore backup to it D. Start up new engine What am I missing? Thanks, Bob ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
