Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address

[Nux!]

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" 
> To: "dev" 
> 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

[Wei ZHOU]

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 :

> 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: KVM on ubuntu

[Özhan Rüzgar Karaman]

On Tue, Jan 16, 2018 at 10:49 AM, Wido den Hollander  wrote:

>
>
> On 01/16/2018 06:36 AM, Özhan Rüzgar Karaman wrote:
>
>> Hi Paul;
>> Ubuntu 16.04 has systemd installed and it directly controls libvirtd
>> process so if you add -d to /etc/default/libvirt-bin file libvirtd tries
>> to
>> control to its self and then you have problem, you could not
>> stop/start/restart libvirtd service via systemd. Only adding -l flag to
>> libvirtd_opts is enough for Cloudstack.
>>
>> We also make no change on /etc/init/libvirt-bin.conf file for 16.04
>>
>>
I recheck my previous email and my written info below is for 14.04 (i
mistakely wrote 16.04 for below info)

For Ubuntu 16.04 you need to add both -d and -l flags for
>> /etc/default/libvirt-bin
>> file.
>>
>>
> Indeed! Mainly the -l flag is important to make libvirtd listen on TCP
> sockets which are required for live migration.
>
> Wido
>
>
> Thanks
>> Özhan
>>
>> On Mon, Jan 15, 2018 at 11:34 PM, Paul Angus 
>> wrote:
>>
>> Hey guys,
>>>
>>> I'm no Ubuntu Guru, so I want to check that I have this right
>>>
>>> Our documentation says:
>>> --
>>> On Ubuntu: modify /etc/default/libvirt-bin
>>> Add "-l" to the following line
>>> libvirtd_opts="-d"
>>> so it looks like:
>>> libvirtd_opts="-d -l"
>>> ---
>>>
>>> I've found on Ubuntu 16.04 that you seem to need:
>>> /etc/default/libvirt-bin
>>> to have:
>>> libvirtd_opts="-l"
>>>
>>> and
>>> /etc/init/libvirt-bin.conf
>>> to have:
>>> env libvirtd_opts="-d -l"
>>>
>>> Can anyone confirm/deny this and should it also be this way for Ubuntu
>>> 14.04 ?
>>>
>>>
>>> If so I'll update the documentation...
>>>
>>>
>>> cheers
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Paul Angus
>>>
>>>
>>> paul.an...@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

[Rohit Yadav]

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






From: Tutkowski, Mike 
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.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

RE: KVM on ubuntu

[Paul Angus]

Thanks guys,

😊 I guessed that you were meaning 14.04 Özhan.

@wido are you saying that you need the -l flag in '/etc/default/libvirt-bin' 
for live migration or only in '/etc/init/libvirt-bin.conf'  ?


Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Özhan Rüzgar Karaman [mailto:oruzgarkara...@gmail.com] 
Sent: 16 January 2018 09:05
Cc: dev@cloudstack.apache.org
Subject: Re: KVM on ubuntu

On Tue, Jan 16, 2018 at 10:49 AM, Wido den Hollander  wrote:

>
>
> On 01/16/2018 06:36 AM, Özhan Rüzgar Karaman wrote:
>
>> Hi Paul;
>> Ubuntu 16.04 has systemd installed and it directly controls libvirtd 
>> process so if you add -d to /etc/default/libvirt-bin file libvirtd 
>> tries to control to its self and then you have problem, you could not 
>> stop/start/restart libvirtd service via systemd. Only adding -l flag 
>> to libvirtd_opts is enough for Cloudstack.
>>
>> We also make no change on /etc/init/libvirt-bin.conf file for 16.04
>>
>>
I recheck my previous email and my written info below is for 14.04 (i mistakely 
wrote 16.04 for below info)

For Ubuntu 16.04 you need to add both -d and -l flags for
>> /etc/default/libvirt-bin
>> file.
>>
>>
> Indeed! Mainly the -l flag is important to make libvirtd listen on TCP 
> sockets which are required for live migration.
>
> Wido
>
>
> Thanks
>> Özhan
>>
>> On Mon, Jan 15, 2018 at 11:34 PM, Paul Angus 
>> 
>> wrote:
>>
>> Hey guys,
>>>
>>> I'm no Ubuntu Guru, so I want to check that I have this right
>>>
>>> Our documentation says:
>>> --
>>> On Ubuntu: modify /etc/default/libvirt-bin Add "-l" to the following 
>>> line libvirtd_opts="-d"
>>> so it looks like:
>>> libvirtd_opts="-d -l"
>>> ---
>>>
>>> I've found on Ubuntu 16.04 that you seem to need:
>>> /etc/default/libvirt-bin
>>> to have:
>>> libvirtd_opts="-l"
>>>
>>> and
>>> /etc/init/libvirt-bin.conf
>>> to have:
>>> env libvirtd_opts="-d -l"
>>>
>>> Can anyone confirm/deny this and should it also be this way for 
>>> Ubuntu
>>> 14.04 ?
>>>
>>>
>>> If so I'll update the documentation...
>>>
>>>
>>> cheers
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Paul Angus
>>>
>>>
>>> paul.an...@shapeblue.com
>>> www.shapeblue.com
>>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>>>
>>>
>>>
>>>
>>>
>>

