You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by "Tutkowski, Mike" <Mi...@netapp.com> on 2018/01/15 21:36:56 UTC
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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by Rohit Yadav <ro...@shapeblue.com>.
Mike, can you check if dnsmasq is running on your VR. Does it work, if you ssh to your VR restart dnsmasq and retry dhclient (or reboot the user VM)?
FYI - Per PR2211, systemvmtemplate improvements I made it reload dnsmasq than reboot it. Dnsmasq is only rebooted when cfg files in /etc/dnsmasq.d changes but dhcp opts/hosts file (that contains dhcp rules for new VMs) changes, dnsmasq is only reloaded. This was done to avoid dhcp failures when you launch several VMs, restart dnsmasq every time may fail dhcp discovery queries from user VMs.
- Rohit
<https://cloudstack.apache.org>
________________________________
From: Tutkowski, Mike <Mi...@netapp.com>
Sent: Tuesday, January 16, 2018 3:06:56 AM
To: dev@cloudstack.apache.org
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
rohit.yadav@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
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! <nu...@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" <Mi...@netapp.com>
>> To: "dev" <de...@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" <Mi...@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!" <nu...@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" <Mi...@netapp.com>
>>> To: "dev" <de...@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!" <nu...@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" <Mi...@netapp.com>
>>>> To: "dev" <de...@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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by Nux! <nu...@li.nux.ro>.
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" <Mi...@netapp.com>
> To: "dev" <de...@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" <Mi...@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!" <nu...@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" <Mi...@netapp.com>
> > To: "dev" <de...@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!" <nu...@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" <Mi...@netapp.com>
> > > To: "dev" <de...@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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
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" <Mi...@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!" <nu...@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" <Mi...@netapp.com>
> To: "dev" <de...@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!" <nu...@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" <Mi...@netapp.com>
> > To: "dev" <de...@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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
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!" <nu...@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" <Mi...@netapp.com>
> To: "dev" <de...@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!" <nu...@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" <Mi...@netapp.com>
> > To: "dev" <de...@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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by Rohit Yadav <ro...@shapeblue.com>.
Mike,
I tested basic zone KVM (with and without SG enabled, and with/without local storage enabled) and could not reproduce the issue. My guest VMs got ip/hostname from dnsmasq on the shared guest network VR. I tested it using CentOS7 based KVM box [1], but not with Ubuntu based boxes. It's quite possible the issue you're seeing may be environment/configuration related.
[1] monkeybox: https://github.com/rhtyd/monkeybox
- Rohit
<https://cloudstack.apache.org>
________________________________
From: Nux! <nu...@li.nux.ro>
Sent: Wednesday, January 17, 2018 2:34:24 PM
To: dev
Subject: Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
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
rohit.yadav@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
----- Original Message -----
> From: "Tutkowski, Mike" <Mi...@netapp.com>
> To: "dev" <de...@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!" <nu...@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" <Mi...@netapp.com>
> > To: "dev" <de...@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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by Nux! <nu...@li.nux.ro>.
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" <Mi...@netapp.com>
> To: "dev" <de...@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!" <nu...@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" <Mi...@netapp.com>
> > To: "dev" <de...@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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
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!" <nu...@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" <Mi...@netapp.com>
> To: "dev" <de...@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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by Nux! <nu...@li.nux.ro>.
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" <Mi...@netapp.com>
> To: "dev" <de...@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
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by Wei ZHOU <us...@gmail.com>.
Hi Mike,
Is dhclient installed in your vm ?
If you have the original password, try to log into the vm, and configure
the ip manually. By this way, we can see if there is issue with networking.
I faced the issue that some vms fail to fetch hostname and password because
of some miconfigurations in the vms.
-Wei
2018-01-16 21:39 GMT+01:00 Tutkowski, Mike <Mi...@netapp.com>:
> Hi Wei,
>
> No, there is no VLAN in operation here.
>
> Per your suggestion, I migrated the VM to the host that’s running the VR
> and rebooted the VM after migrating it to this host, but it still didn’t
> get its hostname or IP address.
>
> Thanks!
> Mike
>
> On 1/16/18, 1:32 AM, "Wei ZHOU" <us...@gmail.com> wrote:
>
> Hi Mike,
>
> Have you configured vlan ? What if you migrate VM to same host as VR
> and
> reboot the VM ?
>
> -Wei
>
> 2018-01-15 22:36 GMT+01:00 Tutkowski, Mike <Mike.Tutkowski@netapp.com
> >:
>
> > 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
> >
>
>
>
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
Hi Wei,
No, there is no VLAN in operation here.
Per your suggestion, I migrated the VM to the host that’s running the VR and rebooted the VM after migrating it to this host, but it still didn’t get its hostname or IP address.
Thanks!
Mike
On 1/16/18, 1:32 AM, "Wei ZHOU" <us...@gmail.com> wrote:
Hi Mike,
Have you configured vlan ? What if you migrate VM to same host as VR and
reboot the VM ?
-Wei
2018-01-15 22:36 GMT+01:00 Tutkowski, Mike <Mi...@netapp.com>:
> 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
>
Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address
Posted by Wei ZHOU <us...@gmail.com>.
Hi Mike,
Have you configured vlan ? What if you migrate VM to same host as VR and
reboot the VM ?
-Wei
2018-01-15 22:36 GMT+01:00 Tutkowski, Mike <Mi...@netapp.com>:
> 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
>