You are here
DRivard - Mon, 2012/02/20 - 06:57
Hi everyone,
I was trying to get the turnkey bugzilla template working on my OpenVZ server.
So I copied the link of the template and execute those command lines:
cd /vz/template/cache
wget http://downloads.sourceforge.net/project/turnkeylinux/openvz/turnkey-bug...
Then I executed the command lines to create my vz container by hand. When the container was initialized, I entered it with the normale vzctl enter 19
# vzlist -a
19 70 running 192.168.2.19 bugzilla-turnkey
When I tried to reach it through the web browser, it didn't workout. I though it was a network probleme. So I started debuging to find out that it is the networking configuration that was wrong. Here is what the /etc/network/interface file contained:
# UNCONFIGURED INTERFACES
# remove the above line if you edit this file
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet dhcp
To really get it to work I needed to completely switch the configuration file to:
auto venet0
iface venet0 inet manual
up ifconfig venet0 up
up ifconfig venet0 127.0.0.2
up route add default dev venet0
down route del default dev venet0
down ifconfig venet0 down
auto venet0:0
iface venet0:0 inet static
address 192.168.2.19
netmask 255.255.255.255
Why isn't it by default the venet adapter? How do we get it to work under plain OpenVZ by default or automatically? Is it a proxmox requirement?
thank you!
Forum:
Tags:
I've never used vanilla OVZ
I have only ever used OVZ via Proxmox and in there it defaults to venet so not sure why you're experiencing this behaviour.
AFAIK these templates haven't been extensively tested under vanilla OVZ (the OVZ users I've come across use Proxmox) so perhaps it is a quirk that is only noticable in your usage scenario (ie manual OVZ). I'm sure the devs would be open to modifying it if it means a better end user experience.
When I get a chance I'll test launching from the commandline. And perhaps I could modify a template like you have explained above and see how it goes, both manually and via the WebUI. If we can make it work better for you, whilst maintaining the OOTB experience for PVE users then we all win! :)
BTW I've lodged a bug report.
I've never used Proxmox
Later when I'll be home I'll paste the exacte command lines to create the VM from Turnkey templates.
thank you for your support.
Dom
Try editing /etc/network/interface as DRivard did
But obviously you'll need to change the "192.168.1.19" to the appropriate IP address that you want for your VM.
I'm assuming that what's happening here is that under Proxmox this file is created when lauching the container (hence why it works flawlessly with OpenVZ under Proxmox) but vanilla OpenVZ obviously doesn't do that step for you.
Out of interest, do you have another (untouched) OpenVZ template to look at? If so could you post the contents of /etc/network/interface. Otherwise I'll download one at some point and have a look.
As the only extensive testing these OVZ templates have had is when launched by Proxmox, I think that is why this bug has snuck through. We'll work it out and ask the devs to push through a bugfix. If my suspicion is correct about Proxmox creating the interface file on launch then changing this won't effect the PVE OVZ templates (ie they can remain the same).
OpenVZ /etc/network/interfaces after initiating the container
Good morning guys,
Here is what the /etc/network/interfaces looks like when you initiate a new container following these commands:
Thanks
And good morning to you too! :)
Out of interest here is the commands that the PVE WebUI does behind the scenes when a new (working) OVZ container is created (from the WebUI):
Note I included the line breaks to make it easier to read - the lines that start with a space followed by a switch actually belong to the line above.
And here is the contents of the (working) /etc/network/interface file:
# This configuration file is auto-generated. # # WARNING: Do not edit this file, your changes will be lost. # Please create/edit /etc/network/interfaces.head and # /etc/network/interfaces.tail instead, their contents will be # inserted at the beginning and at the end of this file, respectively. # # NOTE: it is NOT guaranteed that the contents of /etc/network/interfaces.tail # will be at the very end of this file. # # Auto generated lo interface auto lo iface lo inet loopback # Auto generated venet0 interface auto venet0 iface venet0 inet manual up ifconfig venet0 up up ifconfig venet0 127.0.0.2 up route add default dev venet0 down route del default dev venet0 down ifconfig venet0 down iface venet0 inet6 manual up route -A inet6 add default dev venet0 down route -A inet6 del default dev venet0 auto venet0:0 iface venet0:0 inet static address 192.168.1.125 netmask 255.255.255.255The only significant difference I can see (besides that the interface file is populated properly) is that PVE first uses the vzcreate command with --ipset as a switch. I'm not sure if the vzcreate command is unique to PVE (I'm suspecting that perhaps it is?) or whether that is just another OVZ command? What happens if you try to use that command?
I'm assuming that the commands that you use normally work for other (non TKL) OVZ templates (or I guess otherwise this wouldn't be an issue).
I should have been clearer, when I was asking for the /etc/network/interface from "another (untouched) OpenVZ template to look at" I meant a non-TKL template that you could compare. Do you have one handy?
One other thing... (aka Ramblings of a PVE fanboy...)
I'm not sure what OS you are using for your OVZ server and this may not be relevant but ProxmoxVE is a fantastic (Debian based) setup IMO. It has OVZ (obviously) but also KVM (so you can also host alternative OS such as Win) and a nice WebUI up front as well as powerful commandline tools. It also supports server clustering and alternative storage such as SAN and iSCSI OOTB.
Obviously if your current setup works well and fulfills your needs, then there's no reason to fix what isn't broken. But if you're looking for a little bit more from your OVZ server then PVE could be worth a look. I'm still using the v1.9 stable, but v2.0rc1 is looking pretty sweet so I think I'll start having a play with that really soon.
Although PVE comes as an ISO download it can be installed to an existing Debian install. v1.9 is Lenny based (oldstable) but v2.0 is Squeeze based (stable). Once PVE 2.0 goes stable the PVE devs will supply a 1.9->2.0 upgrade script (and v1x will be EOL).
If you just want to have a look you can download the ISO and it installs fine to VirtualBox. If you go straight for v2.0rc1 then you'll want to make sure to run "aptitude update && aptitude full-upgrade" after install to update to the latest packages. It's under heavy development - but the latest version (updated with the above command) is pretty much feature complete AFAIK.
As an extra bonus PVE devs have just announced that following on from the official TKL release of OVZ templates, the latest v2.0 PVE (when updated as above) comes complete with a 'TKL-channel' for downloading TKL OVZ templates from within the PVE WebUI! It's almost too easy now!
PS sorry to hijack your thread with my unashamed PVE advertisement. For the record I am not affiliated with PVE in any way, just a very satisfied user since v1.3.
ipset
Hi Jeremy,
I checked out this morning and on plain OpenVZ the command "ipset" doesn't even exist neither vzcreate.
The available options are:
I am running Debian Squeeze 6.0.4, I am not against testing PVE at all, I just normally install everything myself so I know the underground configuration of it and then I can debug myself. Plus I tested recently OpenVZ Web Panel that turned out to be a very complete solution with a very nice Web GUI.
How does it work for clustering because that is one thing interesting of PVE. The second good argument is the ISO to ovz conversion. I'll give it a try later next week.
Regards
Thanks for your extensive response
I actually posted some more info that I discovered on the bug report. But here it is again here:
As for PVE - TBH I haven't used the clustering feature myself. I just think it sounds really cool! :) From what I've read v2.0 includes the facility to create High Availablitiy clusteris too.
And perhaps I mislead you somewhat, it doesn't support ISO to OVZ conversion, it just allows you to download the TKL OVZ templates from the WebUI (and they work OOTB!) You can also install from ISO (to KVM VM though - not OVZ). TBH it sounds like you are streets ahead of me in tech knowledge so I suggest that you just test in VBox (on a desktop) to see what you think. As I say, if your server is doing what you want, then perhaps we just need to work this bug out so it works OOTB...
PVE
VBox will not give the true look and feel of testing PVE. I will install on two little server and I will test the clustering feature. We already use OpenVZ clustering with DRBD, so if one node fail the second node transfer the harddisk and all the container are restarted. So this way our clients never go down.
I will investigate the VZ tools to see, if this is where the IP gets correctly assign.
Cheers.
Seeing as I was the one who pushed so hard for OVZ...
Perhaps I should take it on myself to work to resolve this issue. I have updated the Bug report. Please note that the above (clunky) workaround does indeed seem to work...
I can't replicate this bug on PVE!?!?
I downloaded the turnkey-core-11.3-lucid-x86-openvz.tar.gz template to my PVE host.
Before I started, I untarred the template and checked /etc/network/interfaces:
Obviously it was the same as yours. I then ran the commands you posted:
It starts as expected and this is what /etc/network/interfaces looks like in the running container:
# This configuration file is auto-generated. # # WARNING: Do not edit this file, your changes will be lost. # Please create/edit /etc/network/interfaces.head and # /etc/network/interfaces.tail instead, their contents will be # inserted at the beginning and at the end of this file, respectively. # # NOTE: it is NOT guaranteed that the contents of /etc/network/interfaces.tail # will be at the very end of this file. # # Auto generated lo interface auto lo iface lo inet loopback # Auto generated venet0 interface auto venet0 iface venet0 inet manual up ifconfig venet0 up up ifconfig venet0 127.0.0.2 up route add default dev venet0 down route del default dev venet0 down ifconfig venet0 down iface venet0 inet6 manual up route -A inet6 add default dev venet0 down route -A inet6 del default dev venet0 auto venet0:0 iface venet0:0 inet static address 192.168.1.206 netmask 255.255.255.255And everything works, which wasn't quite what I expected...
So not sure where to go next...
Solution found, here's the quick fix!
As reported in the bug I finally found the solution to this issue.
If you want the turnkey linux OVZ template to work you have to rename them starting by ubuntu:
e.g.: turnkey-postgresql-11.3-lucid-x86-openvz.tar.gz needs to be rename ubuntu-turnkey-postgresql-11.3-lucid-x86-openvz.tar.gz
This is due to a naming convention on of OpenVZ and the distribution they support. You can look a the script I created here: http://drivard.com/2012/02/19/download-turnkey-linux-virtual-appliances-for-openvz-at-once/ it will help you download all the turnkey OVZ template in one shot and start using them within a vanilla OpenVZ without the networking issue. This is a quick fix until TKL fix their naming convention.
Regards.
If it's just naming convention then use PVE OVZ templates
They are exactly the same bexcept they use the PVE naming convention so are named like this:
ubuntu-10.04-turnkey-core_11.3-1_i386.tar.gzThe PVE naming convention is only required so the templates show correctly in the PVE WebUI (beacuse as I demonstrated even with the 'plain' TKL OVZ naming they still work ok). Seeing as they start with 'ubuntu' perhaps that is enough for them to work with vanilla OVZ? Perhaps you could give one a try to confirm. They can be on SourceForge in 'Files' under 'PVE' here: http://sourceforge.net/projects/turnkeylinux/files/pve/
If they work ok, then TKL won't have to maintain 2 versions of the OVZ templates. I think the only reason why the devs have 2 sets of OVZ templates was so the vanilla templates follow the naming convention that all the other appliance formats follow. But if that is what causes the problem, and the PVE-OVZ templates work ok, then that defaets the purpose of 2 sets...
PS thanks for all your your work on getting to the bottom of this bug.
TKL appliances have firstboot scripts to set these
But as OVZ containers don't have a true console that doesn't work. So you need to manually run them. The TKL devs have made a script which will run the required firstboot scripts, so to get started:
PVE templates works fine in OpenVZ Vanilla
Good monday morning,
Sorry I missed the PVE template being the same as OVZ, I confirmed that on a Vanilla OpenVZ server, the template works fine. I tested ubuntu-10.04-turnkey-wordpress_11.3-1_i386.tar.gz and it worked out of the box, so I think you are right saying that TKL should only support one type of OVZ templates and not two forks. But renaming them PVE/OpenVZ would be great, that way we will know which one to choose, if PVE doesn't ring a bell to us.
Regards.
Thanks for confirming
Yes I think that is the solution.
I noticed that the TKL devs have recently changed the appliance page links to point straight to the downloads and as the PVE interface interacts with the TKL image repository in the background it should be fairly trivial to just put all the images in the OpenVZ folder (and adjust the PVE script to the new location).
Add new comment