Re: KVM on ubuntu

[Wei ZHOU]

In my experience,

/etc/init/libvirt-bin.conf is used for ubuntu 12.04 (add "-d -l", any
change in /etc/default/libvirt-bin has no impact)
/etc/default/libvirt-bin is used for ubuntu 16.04. We use -l . "-d" will
cause libvirt-bin fails to restart. If libvirt-bin fails to restart, please
execute "systemctl stop libvirt-bin.socket" then restart libvirt-bin.
/etc/default/libvirtd is used for ubuntu 17.04 . same as ubuntu 16.04 (-d
is not needed).

-Wei


2018-01-16 6:36 GMT+01:00 Özhan Rüzgar Karaman :

> Hi Paul;
> Ubuntu 16.04 has systemd installed and it directly controls libvirtd
> process so if you add -d to /etc/default/libvirt-bin file libvirtd tries to
> control to its self and then you have problem, you could not
> stop/start/restart libvirtd service via systemd. Only adding -l flag to
> libvirtd_opts is enough for Cloudstack.
>
> We also make no change on /etc/init/libvirt-bin.conf file for 16.04
>
> For Ubuntu 16.04 you need to add both -d and -l flags for
> /etc/default/libvirt-bin
> file.
>
> Thanks
> Özhan
>
> On Mon, Jan 15, 2018 at 11:34 PM, Paul Angus 
> wrote:
>
> > Hey guys,
> >
> > I'm no Ubuntu Guru, so I want to check that I have this right
> >
> > Our documentation says:
> > --
> > On Ubuntu: modify /etc/default/libvirt-bin
> > Add "-l" to the following line
> > libvirtd_opts="-d"
> > so it looks like:
> > libvirtd_opts="-d -l"
> > ---
> >
> > I've found on Ubuntu 16.04 that you seem to need:
> > /etc/default/libvirt-bin
> > to have:
> > libvirtd_opts="-l"
> >
> > and
> > /etc/init/libvirt-bin.conf
> > to have:
> > env libvirtd_opts="-d -l"
> >
> > Can anyone confirm/deny this and should it also be this way for Ubuntu
> > 14.04 ?
> >
> >
> > If so I'll update the documentation...
> >
> >
> > cheers
> >
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>

Re: [4.11] VLAN, VXLAN same bridge - Tags are not defined for physical network in the zone id=1

[Remi Bergsma]

Hi Lucian,

Not 100% sure but it looks like you have multiple physical networks with 
type=guest? If that’s the case, you need tags to distinguish between the two. 
You’d tag the physical networks, and also do that in network offerings. Then 
CloudStack knows which one to use.

Regards,
Remi
 

On 15/01/2018, 17:08, "Nux!"  wrote:

Hi,

I'm just trying out 4.11 RC1 with a new network config.
I have created a bridge and used it for 2 separate guest networks (ie 
traffic labels).
See http://img.nux.ro/M7V-Selection_313.png

Everything went ok, except when trying to create the very first network I 
am getting this error:
"Tags are not defined for physical network in the zone id=1"

More logs here:
http://tmp.nux.ro/L4k-no-tags-defined.txt

Any ideas what I am doing wrong? Is it even supported to use the same 
bridge for VLAN _and_ VXLAN traffic?

Regards,
Lucian


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

please discuss on the VOTE thread Kristian. Give your -1 with explanation
there.

On Tue, Jan 16, 2018 at 11:40 AM, Kristian Liivak  wrote:

> Daan,
>
> For us and i guess for many others public cloud and vps providers its very
> big hole.
> Imagine that 10-20 chinese guys have made fraud orders and 10-20 vps are
> provisioned.
> We dealing with fradulent orders daily basis.
> Some time later abusers will get catch in the act and vpses will be
> terminated.
> If your customer increase is considerable, most probably one or more ips
> will be given to new customers during same day.
> Newly created instances get then abusers keys and root passwords.
> If new instance uses only keys, root password will be never changed.
> Abusers need just log in with them old passwords and bitcoin mining or
> spamming will be started again.
> Some of smarter customers are able to connect dots and serviceprovider
> reputation will be damaged seriously.
>
>
> Lugupidamisega / Regards
>
> Kristian Liivak
>
> Tegevjuht / Executive director
>
> WaveCom As
> Endla 16, 10142 Tallinn
> Estonia
> Tel: +3726850001
> Gsm: +37256850001
> E-mail: k...@wavecom.ee
> Skype: kristian.liivak
> http://www.wavecom.ee
> http://www.facebook.com/wavecom.ee
>
> - Original Message -
> From: "Daan Hoogland" 
> To: "users" 
> Cc: "dev" 
> Sent: Monday, January 15, 2018 1:49:04 PM
> Subject: Re: [DISCUSS] Freezing master for 4.11
>
> Kristian,
>
>
>
> On Mon, Jan 15, 2018 at 11:49 AM, Kristian Liivak  wrote:
> >>
> > ...
>
>
>
> As for this one:
>
> > Also there is major security hole. When instance is destroyd and expunged
> >> > and new instance is created with old IP all old data is unaffected in
> VR
> >> > New instance will get then old root password and  ssh key if they were
> >> > present in VR
> >>
> > I don't see how this is a security issue. The user won't get in and
> update the key and password to get in. No harm done or am I overlooking
> something?
>
>
> --
> Daan
>



