[Cloudmin GPL] Xen machines fail to ping

I recently bought a dedicated server from OVH with a clean install of CentOS 5.5 64-bit, webmin, Virtualmin and Cloudmin, and have been trying to set up some xen machines with no success.

Basically, I get three Failover IP's with my server, which can only be used on my server. I have the following IP's: 188.165.5.110 (02:00:00:1b:90:45) 188.165.5.120 (00:50:56:09:a4:22) 188.165.5.130 (02:00:00:d8:26:73)

OVH's system makes you do the following changes to the xen machine: /etc/network/interfaces auto lo eth0 iface lo inet loopback iface eth0 inet static address "IP Failover" netmask 255.255.255.255 broadcast "IP Failover" post-up route add "Dedicated Server IP but end in .254" dev eth0 post-up route add default gw "Dedicated Server IP but end in .254" post-down route del "Dedicated Server IP but end in .254" dev eth0 post-down route del default gw "Dedicated Server IP but end in .254"

/etc/resolv.conf nameserver 213.186.33.99

What I used to do on my previous ovh server would have been to set up the xen machine with the ip failover, and the gateway 188.165.5.254, and once it was up and running, ssh in, make the changes, and reboot the machine. But this does not appear to be working on the new server. Thew new server's xen machines are un-pingable. The only differences between this server and the last one are as follows:

Old: New: Ubuntu 8.04 64-bit centOS 5.5 64-bit No firewall in Virtualmin Firewall in Virtualmin Disk images for Xen LVM for Xen

Can anyone help? If I get this working, I'm thinking of purchasing a Cloudmin pro license (wanted to see if I can get things working in Cloudmin GPL first)

Status: 
Closed (fixed)

Comments

After some more investivation, I've established the following. On the old server, the XEN IP's were bridged to eth0. On the new server, it has two interfaces for external use, eth0 has my public ip, and eth1 is set up with the ip 10.0.0.1 (for a VPN setup).

Yet neither are available to bridge to, the XEN IP's are bridged to xenbr0 (I disabled virtbr0 after testing and finding that it also didn't work with the VM's). Is there anything I have to change to allow me to bridge the XEN vm's to eth0 on the new server?

Also, I get an error on the new sever when saving settings (It's Cloudmin specific), picture is attached. I would be more than willing to pay/donate to get this problem resolved ASAP

Ok, nevermind, xenbr0 is now working, and IP's are working at long last. The error when saving settings in Cloudmin still applies tho

That error about type_real_desc is an odd one .. it indicates that Cloudmin is trying to display a non-virtual system, which shouldn't be possible in the GPL version.

If you SSH in and run the command cloudmin list-systems --type real , what does it output?

I get the following error:

[root@XXXXXXXX ~]# cloudmin list-systems --type real No systems specified

Lists some or all registered managed systems.

cloudmin list-systems [--multiline | --name-only | --id-only] [--all-hosts] | [--host name]* [--group name]* [--type xen|this]* [--os oscode]* [--owner name]* [--status status-code|"up"|"wm"|"bad"] [--host-type type|"all"] [--last-period | --period-ago N]

Running cloudmin list-systems on it's own produces this: [root@XXXXXXXX ~]# cloudmin list-systems Hostname Type Description

XXXXXXXX.kimsufi.com Master This system static.XXXXXXXXXXX.info Xen Xen VM for www.XXXXXXanime.net

If you like, I could login to your system myself and see what is going wrong. I'd need to root SSH access though ..

If that is possible, please contact me directly at jcameron@virtualmin.com

I've sent you an email with the details, subject line matches this thread title, and you can expect it from static [dot] anime [at] hotmail [dot] com

Thanks for the login - I see the bug, which is triggered only when you enable categorization of systems by type and are using the GPL version. I have patched your system to fix it, and will include the fix in the 4.7 Cloudmin release.

Ah, cool, thanks very much Jamie!!

Automatically closed -- issue fixed for 2 weeks with no activity.