[Users] Is it possible to run the node and engine on the same box?
Assume if it was possible fedora 16 with the additional repos would be suggested.
On 19/02/12 15:33, Brent Bolin wrote:
Assume if it was possible fedora 16 with the additional repos would be suggested.
Hi Brent, ovirt-node is read-only by nature (with the exception of some configurations). This means you cannot simply install rpm's on it. Instead both vdsm and the engine core needs to be pre-built on the node. This is not trivial, as the engine core requires many packages. If we assume you're using standard Fedora to be able to install rpm's, then we come to the next set of issues; co-hosting engine core with vdsm. There are things that need to be taken care of such as- - Adding the same host as a new host into the engine will cause reboot, which is not a good thing to do to the engine core during the installation process of the host.. - Fencing.... the co-hosted machine should not be fenced under any circumstances, in order to protect the engine core. - Networking... networking changes may impact the engine core as well. So here again we need to be careful. To conclude, it is possible to create a co-hosted machine used both by vdsm and engine-core. However, we need to verify the machine is not being rebooted. There are thoughts and maybe some work on achieving it, but it will take some time. -- /d “Funny,” he intoned funereally, “how just when you think life can't possibly get any worse it suddenly does.” --Douglas Adams, The Hitchhiker's Guide to the Galaxy
On Sun, Feb 19, 2012 at 10:10 AM, Doron Fediuck <dfediuck@redhat.com> wrote:
On 19/02/12 15:33, Brent Bolin wrote:
Assume if it was possible fedora 16 with the additional repos would be suggested.
Hi Brent, ovirt-node is read-only by nature (with the exception of some configurations). This means you cannot simply install rpm's on it. Instead both vdsm and the engine core needs to be pre-built on the node. This is not trivial, as the engine core requires many packages.
If we assume you're using standard Fedora to be able to install rpm's, then we come to the next set of issues; co-hosting engine core with vdsm. There are things that need to be taken care of such as- - Adding the same host as a new host into the engine will cause reboot, which is not a good thing to do to the engine core during the installation process of the host.. - Fencing.... the co-hosted machine should not be fenced under any circumstances, in order to protect the engine core. - Networking... networking changes may impact the engine core as well. So here again we need to be careful.
To conclude, it is possible to create a co-hosted machine used both by vdsm and engine-core. However, we need to verify the machine is not being rebooted. There are thoughts and maybe some work on achieving it, but it will take some time. --
/d
“Funny,” he intoned funereally, “how just when you think life can't possibly get any worse it suddenly does.” --Douglas Adams, The Hitchhiker's Guide to the Galaxy
Thanks for your reply. I've used XEN, ESX and now i'm focusing on KVM because that's where I think the technology is going. Very interested in the GUI management and not having to use windows for the engine database(ESX) or windows client(vSphere). The ovirt node ISO is still pretty buggy from what I've seen. stdout errors and the install just not working without more then one attempt. Even tried breaking in as root to install ovirt engine repos without success. Getting some odd errors when trying to set the root password to a known value. Any way I was able to install ovirt engine and vdsm by looking at the install guides using fedora 16 x86_64 DVD ISO. Doing a minimal install. Was able to bring up the mgmt UI. Saw exactly what your talking about requiring a reboot when adding a node host. Wasn't sure if that's the way it's suppose to work or not. Kinda like the surgeon working on his own hands!. Don't think the node registration fully installed itself because it re-booty up'ed itself. Networking isn't very clear if the above was tried. Example: using loopback 127.0.0.1 as the host node address. Not sure if the node host has to be reachable via a bridged network etc... . Thought it was worth the question because I'd like to know.
On Sun, 19 Feb 2012, Brent Bolin wrote:
I've used XEN, ESX and now i'm focusing on KVM because that's where I think the technology is going. Very interested in the GUI management and not having to use windows for the engine database(ESX) or windows client(vSphere).
The ovirt node ISO is still pretty buggy from what I've seen. stdout errors and the install just not working without more then one attempt. Even tried breaking in as root to install ovirt engine repos without success. Getting some odd errors when trying to set the root password to a known value.
Hmm, have not tried the ISO because we also run other things on the host such as gluster. Its just easier for us to start from a minimal F16 install.
Any way I was able to install ovirt engine and vdsm by looking at the install guides using fedora 16 x86_64 DVD ISO. Doing a minimal install.
Was able to bring up the mgmt UI. Saw exactly what your talking about requiring a reboot when adding a node host. Wasn't sure if that's the way it's suppose to work or not. Kinda like the surgeon working on his own hands!. Don't think the node registration fully installed itself because it re-booty up'ed itself.
Once things come back up you should be able to restart disarmed and have it talked to the engine.
Networking isn't very clear if the above was tried. Example: using loopback 127.0.0.1 as the host node address. Not sure if the node host has to be reachable via a bridged network etc... .
There are a LOT of different ways to set it up, I have dual nicks so I bond them together with: [root@virt1 network-scripts]# more ifcfg-bond0 DEVICE=bond0 MTU=9000 BOOTPROTO=no ONBOOT=yes BONDING_OPTS="mode=4 miimon=100" BRIDGE=ovirtmgmt [root@virt1 network-scripts]# more ifcfg-eth0 DEVICE=eth0 MTU=9000 ONBOOT=yes MASTER=bond0 SLAVE=yes [root@virt1 network-scripts]# more ifcfg-eth1 DEVICE=eth1 MTU=9000 ONBOOT=yes MASTER=bond0 SLAVE=yes I don't really like the requirement for ovirtmgmt, since we already have a private bridge I wish I could use that, but since overt requires it... [root@virt1 network-scripts]# more ifcfg-ovirtmgmt DEVICE=ovirtmgmt ONBOOT=yes BOOTPROTO=static IPADDR=10.13.1.101 NETMASK=255.255.255.0 GATEWAY=10.13.1.1 TYPE=Bridge Ovirt will use that IP for things like spice, so your going to need to make sure it is reachable at least locally. I then have two vlans, VLAN2 for private and VLAN8 for public IP traffic from my VMs. [root@virt1 network-scripts]# more ifcfg-bond0.2 DEVICE=bond0.2 BOOTPROTO=none ONBOOT=yes VLAN=yes BRIDGE=private [root@virt1 network-scripts]# more ifcfg-bond0.8 DEVICE=bond0.8 BOOTPROTO=none ONBOOT=yes VLAN=yes BRIDGE=public [root@virt1 network-scripts]# more ifcfg-private DEVICE=private ONBOOT=yes BOOTPROTO=none TYPE=Bridge [root@virt1 network-scripts]# more ifcfg-public DEVICE=public ONBOOT=yes BOOTPROTO=none TYPE=Bridge A setup like the above is not required, just works for us.
Thought it was worth the question because I'd like to know.
I have been running KVM/OpenVZ/Xen for years, but I am very new (read a few weeks) to ovirt. I like it much better then our manual / scrips we use in production today and hope to have it in production as soon as I figure out a few more things.
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
The ovirt node ISO is still pretty buggy from what I've seen. stdout errors
I believe this was fixed in the latest ISO build, and fwiw it's completely cosmetic.
and the install just not working without more then one attempt.
Can you provide more details? Otherwise we can't fix the issues.
Even tried breaking in as root to install ovirt engine repos without success. Getting some odd errors when trying to set the root password to a known value.
Echoing what Doron said in his reply... Don't try to install oVirt Engine onto oVirt Node. The stateless nature of oVirt Node makes running the mgmt server there not possible. If you want to run the Engine on the same machine as other oVirt controlled VMs, then you should use a heavyweight install of Fedora and put the Engine and VDSM side by side on that. The fact that you can't easily run oVirt Engine on the oVirt Node is not a bug, or a sign of instability. It's simply not what oVirt Node was designed for. Perry
Replies inserted into the message. On Sun, Feb 19, 2012 at 2:37 PM, Perry Myers <pmyers@redhat.com> wrote:
The ovirt node ISO is still pretty buggy from what I've seen. stdout errors
I believe this was fixed in the latest ISO build, and fwiw it's completely cosmetic.
and the install just not working without more then one attempt.
Can you provide more details? Otherwise we can't fix the issues.
Just that the installer says it fails and the only option is to reboot. Sometimes going into the troubleshooting option and selecting "reinstall" fixes it other times not. Makes me wonder if ovirt iso install can't handle pre existing partions/lvm remnants.
Even tried breaking in as root to install ovirt engine repos without success. Getting some odd errors when trying to set the root password to a known value.
Echoing what Doron said in his reply... Don't try to install oVirt Engine onto oVirt Node. The stateless nature of oVirt Node makes running the mgmt server there not possible.
I don't understand this statement. Are you talking about firewall stateless connections?
If you want to run the Engine on the same machine as other oVirt controlled VMs, then you should use a heavyweight install of Fedora and put the Engine and VDSM side by side on that.
The fact that you can't easily run oVirt Engine on the oVirt Node is not a bug, or a sign of instability. It's simply not what oVirt Node was designed for.
I understand this. However in these days of my old age I don't run half a dozen chassis, skins, power supplies, hd's, mb etc... like to use virtualization hosts for my personal lab environment. Right now I accomplish this using a kvm host and virt-manager The real power from what I read about the ovirt road map is using native kvm, management server without the need of windows server, vmotion type clustering etc... I am going to look over Doron notes. Specifically the networking. Cheers... keep up the good work. btb
Perry
On 02/19/2012 07:17 PM, Brent Bolin wrote:
and the install just not working without more then one attempt.
Can you provide more details? Otherwise we can't fix the issues.
Just that the installer says it fails and the only option is to reboot. Sometimes going into the troubleshooting option and selecting "reinstall" fixes it other times not. Makes me wonder if ovirt iso install can't handle pre existing partions/lvm remnants.
It should be able to. Over the past months we've made numerous fixes for this. However, if you have already installed oVirt Node to the disk, you need to select the 'Reinstall' option from the Grub menu (listed under Troubleshooting menu option in Grub) So perhaps what you're seeing is Install vs. Reinstall. In any case, we should handle this more gracefully or at least provide some add'l diagnostics to indicate the core reason why it failed to install. If you could file a bug against the ovirt-node component in bugzilla, we can definitely try to make this more user friendly.
Even tried breaking in as root to install ovirt engine repos without success. Getting some odd errors when trying to set the root password to a known value.
Echoing what Doron said in his reply... Don't try to install oVirt Engine onto oVirt Node. The stateless nature of oVirt Node makes running the mgmt server there not possible.
I don't understand this statement. Are you talking about firewall stateless connections?
The filesystem in oVirt Node is stateless. If you attempt to install an rpm, when you reboot the changes are lost. The entire filesystem is in RAM aside from a few select configuration files that are manually persisted to a 5MB config partition on disk.
If you want to run the Engine on the same machine as other oVirt controlled VMs, then you should use a heavyweight install of Fedora and put the Engine and VDSM side by side on that.
The fact that you can't easily run oVirt Engine on the oVirt Node is not a bug, or a sign of instability. It's simply not what oVirt Node was designed for.
I understand this. However in these days of my old age I don't run half a dozen chassis, skins, power supplies, hd's, mb etc... like to use virtualization hosts for my personal lab environment. Right now I accomplish this using a kvm host and virt-manager
Right. We're not suggesting that you can't use oVirt in this way. You should absolutely be able to use a single physical host running Fedora 16 and on that host run both the oVirt Engine as well as vdsm, so that you can have an 'oVirt in a single box' setup. All we were saying here is that you can't use oVirt Node specifically to do the above, since it's a livecd with a stateless filesystem and contains 'just enough OS' to run virtual machines, and no where near enough OS to run a mgmt server. Now, what should be possible... is to run oVirt Node and run on that node a single VM that is not managed by oVirt Engine, and run the engine inside that VM. However in order to do this, you'd need to get past a chicken-egg issue with starting a VM on oVirt Node prior to it being registered with the oVirt Engine. I wonder if we should expose a special command/config option in oVirt Node to allow it to run a single VM so that oVirt Engine can be colocated as a VM. Anyone have any thoughts on that?
The real power from what I read about the ovirt road map is using native kvm, management server without the need of windows server, vmotion type clustering etc...
All of that is accurate
I am going to look over Doron notes. Specifically the networking.
Cheers... keep up the good work.
Thanks for the feedback and experimentation :) Perry
On 20/02/12 03:55, Perry Myers wrote:
On 02/19/2012 07:17 PM, Brent Bolin wrote:
and the install just not working without more then one attempt.
Can you provide more details? Otherwise we can't fix the issues.
Just that the installer says it fails and the only option is to reboot. Sometimes going into the troubleshooting option and selecting "reinstall" fixes it other times not. Makes me wonder if ovirt iso install can't handle pre existing partions/lvm remnants.
It should be able to. Over the past months we've made numerous fixes for this.
However, if you have already installed oVirt Node to the disk, you need to select the 'Reinstall' option from the Grub menu (listed under Troubleshooting menu option in Grub)
So perhaps what you're seeing is Install vs. Reinstall. In any case, we should handle this more gracefully or at least provide some add'l diagnostics to indicate the core reason why it failed to install.
If you could file a bug against the ovirt-node component in bugzilla, we can definitely try to make this more user friendly.
Even tried breaking in as root to install ovirt engine repos without success. Getting some odd errors when trying to set the root password to a known value.
Echoing what Doron said in his reply... Don't try to install oVirt Engine onto oVirt Node. The stateless nature of oVirt Node makes running the mgmt server there not possible.
I don't understand this statement. Are you talking about firewall stateless connections?
The filesystem in oVirt Node is stateless. If you attempt to install an rpm, when you reboot the changes are lost. The entire filesystem is in RAM aside from a few select configuration files that are manually persisted to a 5MB config partition on disk.
If you want to run the Engine on the same machine as other oVirt controlled VMs, then you should use a heavyweight install of Fedora and put the Engine and VDSM side by side on that.
The fact that you can't easily run oVirt Engine on the oVirt Node is not a bug, or a sign of instability. It's simply not what oVirt Node was designed for.
I understand this. However in these days of my old age I don't run half a dozen chassis, skins, power supplies, hd's, mb etc... like to use virtualization hosts for my personal lab environment. Right now I accomplish this using a kvm host and virt-manager
Right. We're not suggesting that you can't use oVirt in this way. You should absolutely be able to use a single physical host running Fedora 16 and on that host run both the oVirt Engine as well as vdsm, so that you can have an 'oVirt in a single box' setup.
All we were saying here is that you can't use oVirt Node specifically to do the above, since it's a livecd with a stateless filesystem and contains 'just enough OS' to run virtual machines, and no where near enough OS to run a mgmt server.
Now, what should be possible... is to run oVirt Node and run on that node a single VM that is not managed by oVirt Engine, and run the engine inside that VM. However in order to do this, you'd need to get past a chicken-egg issue with starting a VM on oVirt Node prior to it being registered with the oVirt Engine.
I wonder if we should expose a special command/config option in oVirt Node to allow it to run a single VM so that oVirt Engine can be colocated as a VM. Anyone have any thoughts on that?
I think worth opening a discussion on arch list.
The real power from what I read about the ovirt road map is using native kvm, management server without the need of windows server, vmotion type clustering etc...
All of that is accurate
I am going to look over Doron notes. Specifically the networking.
Cheers... keep up the good work.
Thanks for the feedback and experimentation :)
Perry _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 19/02/12 19:21, Brent Bolin wrote:
On Sun, Feb 19, 2012 at 10:10 AM, Doron Fediuck <dfediuck@redhat.com> wrote:
On 19/02/12 15:33, Brent Bolin wrote:
Assume if it was possible fedora 16 with the additional repos would be suggested.
Hi Brent, ovirt-node is read-only by nature (with the exception of some configurations). This means you cannot simply install rpm's on it. Instead both vdsm and the engine core needs to be pre-built on the node. This is not trivial, as the engine core requires many packages.
If we assume you're using standard Fedora to be able to install rpm's, then we come to the next set of issues; co-hosting engine core with vdsm. There are things that need to be taken care of such as- - Adding the same host as a new host into the engine will cause reboot, which is not a good thing to do to the engine core during the installation process of the host..
We are adding a flag (host property) to avoid host reboot at the end of host installation. This will be available soon and we are thinking to expose it only through the API (not in the UI).
- Fencing.... the co-hosted machine should not be fenced under any circumstances, in order to protect the engine core. - Networking... networking changes may impact the engine core as well. So here again we need to be careful.
To conclude, it is possible to create a co-hosted machine used both by vdsm and engine-core. However, we need to verify the machine is not being rebooted. There are thoughts and maybe some work on achieving it, but it will take some time. --
/d
“Funny,” he intoned funereally, “how just when you think life can't possibly get any worse it suddenly does.” --Douglas Adams, The Hitchhiker's Guide to the Galaxy
Thanks for your reply.
I've used XEN, ESX and now i'm focusing on KVM because that's where I think the technology is going. Very interested in the GUI management and not having to use windows for the engine database(ESX) or windows client(vSphere).
The ovirt node ISO is still pretty buggy from what I've seen. stdout errors and the install just not working without more then one attempt. Even tried breaking in as root to install ovirt engine repos without success. Getting some odd errors when trying to set the root password to a known value.
Any way I was able to install ovirt engine and vdsm by looking at the install guides using fedora 16 x86_64 DVD ISO. Doing a minimal install.
Was able to bring up the mgmt UI. Saw exactly what your talking about requiring a reboot when adding a node host. Wasn't sure if that's the way it's suppose to work or not. Kinda like the surgeon working on his own hands!. Don't think the node registration fully installed itself because it re-booty up'ed itself.
Networking isn't very clear if the above was tried. Example: using loopback 127.0.0.1 as the host node address. Not sure if the node host has to be reachable via a bridged network etc... .
Thought it was worth the question because I'd like to know. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 02/20/2012 09:12 AM, Livnat Peer wrote:
On 19/02/12 19:21, Brent Bolin wrote:
On Sun, Feb 19, 2012 at 10:10 AM, Doron Fediuck<dfediuck@redhat.com> wrote:
On 19/02/12 15:33, Brent Bolin wrote:
Assume if it was possible fedora 16 with the additional repos would be suggested.
Hi Brent, ovirt-node is read-only by nature (with the exception of some configurations). This means you cannot simply install rpm's on it. Instead both vdsm and the engine core needs to be pre-built on the node. This is not trivial, as the engine core requires many packages.
If we assume you're using standard Fedora to be able to install rpm's, then we come to the next set of issues; co-hosting engine core with vdsm. There are things that need to be taken care of such as- - Adding the same host as a new host into the engine will cause reboot, which is not a good thing to do to the engine core during the installation process of the host..
We are adding a flag (host property) to avoid host reboot at the end of host installation. This will be available soon and we are thinking to expose it only through the API (not in the UI).
I think there are two different reboot's being discussed here: 1. reboot at end of an ovirt-node installation by ovirt node installation process (anaconda?) 2. reboot at end of configuring a full blown host (i.e., pre installed fedora), by ovirt-engine. I'm assuming perry was talking on #1. doron is talking on #2, since all-in-one is not relevant at this point for #1. 2. reb
I think there are two different reboot's being discussed here: 1. reboot at end of an ovirt-node installation by ovirt node installation process (anaconda?)
This cannot be solved as long as oVirt Node requires 'installation to disk'. Once we remove the requirement for installing oVirt Node to disk, we won't need a reboot at the end of the install... because there will no longer even be an install. So we get the above for free once we move to the fully stateless config model. In order to do that we'll need vdsm to retrieve all of its config from oVirt Engine on every boot/connection. The current thinking for 'stateless' in oVirt Node is that Node will be responsible for 'just enough config' to: 1. boot 2. get mgmt interface configured so that mgmt agent (vdsm) can talk to its server Every other aspect of configuration can be handled then by the mgmt agent, keeping oVirt Node bootstrapping simple and also neutral in terms of what each mgmt agent would require. The challenge here is the registration model that vdsm uses. How vdsm registers will need to change in order for this to work. Basically, if a particular node is already registered, vdsm will need to talk to oVirt Engine, the Engine will need to recognize that that particular node is already registered and treat it as such rather than trying to 're-register' it. Perry
On Sun, 19 Feb 2012, Brent Bolin wrote:
Assume if it was possible fedora 16 with the additional repos would be suggested.
Its possible, I tried it and it does work, but I ended up ditching the idea because I wanted all my node boxes to be identical. What I am working on now is getting ovirt-engine to work as a guest on a node. First setup ovirt on a stand alone box Setup everything the way you want it Create a overt-engine VM Shutdown the first ovirt-engine (the guest ovirt-engine will stay up) Import the DB into the VM engine Start the ovirt-engine on the VM If you need to start a cold cluster you fire up all your nodes and then manually start ovirt-engine VM on one of the nodes.
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
participants (6)
-
Brent Bolin -
Doron Fediuck -
Itamar Heim -
Livnat Peer -
Nathan Stratton -
Perry Myers