-- 
Daan

Re: [DISCUSS] Freezing master for 4.11

[Rohit Yadav]

Hi Kristian,

Can you test and confirm that you can reproduce the issue with 4.11.0.0-rc1?


- Rohit






From: Kristian Liivak 
Sent: Tuesday, January 16, 2018 4:10:17 PM
To: users
Cc: dev
Subject: Re: [DISCUSS] Freezing master for 4.11

Daan,

For us and i guess for many others public cloud and vps providers its very big 
hole.
Imagine that 10-20 chinese guys have made fraud orders and 10-20 vps are 
provisioned.
We dealing with fradulent orders daily basis.
Some time later abusers will get catch in the act and vpses will be terminated.
If your customer increase is considerable, most probably one or more ips will 
be given to new customers during same day.
Newly created instances get then abusers keys and root passwords.
If new instance uses only keys, root password will be never changed.
Abusers need just log in with them old passwords and bitcoin mining or spamming 
will be started again.
Some of smarter customers are able to connect dots and serviceprovider 
reputation will be damaged seriously.


Lugupidamisega / Regards

Kristian Liivak

Tegevjuht / Executive director

WaveCom As
Endla 16, 10142 Tallinn
Estonia
Tel: +3726850001
Gsm: +37256850001
E-mail: k...@wavecom.ee
Skype: kristian.liivak
http://www.wavecom.ee
http://www.facebook.com/wavecom.ee


rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

- Original Message -
From: "Daan Hoogland" 
To: "users" 
Cc: "dev" 
Sent: Monday, January 15, 2018 1:49:04 PM
Subject: Re: [DISCUSS] Freezing master for 4.11

Kristian,



On Mon, Jan 15, 2018 at 11:49 AM, Kristian Liivak  wrote:
>>
> ...



As for this one:

> Also there is major security hole. When instance is destroyd and expunged
>> > and new instance is created with old IP all old data is unaffected in VR
>> > New instance will get then old root password and  ssh key if they were
>> > present in VR
>>
> I don't see how this is a security issue. The user won't get in and
update the key and password to get in. No harm done or am I overlooking
something?


--
Daan

Re: HA issues

[Rohit Yadav]

Hi Lucian,


If you're talking about the new HostHA feature (with KVM+nfs+ipmi), please 
refer to following docs:

http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/hosts.html#out-of-band-management

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Host+HA


We'll need to you look at logs perhaps create a JIRA ticket with the logs and 
details? If you saw ipmi based reboot, then host-ha indeed tried to recover 
i.e. reboot the host, once hostha has done its work it would schedule HA for VM 
as soon as the recovery operation succeeds (we've simulator and kvm based 
marvin tests for such scenarios).


Can you see it making attempt to schedule VM ha in logs, or any failure?


- Rohit






From: Nux! 
Sent: Tuesday, January 16, 2018 12:47:56 AM
To: dev
Subject: [4.11] HA issues

Hi,

I see there's a new HA engine for KVM and IPMI support which is really nice, 
however it seems hit and miss.
I have created an instance with HA offering, kernel panicked one of the 
hypervisors - after a while the server was rebooted via IPMI probably, but the 
instance never moved to a running hypervisor and even after the original 
hypervisor came back it was still left in Stopped state.
Is there any extra things I need to set up to have proper HA?

Regards,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: HA issues

[Nux!]

I'll reinstall my setup and try again, just to be sure I'm working on a clean 
slate.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" 
> Sent: Tuesday, 16 January, 2018 11:29:51
> Subject: Re: HA issues

> Hi Lucian,
> 
> 
> If you're talking about the new HostHA feature (with KVM+nfs+ipmi), please 
> refer
> to following docs:
> 
> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/hosts.html#out-of-band-management
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Host+HA
> 
> 
> We'll need to you look at logs perhaps create a JIRA ticket with the logs and
> details? If you saw ipmi based reboot, then host-ha indeed tried to recover
> i.e. reboot the host, once hostha has done its work it would schedule HA for 
> VM
> as soon as the recovery operation succeeds (we've simulator and kvm based
> marvin tests for such scenarios).
> 
> 
> Can you see it making attempt to schedule VM ha in logs, or any failure?
> 
> 
> - Rohit
> 
> 
> 
> 
> 
> 
> From: Nux! 
> Sent: Tuesday, January 16, 2018 12:47:56 AM
> To: dev
> Subject: [4.11] HA issues
> 
> Hi,
> 
> I see there's a new HA engine for KVM and IPMI support which is really nice,
> however it seems hit and miss.
> I have created an instance with HA offering, kernel panicked one of the
> hypervisors - after a while the server was rebooted via IPMI probably, but the
> instance never moved to a running hypervisor and even after the original
> hypervisor came back it was still left in Stopped state.
> Is there any extra things I need to set up to have proper HA?
> 
> Regards,
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue

