cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tutkowski, Mike" <Mike.Tutkow...@netapp.com>
Subject Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Date Wed, 17 Jan 2018 18:32:35 GMT
Once I run through the rest of my testing for the release candidate, I will turn my attention
back to this issue. Thanks!

> On Jan 17, 2018, at 10:53 AM, Nux! <nux@li.nux.ro> wrote:
> 
> Mike,
> 
> Ok, at least we can rule out hypervisor firewall side, the problem in your particular
case may be with the VR then, but if you feel further testing is not warranted then that's
fine.
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> ----- Original Message -----
>> From: "Tutkowski, Mike" <Mike.Tutkowski@netapp.com>
>> To: "dev" <dev@cloudstack.apache.org>
>> Sent: Wednesday, 17 January, 2018 15:08:21
>> Subject: Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
> 
>> The good part for 4.11 is that, per Rohit’s testing and comments, it seems like
>> it’s just an environment misconfiguration that is leading to these results.
>> That being the case, it’s not an issue we really need to be concerned with for
>> the 4.11 release candidate.
>> 
>> On 1/17/18, 7:56 AM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:
>> 
>>   Hi Lucian,
>> 
>>   Thanks for the e-mail. I haven’t yet gotten around to trying suggestions from
>>   others, but I did run that script you pointed me to and then rebooted the user
>>   VM that was running on that host. Unfortunately, I see the same results: no
>>   specified hostname and no IP address for that VM.
>> 
>>   In case you’re interested, here is the output from that script:
>> 
>>   Stopping firewall and allowing all traffic ...
>> 
>>   # Generated by iptables-save v1.4.21 on Wed Jan 17 07:36:15 2018
>>   *raw
>>   :PREROUTING ACCEPT [103:4120]
>>   :OUTPUT ACCEPT [103:4120]
>>   COMMIT
>>   # Completed on Wed Jan 17 07:36:15 2018
>>   # Generated by iptables-save v1.4.21 on Wed Jan 17 07:36:15 2018
>>   *nat
>>   :PREROUTING ACCEPT [2:133]
>>   :INPUT ACCEPT [0:0]
>>   :OUTPUT ACCEPT [0:0]
>>   :POSTROUTING ACCEPT [0:0]
>>   COMMIT
>>   # Completed on Wed Jan 17 07:36:15 2018
>>   # Generated by iptables-save v1.4.21 on Wed Jan 17 07:36:15 2018
>>   *mangle
>>   :PREROUTING ACCEPT [259:10360]
>>   :INPUT ACCEPT [259:10360]
>>   :FORWARD ACCEPT [0:0]
>>   :OUTPUT ACCEPT [259:10360]
>>   :POSTROUTING ACCEPT [259:10360]
>>   COMMIT
>>   # Completed on Wed Jan 17 07:36:15 2018
>>   # Generated by iptables-save v1.4.21 on Wed Jan 17 07:36:15 2018
>>   *filter
>>   :INPUT ACCEPT [494:19760]
>>   :FORWARD ACCEPT [0:0]
>>   :OUTPUT ACCEPT [494:19760]
>>   COMMIT
>>   # Completed on Wed Jan 17 07:36:15 2018
>> 
>>   Done!
>> 
>>   Thanks,
>>   Mike
>> 
>>   On 1/17/18, 2:04 AM, "Nux!" <nux@li.nux.ro> wrote:
>> 
>>       Mike,
>> 
>>       Run iptables-save on the hypervisor running an actual VM, from the rules above
>>       it looks like you are not running any (except system VMs). If you are running
a
>>       VM there, then something seems horribly wrong with the security groups.
>> 
>>       Another way to check for firewall issues is to disable it altogether, not sure
>>       how Ubuntu handles that, but you can use this little script[1]. If once you
do
>>       that your problems go away, then it's a firewall issue.
>> 
>>       [1] - http://dl.nux.ro/utils/iptflush.sh
>> 
>>       --
>>       Sent from the Delta quadrant using Borg technology!
>> 
>>       Nux!
>>       www.nux.ro
>> 
>>       ----- Original Message -----
>>> From: "Tutkowski, Mike" <Mike.Tutkowski@netapp.com>
>>> To: "dev" <dev@cloudstack.apache.org>
>>> Sent: Tuesday, 16 January, 2018 20:31:23
>>> Subject: Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
>> 
>>> Hi,
>>> 
>>> Here is the results of iptables-save (ebtables-save appears not to be
>>> installed):
>>> 
>>> # Generated by iptables-save v1.4.21 on Tue Jan 16 13:23:25 2018
>>> *nat
>>> :PREROUTING ACCEPT [1914053:9571571583]
>>> :INPUT ACCEPT [206:38888]
>>> :OUTPUT ACCEPT [4822:348457]
>>> :POSTROUTING ACCEPT [7039:610037]
>>> -A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
>>> -A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
>>> -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE
>>> --to-ports 1024-65535
>>> -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE
>>> --to-ports 1024-65535
>>> -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
>>> COMMIT
>>> # Completed on Tue Jan 16 13:23:25 2018
>>> # Generated by iptables-save v1.4.21 on Tue Jan 16 13:23:25 2018
>>> *mangle
>>> :PREROUTING ACCEPT [5214518:18468052456]
>>> :INPUT ACCEPT [2635017:8841915309]
>>> :FORWARD ACCEPT [214137:32291562]
>>> :OUTPUT ACCEPT [4343524:27594835296]
>>> :POSTROUTING ACCEPT [4558131:27627145644]
>>> -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
>>> COMMIT
>>> # Completed on Tue Jan 16 13:23:25 2018
>>> # Generated by iptables-save v1.4.21 on Tue Jan 16 13:23:25 2018
>>> *filter
>>> :INPUT ACCEPT [884752:56694574]
>>> :FORWARD ACCEPT [0:0]
>>> :OUTPUT ACCEPT [886649:47348857]
>>> :BF-cloudbr0 - [0:0]
>>> :BF-cloudbr0-IN - [0:0]
>>> :BF-cloudbr0-OUT - [0:0]
>>> :r-318-VM - [0:0]
>>> :s-316-VM - [0:0]
>>> :v-315-VM - [0:0]
>>> -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
>>> -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
>>> -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
>>> -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
>>> -A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate
>>> RELATED,ESTABLISHED -j ACCEPT
>>> -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
>>> -A FORWARD -i virbr0 -o virbr0 -j ACCEPT
>>> -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
>>> -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
>>> -A FORWARD -o cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0
>>> -A FORWARD -i cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0
>>> -A FORWARD -o cloudbr0 -j DROP
>>> -A FORWARD -i cloudbr0 -j DROP
>>> -A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
>>> -A BF-cloudbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
>>> -A BF-cloudbr0 -m physdev --physdev-is-in --physdev-is-bridged -j BF-cloudbr0-IN
>>> -A BF-cloudbr0 -m physdev --physdev-is-out --physdev-is-bridged -j
>>> BF-cloudbr0-OUT
>>> -A BF-cloudbr0 -m physdev --physdev-out eth0 --physdev-is-bridged -j ACCEPT
>>> -A BF-cloudbr0-IN -m physdev --physdev-in vnet1 --physdev-is-bridged -j v-315-VM
>>> -A BF-cloudbr0-IN -m physdev --physdev-in vnet2 --physdev-is-bridged -j v-315-VM
>>> -A BF-cloudbr0-IN -m physdev --physdev-in vnet4 --physdev-is-bridged -j s-316-VM
>>> -A BF-cloudbr0-IN -m physdev --physdev-in vnet5 --physdev-is-bridged -j s-316-VM
>>> -A BF-cloudbr0-IN -m physdev --physdev-in vnet6 --physdev-is-bridged -j r-318-VM
>>> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet1 --physdev-is-bridged -j
>>> v-315-VM
>>> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet2 --physdev-is-bridged -j
>>> v-315-VM
>>> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet4 --physdev-is-bridged -j
>>> s-316-VM
>>> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet5 --physdev-is-bridged -j
>>> s-316-VM
>>> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet6 --physdev-is-bridged -j
>>> r-318-VM
>>> -A r-318-VM -m physdev --physdev-in vnet6 --physdev-is-bridged -j RETURN
>>> -A r-318-VM -j ACCEPT
>>> -A s-316-VM -m physdev --physdev-in vnet4 --physdev-is-bridged -j RETURN
>>> -A s-316-VM -m physdev --physdev-in vnet5 --physdev-is-bridged -j RETURN
>>> -A s-316-VM -j ACCEPT
>>> -A v-315-VM -m physdev --physdev-in vnet1 --physdev-is-bridged -j RETURN
>>> -A v-315-VM -m physdev --physdev-in vnet2 --physdev-is-bridged -j RETURN
>>> -A v-315-VM -j ACCEPT
>>> COMMIT
>>> # Completed on Tue Jan 16 13:23:25 2018
>>> 
>>> Thanks!
>>> Mike
>>> 
>>> On 1/16/18, 1:32 AM, "Nux!" <nux@li.nux.ro> wrote:
>>> 
>>>   Hi Mike,
>>> 
>>>   First thing to check would be the firewall on the hypervisor.
>>>   Can you paste the output of iptables-save and ebtables-save ?
>>> 
>>>   --
>>>   Sent from the Delta quadrant using Borg technology!
>>> 
>>>   Nux!
>>>   www.nux.ro
>>> 
>>>   ----- Original Message -----
>>>> From: "Tutkowski, Mike" <Mike.Tutkowski@netapp.com>
>>>> To: "dev" <dev@cloudstack.apache.org>
>>>> Sent: Monday, 15 January, 2018 21:36:56
>>>> Subject: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
>>> 
>>>> Hi,
>>>> 
>>>> I noticed a problem related to hostnames/IP addressing on KVM with RC1 for
4.11.
>>>> 
>>>> I have a single Basic Zone with KVM (no other hypervisor type in use). My
two
>>>> KVM hosts are running on Ubuntu 14.04.
>>>> 
>>>> All system VMs come up and I create a new VM whose root disk resides on NFS
>>>> (alongside the root disks of the system VMs).
>>>> 
>>>> During the boot process, I see the following error:
>>>> 
>>>> https://imgur.com/LdTIcb2
>>>> 
>>>> When the VM has completed booting, it does not have the proper hostname and
has
>>>> no IP address:
>>>> 
>>>> https://imgur.com/PY47Lr8
>>>> 
>>>> Thoughts?
>>>> 
>>>> Thanks,
>>>> Mike
Mime
View raw message