Re: [4.11] VLAN, VXLAN same bridge - Tags are not defined for physical network in the zone id=1

[Nux!]

Thanks Remi, that was it!

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Remi Bergsma" 
> To: "dev" 
> Sent: Tuesday, 16 January, 2018 10:16:17
> Subject: Re: [4.11] VLAN, VXLAN same bridge - Tags are not defined for 
> physical network in the zone id=1

> Hi Lucian,
> 
> Not 100% sure but it looks like you have multiple physical networks with
> type=guest? If that’s the case, you need tags to distinguish between the two.
> You’d tag the physical networks, and also do that in network offerings. Then
> CloudStack knows which one to use.
> 
> Regards,
> Remi
> 
> 
> On 15/01/2018, 17:08, "Nux!"  wrote:
> 
>Hi,
>
>I'm just trying out 4.11 RC1 with a new network config.
>I have created a bridge and used it for 2 separate guest networks (ie 
> traffic
>labels).
>See http://img.nux.ro/M7V-Selection_313.png
>
>Everything went ok, except when trying to create the very first network I 
> am
>getting this error:
>"Tags are not defined for physical network in the zone id=1"
>
>More logs here:
>http://tmp.nux.ro/L4k-no-tags-defined.txt
>
>Any ideas what I am doing wrong? Is it even supported to use the same 
> bridge for
>VLAN _and_ VXLAN traffic?
>
>Regards,
>Lucian
>
>
>--
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
> www.nux.ro

[cloud-init] change on how DHCP leases are scanned to fetch VR address

[Marc-Aurèle Brothier]

Hi all,

I pushed a PR for cloud-init to change the way the DHCP leases are scanned
to retrieve the VR ip address. Currently it does scan the lease files in
reverse time order (newest file first) to get the VR address and if that
address does not work, it falls back on the default gateway address.

My change is to scan the DHCP lease in alphabetical order of the iterface
names, retrieving all potential address from those file and iterating among
them in the same order to find the VR address, with the latest entry on the
default gateway address.
This is to overcomes issue when additional interfaces are added to the VM
which are also configured with a DHCP server which is not part of
cloudstack. In the current situtation, cloud-init would try to use the
address from that newest interface.

Does that sound like a good change to everyone? Or would it break, slow
down, your current VM boot process ?

https://code.launchpad.net/~ma-brothier/cloud-init/+git/cloud-init/+merge/336145

Cheers,
Marc-Aurèle

Re: [cloud-init] change on how DHCP leases are scanned to fetch VR address

[Nux!]

Also interested as the CentOS project is about to patch their cloud-init with 
this:
http://li.nux.ro/download/nux/tmp/cloud-init7/0050-cloudstack-dhcp-lease-file.patch

Might as well save them the trouble and go directly for Marc's patch.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Marc-Aurèle Brothier" 
> To: "dev" 
> Sent: Tuesday, 16 January, 2018 13:43:58
> Subject: [cloud-init] change on how DHCP leases are scanned to fetch VR 
> address

> Hi all,
> 
> I pushed a PR for cloud-init to change the way the DHCP leases are scanned
> to retrieve the VR ip address. Currently it does scan the lease files in
> reverse time order (newest file first) to get the VR address and if that
> address does not work, it falls back on the default gateway address.
> 
> My change is to scan the DHCP lease in alphabetical order of the iterface
> names, retrieving all potential address from those file and iterating among
> them in the same order to find the VR address, with the latest entry on the
> default gateway address.
> This is to overcomes issue when additional interfaces are added to the VM
> which are also configured with a DHCP server which is not part of
> cloudstack. In the current situtation, cloud-init would try to use the
> address from that newest interface.
> 
> Does that sound like a good change to everyone? Or would it break, slow
> down, your current VM boot process ?
> 
> https://code.launchpad.net/~ma-brothier/cloud-init/+git/cloud-init/+merge/336145
> 
> Cheers,
> Marc-Aurèle

Re: [DISCUSS] running sVM and VR as HVM on XenServer

[Tim Mackey]

There isn't anything I can think of wrt reliability. If the usage is
limited to VR boot, then I don't see anything on the surface to limit
performance.

In other words, xenstore as a solution seems a reasonable approach.

-tim

On Mon, Jan 15, 2018 at 8:26 PM, Pierre-Luc Dion  wrote:

> Hi Tim,
>
> As long as it work, since it's only used to for the initial instruction set
> at the VR boot so eth0 can be configure, I think xenstore would work just
> fine.
> unless you are saying we could just not rely on xenstore in terms of
> reliability?
>
>
> *Pierre-Luc DION*
> Architecte de Solution Cloud | Cloud Solutions Architect
> t 855.652.5683
>
> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Fri, Jan 12, 2018 at 7:34 PM, Tim Mackey  wrote:
>
> > > We found that we can use xenstore-read / xenstore-write to send data
> from
> > dom0 to domU which are in our case  VRs or SVMs. Any reason not using
> this
> > approach ?
> >
> > xenstore has had some issues in the past. The most notable of which were
> > limitations on the number of event channels in use, followed by overall
> > performance impact. iirc, the event channel stuff was fully resolved with
> > XenServer 6.5, but they do speak to a need to test if there are any
> changes
> > to the maximum number of VMs which can be reliably supported. It also
> > limits legacy support (in case that matters).
> >
> > Architecturally I think this is a reasonable approach to the problem. One
> > other thing to note is that xapi replicates xenstore information to all
> > members of a pool. That might impact RVRs.
> >
> > -tim
> >
> > [1] "xenstore is not a high-performance facility and should beused only
> for
> > small amounts of control plane data."
> > https://xenbits.xen.org/docs/4.6-testing/misc/xenstore.txt
> >
> > On Fri, Jan 12, 2018 at 4:56 PM, Pierre-Luc Dion 
> > wrote:
> >
> > > After some verification with Syed and Khosrow,
> > >
> > > We found that we can use xenstore-read / xenstore-write to send data
> from
> > > dom0 to domU which are in our case  VRs or SVMs. Any reason not using
> > this
> > > approach ?  that way we would not need a architectural change for
> > XenServer
> > > pods, and this would support HVM and PV virtual-router. more test
> > required,
> > > for sure, VR would need to have xentools pre-installed.
> > >
> > >
> > > *Pierre-Luc DION*
> > > Architecte de Solution Cloud | Cloud Solutions Architect
> > > t 855.652.5683
> > >
> > > *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> > > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > > w cloudops.com *|* tw @CloudOps_
> > >
> > > On Fri, Jan 12, 2018 at 4:07 PM, Syed Ahmed 
> wrote:
> > >
> > > > KVM uses a VirtIO channel to send information about the IP address
> and
> > > > other params to the SystemVMs. We could use a similar strategy in
> > > XenServer
> > > > using XenStore. This would involve minimal changes to the code while
> > > > keeping backward compatibility.
> > > >
> > > >
> > > >
> > > > On Fri, Jan 12, 2018 at 3:07 PM, Simon Weller
>  > >
> > > > wrote:
> > > >
> > > > > They do not. They receive a link-local ip address that is used for
> > host
> > > > > agent to VR communication. All VR commands are proxied through the
> > host
> > > > > agent. Host agent to VR communication is over SSH.
> > > > >
> > > > >
> > > > > 
> > > > > From: Rafael Weingärtner 
> > > > > Sent: Friday, January 12, 2018 1:42 PM
> > > > > To: dev
> > > > > Subject: Re: [DISCUSS] running sVM and VR as HVM on XenServer
> > > > >
> > > > > but we are already using this design in vmware deployments (not
> sure
> > > > about
> > > > > KVM). The management network is already an isolated network only
> used
> > > by
> > > > > system vms and ACS. Unless we are attacked by some internal agent,
> we
> > > are
> > > > > safe from customer attack through management networks. Also, we can
> > (if
> > > > we
> > > > > don't do yet) restrict access only via these management interfaces
> in
> > > > > system VMs(VRs, SSVM, console proxy and others to come).
> > > > >
> > > > >
> > > > >
> > > > > Can someone confirm if VRs receive management IPs in KVM
> deployments?
> > > > >
> > > > > On Fri, Jan 12, 2018 at 5:36 PM, Syed Ahmed 
> > > wrote:
> > > > >
> > > > > > The reason why we used link local in the first place was to
> isolate
> > > the
> > > > > VR
> > > > > > from directly accessing the management network. This provides
> > another
> > > > > layer
> > > > > > of security in case of a VR exploit. This will also have a side
> > > effect
> > > > of
> > > > > > making all VRs visible to each other. Are we okay accepting this?
> > > > > >
> > > > > > Thanks,
> > > > > > -Syed
> > > > > >
> > > > > > On Fri, Jan 12, 2018 at 11:37 AM, Tim Mackey 
> > > > wrote:
> > > > > >
> > > > > > > dom0 already has a DHCP server listening for requests on
> inte

[4.11] KVM Advanced Networking with SG Problem

[Özhan Rüzgar Karaman]

Hi;
We made a test with 4.11 rc over Ubuntu16.04 KVM hosts and we noticed that
there is a problem on setting & applying security group changes on KVM
host.

All instances could ping vr and they could access internet but no one could
access to the instances.

I checked iptables rules and i noticed that iptables rules for vm is in all
drop state for incoming packages while i gave access to all ingress and
egress tcp/udp traffic ports for that instances. Below are iptables output
for selected vm:

Chain i-2-6-VM (1 references)
target prot opt source   destination
DROP   all  --  anywhere anywhere

Chain i-2-6-VM-eg (1 references)
target prot opt source   destination
RETURN all  --  anywhere anywhere

Chain i-2-6-def (2 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere state
RELATED,ESTABLISHED
ACCEPT udp  --  anywhere anywhere PHYSDEV match
--physdev-in vnet9 --physdev-is-bridged udp spt:bootpc dpt:bootps
ACCEPT udp  --  anywhere anywhere PHYSDEV match
--physdev-out vnet9 --physdev-is-bridged udp spt:bootps dpt:bootpc
DROP   all  --  anywhere anywhere PHYSDEV match
--physdev-in vnet9 --physdev-is-bridged ! match-set i-2-6-VM src
RETURN udp  --  anywhere anywhere PHYSDEV match
--physdev-in vnet9 --physdev-is-bridged match-set i-2-6-VM src udp
dpt:domain
RETURN tcp  --  anywhere anywhere PHYSDEV match
--physdev-in vnet9 --physdev-is-bridged match-set i-2-6-VM src tcp
dpt:domain
i-2-6-VM-eg  all  --  anywhere anywhere PHYSDEV
match --physdev-in vnet9 --physdev-is-bridged match-set i-2-6-VM src
i-2-6-VM   all  --  anywhere anywhere PHYSDEV match
--physdev-out vnet9 --physdev-is-bridged

All management and agent logs could be accessed from:
http://51.15.199.7/4.11r1_Test_20190116.tgz

Thanks
Özhan

Re: HA issues

[Nux!]

Ok, reinstalled and re-tested.

What I've learned:

- HA only works now if OOB is configured, the old way HA no longer applies - 
this can be good and bad, not everyone has IPMIs

- HA only works if IPMI is reachable. I've pulled the cord on a HV and HA 
failed to do its thing, leaving me with a HV down along with all the VMs 
running there. That's bad.
I've opened this ticket for it:
https://issues.apache.org/jira/browse/CLOUDSTACK-10234

Let me know if you need any extra info or stuff to test.

Regards,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: "dev" 
> Sent: Tuesday, 16 January, 2018 11:35:58
> Subject: Re: HA issues

> I'll reinstall my setup and try again, just to be sure I'm working on a clean
> slate.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Rohit Yadav" 
>> To: "dev" 
>> Sent: Tuesday, 16 January, 2018 11:29:51
>> Subject: Re: HA issues
> 
>> Hi Lucian,
>> 
>> 
>> If you're talking about the new HostHA feature (with KVM+nfs+ipmi), please 
>> refer
>> to following docs:
>> 
>> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/hosts.html#out-of-band-management
>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Host+HA
>> 
>> 
>> We'll need to you look at logs perhaps create a JIRA ticket with the logs and
>> details? If you saw ipmi based reboot, then host-ha indeed tried to recover
>> i.e. reboot the host, once hostha has done its work it would schedule HA for 
>> VM
>> as soon as the recovery operation succeeds (we've simulator and kvm based
>> marvin tests for such scenarios).
>> 
>> 
>> Can you see it making attempt to schedule VM ha in logs, or any failure?
>> 
>> 
>> - Rohit
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Nux! 
>> Sent: Tuesday, January 16, 2018 12:47:56 AM
>> To: dev
>> Subject: [4.11] HA issues
>> 
>> Hi,
>> 
>> I see there's a new HA engine for KVM and IPMI support which is really nice,
>> however it seems hit and miss.
>> I have created an instance with HA offering, kernel panicked one of the
>> hypervisors - after a while the server was rebooted via IPMI probably, but 
>> the
>> instance never moved to a running hypervisor and even after the original
>> hypervisor came back it was still left in Stopped state.
>> Is there any extra things I need to set up to have proper HA?
>> 
>> Regards,
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> rohit.ya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue

RE: [PROPOSE] EOL for supported OSes & Hypervisors

[Paul Angus]

Hi Eric,

This is the type of discussion that I wanted to open - the argument that I see 
for earlier dropping of v6 is that - Between May 2018 and q2 2020 RHEL/CentOS 
6.x will only receive security and mission critical updates, meanwhile packages 
on which we depend or may want to utilise in the future are been deprecated or 
not developed for v6.x
Also the testing and development burden on the CloudStack community increases 
as we try to maintain backward compatibility while including new versions.

Needing installation documentation for centos 7 is a great point, and something 
that we need to address regardless.


Does anyone else have a view, I'd really like to here from a wide range of 
people.

Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Eric Green [mailto:eric.lee.gr...@gmail.com] 
Sent: 12 January 2018 17:24
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors

Official EOL for Centos 6 / RHEL 6 as declared by Red Hat Software is 
11/30/2020. Jumping the gun a bit there, padme. 

People on Centos 6 should certainly be working on a migration strategy right 
now, but the end is not here *yet*. Furthermore, the install documentation is 
still written for Centos 6 rather than Centos 7. That needs to be fixed before 
discontinuing support for Centos 6, eh?

> On Jan 12, 2018, at 04:35, Rohit Yadav  wrote:
> 
> +1 I've updated the page with upcoming Ubuntu 18.04 LTS.
> 
> 
> After 4.11, I think 4.12 (assuming releases by mid of 2018) should remove 
> "declared" (they might still work with 4.12+ but in docs and by project we 
> should officially support them) support for following:
> 
> 
> a. Hypervisor:
> 
> XenServer - 6.2, 6.5,
> 
> KVM - CentOS6, RHEL6, Ubuntu12.04 (I think this is already removed, packages 
> don't work I think?)
> 
> vSphere/Vmware - 4.x, 5.0, 5.1, 5.5
> 
> 
> b. Remove packaging for CentOS6.x, RHEL 6.x (the el6 packages), and Ubuntu 
> 12.04 (any non-systemd debian distro).
> 
> 
> Thoughts, comments?
> 

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Ron Wheeler]

I am having a hard time imagining why a new Cloudstack user would want 
to use CentOS 6.
I have not heard complaints from any forum about applications running on 
CentOS 6 that could not run on CentOS 7.


It does have an impact of DevOps but even there it is pretty minor and 
well documented and once one gets one's head around systemctl, 
journalctl and firewalld, it really is a lot better


As you pointed out, support for CentOS 7 is mandatory regardless of the 
decision on CentOS 6.
It will be a big black mark against CloudStack if the current 
RedHat/CentOS release is not supported 2.5 years after its release.


For existing Cloudstack users, is there a large risk that dropping 
official support for CentOS6 as a VM would result in a CentOS 6 VM not 
running after an upgrade to the latest Cloudstack?
Is there anyone in the community that absolutely can not upgrade? Would 
they take over the testing of CentOS 6 if official support was dropped?


Anyone using CentOS6 as a hypervisor will have to upgrade soon in any 
event and as you point out Cloudstack will soon be forced to move from 
CentOS 6 by dependencies dropping support for CentOS 6.


It would seem to make sense to declare an EOL date for support for 
CentOS 6 as a hypervisor as soon as possible so that system 
administrators are put on notice.


Ron



On 16/01/2018 12:58 PM, Paul Angus wrote:

Hi Eric,

This is the type of discussion that I wanted to open - the argument that I see 
for earlier dropping of v6 is that - Between May 2018 and q2 2020 RHEL/CentOS 
6.x will only receive security and mission critical updates, meanwhile packages 
on which we depend or may want to utilise in the future are been deprecated or 
not developed for v6.x
Also the testing and development burden on the CloudStack community increases 
as we try to maintain backward compatibility while including new versions.

Needing installation documentation for centos 7 is a great point, and something 
that we need to address regardless.


Does anyone else have a view, I'd really like to here from a wide range of 
people.

Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Eric Green [mailto:eric.lee.gr...@gmail.com]
Sent: 12 January 2018 17:24
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors

Official EOL for Centos 6 / RHEL 6 as declared by Red Hat Software is 
11/30/2020. Jumping the gun a bit there, padme.

People on Centos 6 should certainly be working on a migration strategy right 
now, but the end is not here *yet*. Furthermore, the install documentation is 
still written for Centos 6 rather than Centos 7. That needs to be fixed before 
discontinuing support for Centos 6, eh?


On Jan 12, 2018, at 04:35, Rohit Yadav  wrote:

+1 I've updated the page with upcoming Ubuntu 18.04 LTS.


After 4.11, I think 4.12 (assuming releases by mid of 2018) should remove 
"declared" (they might still work with 4.12+ but in docs and by project we 
should officially support them) support for following:


a. Hypervisor:

XenServer - 6.2, 6.5,

KVM - CentOS6, RHEL6, Ubuntu12.04 (I think this is already removed, packages 
don't work I think?)

vSphere/Vmware - 4.x, 5.0, 5.1, 5.5


b. Remove packaging for CentOS6.x, RHEL 6.x (the el6 packages), and Ubuntu 
12.04 (any non-systemd debian distro).


Thoughts, comments?



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address

[Tutkowski, Mike]

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:3]
: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!"  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" 
> To: "dev" 
> 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,
  

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Tim Mackey]

I think there are three pieces in play. First there are guest OSes, second
the management server and third the hypervisors themselves. For the
hypervisors and management server I can see a more stringent set of
requirements. Going by the XenServer experience, legacy guests should
continue to work, but removing any "unsupported" guest OS versions from
template definition should be done.

When communicating end of support status, I've always been a fan of
something which can be quickly understood. e.g. "XenServer support ends six
months after Citrix drops primary support for the version". Then follow
that in a table with a date, but I feel tying it to the "upstream" support
statement more clearly communicates the real dependency.

>From a release notes perspective, I'd recommend communicating any impending
support statement change early and often. e.g. For any "upstream" EOL/EOS
statement occurring in the next 12 months we add a notice to the release
notes reminding people of the impending change.

For new versions of things, maybe adopting a statement that within X months
after launch of the dependency we'd have support for it?

-tim

On Tue, Jan 16, 2018 at 2:57 PM, Ron Wheeler  wrote:

> I am having a hard time imagining why a new Cloudstack user would want to
> use CentOS 6.
> I have not heard complaints from any forum about applications running on
> CentOS 6 that could not run on CentOS 7.
>
> It does have an impact of DevOps but even there it is pretty minor and
> well documented and once one gets one's head around systemctl, journalctl
> and firewalld, it really is a lot better
>
> As you pointed out, support for CentOS 7 is mandatory regardless of the
> decision on CentOS 6.
> It will be a big black mark against CloudStack if the current
> RedHat/CentOS release is not supported 2.5 years after its release.
>
> For existing Cloudstack users, is there a large risk that dropping
> official support for CentOS6 as a VM would result in a CentOS 6 VM not
> running after an upgrade to the latest Cloudstack?
> Is there anyone in the community that absolutely can not upgrade? Would
> they take over the testing of CentOS 6 if official support was dropped?
>
> Anyone using CentOS6 as a hypervisor will have to upgrade soon in any
> event and as you point out Cloudstack will soon be forced to move from
> CentOS 6 by dependencies dropping support for CentOS 6.
>
> It would seem to make sense to declare an EOL date for support for CentOS
> 6 as a hypervisor as soon as possible so that system administrators are put
> on notice.
>
> Ron
>
>
>
>
> On 16/01/2018 12:58 PM, Paul Angus wrote:
>
>> Hi Eric,
>>
>> This is the type of discussion that I wanted to open - the argument that
>> I see for earlier dropping of v6 is that - Between May 2018 and q2 2020
>> RHEL/CentOS 6.x will only receive security and mission critical updates,
>> meanwhile packages on which we depend or may want to utilise in the future
>> are been deprecated or not developed for v6.x
>> Also the testing and development burden on the CloudStack community
>> increases as we try to maintain backward compatibility while including new
>> versions.
>>
>> Needing installation documentation for centos 7 is a great point, and
>> something that we need to address regardless.
>>
>>
>> Does anyone else have a view, I'd really like to here from a wide range
>> of people.
>>
>> Kind regards,
>>
>> Paul Angus
>>
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>> -Original Message-
>> From: Eric Green [mailto:eric.lee.gr...@gmail.com]
>> Sent: 12 January 2018 17:24
>> To: us...@cloudstack.apache.org
>> Cc: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors
>>
>> Official EOL for Centos 6 / RHEL 6 as declared by Red Hat Software is
>> 11/30/2020. Jumping the gun a bit there, padme.
>>
>> People on Centos 6 should certainly be working on a migration strategy
>> right now, but the end is not here *yet*. Furthermore, the install
>> documentation is still written for Centos 6 rather than Centos 7. That
>> needs to be fixed before discontinuing support for Centos 6, eh?
>>
>> On Jan 12, 2018, at 04:35, Rohit Yadav  wrote:
>>>
>>> +1 I've updated the page with upcoming Ubuntu 18.04 LTS.
>>>
>>>
>>> After 4.11, I think 4.12 (assuming releases by mid of 2018) should
>>> remove "declared" (they might still work with 4.12+ but in docs and by
>>> project we should officially support them) support for following:
>>>
>>>
>>> a. Hypervisor:
>>>
>>> XenServer - 6.2, 6.5,
>>>
>>> KVM - CentOS6, RHEL6, Ubuntu12.04 (I think this is already removed,
>>> packages don't work I think?)
>>>
>>> vSphere/Vmware - 4.x, 5.0, 5.1, 5.5
>>>
>>>
>>> b. Remove packaging for CentOS6.x, RHEL 6.x (the el6 packages), and
>>> Ubuntu 12.04 (any non-systemd debian distro).
>>>
>>>
>>> Thoughts, comments?
>>>
>>>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@a

Re: 4.11 RC1 KVM Issue: Incorrect hostname/no IP address

[Tutkowski, Mike]

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"  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 :

> 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: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Tutkowski, Mike]

Hi everyone,

For the past couple days, I have been running the KVM managed-storage 
regression-test suite against RC1.

With the exception of one issue (more on this below), all of these tests have 
passed.

Tomorrow I plan to start in on the VMware-related managed-storage tests.

Once I’ve completed running those, I expect to move on to the XenServer-related 
managed-storage tests.

I ran these XenServer and VMware tests just prior to RC1 being created, so I 
suspect all of those tests will come back successful.

Now, with regards to the one issue I found on KVM with managed storage:

It relates to a new feature whereby you can online migrate the storage of a VM 
from NFS or Ceph to managed storage.

During the code-review process, I made a change per a suggestion and it 
introduced an issue with this feature. The solution is just a couple lines of 
code and only impacts this one use case. If you are testing this release 
candidate and don’t really care about this particular feature, it should not at 
all impact your ability to test RC1.

Thanks!
Mike

> On Jan 15, 2018, at 4:33 AM, Rohit Yadav  wrote:
> 
> Hi All,
> 
> I've created a 4.11.0.0 release, with the following artifacts up for
> testing and a vote:
> 
> Git Branch and Commit SH:
> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.11.0.0-RC20180115T1603
> Commit: 1b8a532ba52127f388847690df70e65c6b46f4d4
> 
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.11.0.0/
> 
> PGP release keys (signed using 5ED1E1122DC5E8A4A45112C2484248210EE3D884):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> 
> The vote will be open for 72 hours.
> 
> For sanity in tallying the vote, can PMC members please be sure to indicate
> "(binding)" with their vote?
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Additional information:
> 
> For users' convenience, I've built packages from
> 1b8a532ba52127f388847690df70e65c6b46f4d4 and published RC1 repository here:
> http://cloudstack.apt-get.eu/testing/4.11-rc1
> 
> The release notes are still work-in-progress, but the systemvmtemplate
> upgrade section has been updated. You may refer the following for
> systemvmtemplate upgrade testing:
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/index.html
> 
> 4.11 systemvmtemplates are available from here:
> https://download.cloudstack.org/systemvm/4.11/
> 
> Regards,
> Rohit Yadav