Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

kristian,

these sound like serious regressions. Do you have a fix or did you analyse
the code yet?

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

> Hello,
>
> I have created issue in jira 2 month ago.
> https://issues.apache.org/jira/browse/CLOUDSTACK-10141
>
> In version 4.10 VR password and ssh key distribution don´t work on
> instance creation.
> When instance is allreay excisting reset function is operational.
>
> 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
>
> In my knowledege cloudstack older versions are not affected.
>
> Lugupidamisega / Regards
>
> Kristian Liivak
>
> CTO
>
> 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: "Rohit Yadav" 
> To: dev@cloudstack.apache.org, "users" 
> Sent: Sunday, January 14, 2018 8:41:15 PM
> Subject: Re: [DISCUSS] Freezing master for 4.11
>
> All,
>
>
> To give you update, all feature PRs have been reviewed, tested and merged
> towards the 4.11.0.0. I'll engage with Mike and others for any post-merge
> regressions (smoketest to be kicked shortly).
>
>
> I see an outstanding PR that may be a critical/blocker PR, please advise
> and also review:
>
> https://github.com/apache/cloudstack/pull/2402
>
>
> If anyone has any blocker to report, please do so. Thanks.
>
>
> I'll cut RC1 as planned by EOD today (Mon/15 Jan 2018).
>
>
> - Rohit
>
> 
>
>
>
> 
> From: Tutkowski, Mike 
> Sent: Saturday, January 13, 2018 3:23:40 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Freezing master for 4.11
>
> I’m investigating these now. I have found and fixed two of them so far.
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> > On Jan 12, 2018, at 2:49 PM, Rohit Yadav 
> wrote:
> >
> > Thanks Rafael and Daan.
> >
> >
> >> From: Rafael Weingärtner 
> >>
> >> I believe there is no problem in merging Wido’s and Mike’s PRs, they
> have
> >> been extensively discussed and improved (specially Mike’s one).
> >
> > Thanks, Mike's PR has several regression smoketest failures and can be
> accepted only when those failures are fixed.
> >
> > We'll cut 4.11 branch start rc1 on Monday that would be a hard freeze.
> If Mike wants, he can help fix them over the weekend, I can help run
> smoketests.
> >
> >> Having said that; I would be ok with it (no need to revert it), but we
> need
> >> to be more careful with these things. If one wants to merge something,
> >> there is no harm in waiting and calling for reviewers via Github,
> Slack, or
> >> even email them directly.
> >
> > Additional review was requested, but mea culpa - thanks for your
> support, noted.
> >
> > - Rohit
> >
> > On Fri, Jan 12, 2018 at 3:57 PM, Rohit Yadav 
> > wrote:
> >
> >> All,
> >>
> >>
> >> We're down to one feature PR towards 4.11 milestone now:
> >>
> >> https://github.com/apache/cloudstack/pull/2298
> >>
> >>
> >> The config drive PR from Frank (Nuage) has been accepted today after no
> >> regression test failures seen from yesterday's smoketest run. We've also
> >> tested, reviewed and merge Wido's (blocker fix) PR.
> >>
> >>
> >> I've asked Mike to stabilize the branch; based on the smoketest results
> >> from today we can see some failures caused by the PR. I'm willing to
> work
> >> with Mike and others to get this PR tested, and merged over the
> weekends if
> >> we can demonstrate that no regression is caused by it, i.e. no new
> >> smoketest regressions. I'll also try to fix regression and test failures
> >> over the weekend.
> >>
> >>
> >> Lastly, I would like to discuss a mistake I made today with merging the
> >> following PR which per our guideline lacks one code review
> lgtm/approval:
> >>
> >> https://github.com/apache/cloudstack/pull/2152
> >>
> >>
> >> The changes in above (merged) PR are all localized to a xenserver-swift
> >> file, that is not tested by Travis or Trillian, since no new regression
> >> failures were seen I accepted and merge it on that discretion. The PR
> was
> >> originally on the 4.11 milestone, however, due to it lacking a JIRA id
> and
> >> no response from the author it was only recently removed from the
> milestone.
> >>
> >>
> >> Please advise if I need to revert this, or we can review/lgtm it
> >> post-merge? I'll also ping on the above PR.
> >>
> >>
> >> - Rohit
> >>
> >> 
> > Apache CloudStack: Open Source Cloud Computing apache.org/>
> > cloudstack.apache.org
> > CloudStack is open source cloud computing software for creating,
> managing, and deploying infrastructure cloud services

[VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Rohit Yadav]

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

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

Yes, I know. I made that that's why i asked. This fix isn't in 4.10 but is
in 4.11.

On Mon, Jan 15, 2018 at 12:37 PM, Kristian Liivak  wrote:

>
> We made lot testing but did´nt had time to dig code this time.
> There was similar VR password management related and fixed issue
> https://issues.apache.org/jira/browse/CLOUDSTACK-10113
>
>
>
> Lugupidamisega / Regards
>
> Kristian Liivak
>
> CTO
> 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:22:23 PM
> Subject: Re: [DISCUSS] Freezing master for 4.11
>
> kristian,
>
> these sound like serious regressions. Do you have a fix or did you analyse
> the code yet?
>
> On Mon, Jan 15, 2018 at 11:49 AM, Kristian Liivak  wrote:
>
> > Hello,
> >
> > I have created issue in jira 2 month ago.
> > https://issues.apache.org/jira/browse/CLOUDSTACK-10141
> >
> > In version 4.10 VR password and ssh key distribution don´t work on
> > instance creation.
> > When instance is allreay excisting reset function is operational.
> >
> > 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
> >
> > In my knowledege cloudstack older versions are not affected.
> >
> > Lugupidamisega / Regards
> >
> > Kristian Liivak
> >
> > CTO
> >
> > 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: "Rohit Yadav" 
> > To: dev@cloudstack.apache.org, "users" 
> > Sent: Sunday, January 14, 2018 8:41:15 PM
> > Subject: Re: [DISCUSS] Freezing master for 4.11
> >
> > All,
> >
> >
> > To give you update, all feature PRs have been reviewed, tested and merged
> > towards the 4.11.0.0. I'll engage with Mike and others for any post-merge
> > regressions (smoketest to be kicked shortly).
> >
> >
> > I see an outstanding PR that may be a critical/blocker PR, please advise
> > and also review:
> >
> > https://github.com/apache/cloudstack/pull/2402
> >
> >
> > If anyone has any blocker to report, please do so. Thanks.
> >
> >
> > I'll cut RC1 as planned by EOD today (Mon/15 Jan 2018).
> >
> >
> > - Rohit
> >
> > 
> >
> >
> >
> > 
> > From: Tutkowski, Mike 
> > Sent: Saturday, January 13, 2018 3:23:40 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Freezing master for 4.11
> >
> > I’m investigating these now. I have found and fixed two of them so far.
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> > > On Jan 12, 2018, at 2:49 PM, Rohit Yadav 
> > wrote:
> > >
> > > Thanks Rafael and Daan.
> > >
> > >
> > >> From: Rafael Weingärtner 
> > >>
> > >> I believe there is no problem in merging Wido’s and Mike’s PRs, they
> > have
> > >> been extensively discussed and improved (specially Mike’s one).
> > >
> > > Thanks, Mike's PR has several regression smoketest failures and can be
> > accepted only when those failures are fixed.
> > >
> > > We'll cut 4.11 branch start rc1 on Monday that would be a hard freeze.
> > If Mike wants, he can help fix them over the weekend, I can help run
> > smoketests.
> > >
> > >> Having said that; I would be ok with it (no need to revert it), but we
> > need
> > >> to be more careful with these things. If one wants to merge something,
> > >> there is no harm in waiting and calling for reviewers via Github,
> > Slack, or
> > >> even email them directly.
> > >
> > > Additional review was requested, but mea culpa - thanks for your
> > support, noted.
> > >
> > > - Rohit
> > >
> > > On Fri, Jan 12, 2018 at 3:57 PM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> > > wrote:
> > >
> > >> All,
> > >>
> > >>
> > >> We're down to one feature PR towards 4.11 milestone now:
> > >>
> > >> https://github.com/apache/cloudstack/pull/2298
> > >>
> > >>
> > >> The config drive PR from Frank (Nuage) has been accepted today after
> no
> > >> regression test failures seen from yesterday's smoketest run. We've
> also
> > >> tested, reviewed and merge Wido's (blocker fix) PR.
> > >>
> > >>
> > >> I've asked Mike to stabilize the branch; based on the smoketest
> results
> > >> from today we can see some failures caused by the PR. I'm willing to
> > work
> > >> with Mike and others to get this PR tested, and merged over the
> > weekends if
> > >> we can demonstrate that no regression is caused by it, i.e. no new
> > >> smoketest regressions. I'll also try to fix regression and test
> fai

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

​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: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

I suggest you discuss it on the vote thread for RC1 Kristian.

On Mon, Jan 15, 2018 at 12:47 PM, Kristian Liivak  wrote:

>
> This fix is only for smaller part of password management..
> Is´t possible that someone have look VR password distribution with
> instance creation ?


-- 
Daan

[NOTICE] Master can accept PRs now

[Rohit Yadav]

All,


I've updated master to 4.12.0.0-SNAPSHOT, it may accept feature PRs now. They 
should use the 4.12 milestone: https://github.com/apache/cloudstack/milestone/4


If you've sent a bugfix (and acceptable enhancement [1]) PR, kindly change the 
base branch to 4.11 and milestone to 4.11.1: 
https://github.com/apache/cloudstack/milestone/5


Please find time to test and vote on the 4.11.0.0-rc1 and discuss/share any 
issues especially blockers in the RC1 voting thread.


[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS


- Rohit





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

Re: [NOTICE] Master can accept PRs now

[Marc-Aurèle Brothier]

Hi!
Ok, as my PR for the maven standard structure does a lot of file moves, I'm
putting it as a first PR to accept if people agree to:
https://github.com/apache/cloudstack/pull/2283

I still have to rebase and fix the conflict, which will be done shortly.

On Mon, Jan 15, 2018 at 1:19 PM, Rohit Yadav 
wrote:

> All,
>
>
> I've updated master to 4.12.0.0-SNAPSHOT, it may accept feature PRs now.
> They should use the 4.12 milestone: https://github.com/apache/
> cloudstack/milestone/4
>
>
> If you've sent a bugfix (and acceptable enhancement [1]) PR, kindly change
> the base branch to 4.11 and milestone to 4.11.1:
> https://github.com/apache/cloudstack/milestone/5
>
>
> Please find time to test and vote on the 4.11.0.0-rc1 and discuss/share
> any issues especially blockers in the RC1 voting thread.
>
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>
>
> - Rohit
>
> 
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: Which StringUtils to use?

[Nicolas Vazquez]

I think a PR with a single commit and a large number of files will be ok, if we 
make sure each usage of CS StringUtils functions is replaced by the Apache ones 
and their code removed from CS StringUtils. I also think that another PR could 
be created to move those functions mentioned by Rafael which should not be on 
StringUtils to new util classes and finally remove CS StringUtils from the 
codebase.


From: Rafael Weingärtner 
Sent: Friday, January 12, 2018 6:59:01 AM
To: dev
Subject: Re: Which StringUtils to use?

Well, there is always other approaches...If we did not use those static
loggers, this number could be greatly reduced. Most of those objects are
singletons and we could use a protected attribute in the first element of
the hierarchy.

I do not mind a PR with this number of files changes as long as you stick
to a single change, what I mind is the combination of high number of files
and commits.Then, at least for me, it becomes pretty hard to track down
things.

On Fri, Jan 12, 2018 at 6:19 AM, Daan Hoogland 
wrote:

> if we don't use a wrapper we get PRs like
> https://github.com/apache/cloudstack/pull/2276 in the future, trying to
> update logging touches 1710 files. I think we should go for the wrapper
> model on these kind of utilities.
>
> On Thu, Jan 11, 2018 at 9:59 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > Wrapping would still hold code on our side. We have to get rid of code…
> >
> > If we want to start removing CloudStack’s StringUtils in favor of
> > StringUtils from Apache, we could start creating PRs by components (java
> > project in Eclipse). That is manageable to do and to review. There are
> > about 119 classes that use CloudStack’s StringUtils.
> >
> >
> > We will not be able to remove CloudStack's StringUtils though. There are
> > very specific things there such as "applyPagination" that should not even
> > be there... I guess the programmer was running out of places to write
> code
> >
> > On Thu, Jan 11, 2018 at 6:25 PM, Daan Hoogland 
> > wrote:
> >
> > > All, I am having second thoughts. I think we should maintain a wrapper
> > for
> > > string utils and pass through as much as possible to commons string
> > utils.
> > > A similar thing is applicable to logging. It was started at one time
> and
> > a
> > > second attempt was started to use slf4j.
> > > I think we should encapsulate these kind of utilities to facilitate
> > > migration.
> > > There is also json and xml formatting and maybe handling sockets and
> (big
> > > one) data access objects :/
> > >
> > > @Ron, all string utils are static methods.
> > >
> > > On Thu, Jan 11, 2018 at 12:11 AM, Ron Wheeler
> >  > > com> wrote:
> > >
> > > > Certainly better to find the references and remove them if you can
> get
> > > > that done in a single effort.
> > > >
> > > > Just a technical question: Could one not just add the Warning to the
> > > > constructor?
> > > > Might have to create a null (log warning only) constructor.
> > > >
> > > > Ron
> > > >
> > > >
> > > > On 10/01/2018 3:58 PM, Daan Hoogland wrote:
> > > >
> > > >> We can add log messages to each of the methods in StringUtils but I
> do
> > > not
> > > >> think that is a good way to go. Any method you touch you can reform
> or
> > > >> remove anyhow.
> > > >>
> > > >> On Wed, Jan 10, 2018 at 9:51 PM, Ron Wheeler <
> > > >> rwhee...@artifact-software.com
> > > >>
> > > >>> wrote:
> > > >>> Agreed about deprecation.
> > > >>> A logged WARNing would be detected during testing as well as at
> > > run-time.
> > > >>>
> > > >>> Ron
> > > >>>
> > > >>> On 10/01/2018 3:34 PM, Daan Hoogland wrote:
> > > >>>
> > > >>> Ron, we could but that would only log during compile-time, not on
> > > >>> runtime.
> > > >>> I am doing some analysis and commenting in Wido's ticket.
> > > >>>
> > > >>> On Wed, Jan 10, 2018 at 9:23 PM, Ron Wheeler
> > >  > > >>> com> wrote:
> > > >>>
> > > >>> Is it possible to mark it as deprecated and have it log a warning
> > when
> > >  used?
> > > 
> > >  Ron
> > > 
> > > 
> > >  On 10/01/2018 2:26 PM, Daan Hoogland wrote:
> > > 
> > >  I think we could start with giving it an explicit non standard
> name
> > > like
> > > > CloudStackLocalStringUtils or something a little shorter. Making
> > sure
> > > > that
> > > > we prefer for these types of utils to be imported from other
> > > projects.
> > > >
> > > > On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander <
> > w...@widodh.nl>
> > > > wrote:
> > > >
> > > >
> > > > On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:
> > > >>
> > > >> Instead of creating a PR for that, we could do the bit by bit
> job
> > > >>
> > > >>> (hopefully one day we finish the job).
> > > >>> Every time we see a code using ACS's StringUtils, we check if
> it
> > > can
> > > >>> be
> > > >>> replaced by Apache's one.
> > > >>>
> > > >>>
> > > >>> Yes, but t

RE: IP Address Discrepancy with VMware

[Paul Angus]

Sure.
It doesn't seem to be a systematic failure.


Kind regards,

Paul Angus

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


-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
Sent: 15 January 2018 01:09
To: dev@cloudstack.apache.org
Subject: Re: IP Address Discrepancy with VMware

Hi Paul,

I don’t know what was causing it, but I destroyed and re-created the VR and now 
it works just fine.

Seems like we have a bug here, but it’s not easy to reproduce.

Talk to you later!
Mike

On 1/11/18, 3:13 PM, "Tutkowski, Mike"  wrote:

Hi Paul,

Thanks for looking into that!

I was just spinning up a VM in a Basic Zone using VMware and NFS…nothing 
really out of the ordinary.

I’m traveling today, but should be able to re-try this use case again 
tomorrow.

Thanks again!
Mike

On 1/11/18, 2:12 AM, "Paul Angus"  wrote:

Hey Mike, were you doing anything specific/special?  I haven't yet 
managed to get the wrong IP address.
how does the config for dhcp leases look on the VR?


Kind regards,

Paul Angus

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


-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
Sent: 11 January 2018 07:52
To: dev@cloudstack.apache.org
Subject: Re: IP Address Discrepancy with VMware

Thanks, Paul!

> On Jan 11, 2018, at 12:49 AM, Paul Angus  
wrote:
> 
> I'll have a look @ mike
> 
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> 
> 
> 
> 
> -Original Message-
> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
> Sent: 11 January 2018 07:31
> To: dev@cloudstack.apache.org
> Subject: IP Address Discrepancy with VMware
> 
> Hi,
> 
> While I was running some tests related to 4.11 tonight, I noticed the 
following discrepancy with regards to the IP address given to a VM of mine:
> 
> https://imgur.com/3ODXHNe
> 
> According to CloudStack, the IP address should be 10.117.40.28. 
However, when I run ifconfig, I get 10.117.40.115.
> 
> In this situation, I’m running only with VMware (no other hypervisor 
type in use) in a Basic Zone where the root disk of the VM is on NFS.
> 
> Anyone else able to reproduce this issue?
> 
> Thanks,
> Mike

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

[Nux!]

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

[4.11] Guid is not updated for cluster with specified cluster id; need to wait for hosts in this cluster to come up

[Nux!]

Hello,

Just installed 4.11 RC1 and following some tests with a single HV I tried 
adding another, but only to get the error in the subject.
http://img.nux.ro/R7x-Selection_314.png

More logs here http://tmp.nux.ro/s3J-guid-cluster-err.txt

The management server does not even attempt to contact that HV (verified with 
tcpdump).
This host has not been added before, it's brand new.

I did play around with the HA settings (turned it on and off, both at cluster 
and host level - it's off now), in case it's relevant.

Any ideas?

Regards,
Lucian


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

RE: Guid is not updated for cluster with specified cluster id; need to wait for hosts in this cluster to come up

[Paul Angus]

What hypervisor is and version is that Lucian?

I'm seeing some weird (similar) stuff with ubuntu 16.04, but it doesn't seem to 
like 4.10 either, so I thought it was something I was doing wrong.


Kind regards,

Paul Angus

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


-Original Message-
From: Nux! [mailto:n...@li.nux.ro] 
Sent: 15 January 2018 17:12
To: dev 
Subject: [4.11] Guid is not updated for cluster with specified cluster id; need 
to wait for hosts in this cluster to come up

Hello,

Just installed 4.11 RC1 and following some tests with a single HV I tried 
adding another, but only to get the error in the subject.
http://img.nux.ro/R7x-Selection_314.png

More logs here http://tmp.nux.ro/s3J-guid-cluster-err.txt

The management server does not even attempt to contact that HV (verified with 
tcpdump).
This host has not been added before, it's brand new.

I did play around with the HA settings (turned it on and off, both at cluster 
and host level - it's off now), in case it's relevant.

Any ideas?

Regards,
Lucian


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Guid is not updated for cluster with specified cluster id; need to wait for hosts in this cluster to come up

[Nux!]

Hi,

CentOS 7 hypervisors, all of them , configured similarly.
The thing is, the management server does not even attempt to connect to it, 
tcpdump outputs nada.
It just spits out that error.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Paul Angus" 
> To: "dev" 
> Sent: Monday, 15 January, 2018 17:27:38
> Subject: RE: Guid is not updated for cluster with specified cluster id; need 
> to wait for hosts in this cluster to come
> up

> What hypervisor is and version is that Lucian?
> 
> I'm seeing some weird (similar) stuff with ubuntu 16.04, but it doesn't seem 
> to
> like 4.10 either, so I thought it was something I was doing wrong.
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>  
> 
> 
> 
> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: 15 January 2018 17:12
> To: dev 
> Subject: [4.11] Guid is not updated for cluster with specified cluster id; 
> need
> to wait for hosts in this cluster to come up
> 
> Hello,
> 
> Just installed 4.11 RC1 and following some tests with a single HV I tried 
> adding
> another, but only to get the error in the subject.
> http://img.nux.ro/R7x-Selection_314.png
> 
> More logs here http://tmp.nux.ro/s3J-guid-cluster-err.txt
> 
> The management server does not even attempt to contact that HV (verified with
> tcpdump).
> This host has not been added before, it's brand new.
> 
> I did play around with the HA settings (turned it on and off, both at cluster
> and host level - it's off now), in case it's relevant.
> 
> Any ideas?
> 
> Regards,
> Lucian
> 
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: Guid is not updated for cluster with specified cluster id; need to wait for hosts in this cluster to come up

[Nux!]

Ok, I solved it.

The install was a bit bumpy because of the problem in my other email re 
VLAN/VXLAN, so maybe that's what caused it.
I checked cloud.cluster table and my cluster was missing the "guid", it was 
NULL.
I've generated a uuid and updated the table and I was able to add the rest of 
the hypervisors.

So do a "select * from cloud.cluster;" see if that's your problem as well.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: "dev" 
> Sent: Monday, 15 January, 2018 17:36:08
> Subject: Re: Guid is not updated for cluster with specified cluster id; need 
> to wait for hosts in this cluster to come
> up

> Hi,
> 
> CentOS 7 hypervisors, all of them , configured similarly.
> The thing is, the management server does not even attempt to connect to it,
> tcpdump outputs nada.
> It just spits out that error.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Paul Angus" 
>> To: "dev" 
>> Sent: Monday, 15 January, 2018 17:27:38
>> Subject: RE: Guid is not updated for cluster with specified cluster id; need 
>> to
>> wait for hosts in this cluster to come
>> up
> 
>> What hypervisor is and version is that Lucian?
>> 
>> I'm seeing some weird (similar) stuff with ubuntu 16.04, but it doesn't seem 
>> to
>> like 4.10 either, so I thought it was something I was doing wrong.
>> 
>> 
>> Kind regards,
>> 
>> Paul Angus
>> 
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>  
>> 
>> 
>> 
>> -Original Message-
>> From: Nux! [mailto:n...@li.nux.ro]
>> Sent: 15 January 2018 17:12
>> To: dev 
>> Subject: [4.11] Guid is not updated for cluster with specified cluster id; 
>> need
>> to wait for hosts in this cluster to come up
>> 
>> Hello,
>> 
>> Just installed 4.11 RC1 and following some tests with a single HV I tried 
>> adding
>> another, but only to get the error in the subject.
>> http://img.nux.ro/R7x-Selection_314.png
>> 
>> More logs here http://tmp.nux.ro/s3J-guid-cluster-err.txt
>> 
>> The management server does not even attempt to contact that HV (verified with
>> tcpdump).
>> This host has not been added before, it's brand new.
>> 
>> I did play around with the HA settings (turned it on and off, both at cluster
>> and host level - it's off now), in case it's relevant.
>> 
>> Any ideas?
>> 
>> Regards,
>> Lucian
>> 
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
> > www.nux.ro

[4.11] HA issues

[Nux!]

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

Re: [DISCUSS] new way of github working

[Rafael Weingärtner]

Daan,

Now that master is open for merges again, can we get a feedback here? It
might be interesting to find a consensus and a standardize way of working
for everybody before we start merging things in master again …



On Mon, Jan 8, 2018 at 8:40 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> This might be my lack of expertise in Git (Github). I like the merge
> commits (when merging a PR) because I can easily find the date when
> something has been introduced to the code base. Of course, this can also be
> achieved through Jira tickets and Github PRs history. This means I would
> not mind adopting the merge and squash option on Github.
>
> On the other hand, regarding the second issue, I prefer the philosophy of
> single commit PRs; otherwise, it feels pretty hard to track what was
> introduced by a PR then. I recall seeing PRs with 100+ commits laying
> around, and I confess that I cannot find myself in the middle of that
> mayhem..
>
> Daan, could you provide more insights on the benefits of having a commit
> per change in a PR?
>
> On Mon, Jan 8, 2018 at 7:30 PM, Daan Hoogland  > wrote:
>
>> Marc-Aurèle and Rafael, I mean both. I know we used to require the first,
>> to create the release notes in a concise way and we used to ban the other
>> because it leads to unnavigable revision trees. But now that squash and
>> merge is a functionality of github one might argue that it doesn’t matter
>> anymore. Personally, I am against squashing persé, in any case. I am not
>> the law (other than during some triathlons) so we jointly might decide
>> differently.
>>
>> On 08/01/2018, 16:50, "Nicolas Vazquez" 
>> wrote:
>>
>> The same as Rafael described. If it is the second case I would prefer
>> rebasing the target branch and push force instead of including merge
>> commits in a PR
>>
>> Obtener Outlook para Android
>>
>> 
>> From: williamstev...@gmail.com  on behalf
>> of Will Stevens 
>> Sent: Monday, January 8, 2018 11:34:42 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] new way of github working
>>
>> Just a note Daan.  If a PR is merged with the `git pr ` tool in
>> our
>> utilities folder, it will automatically include the merge commit.
>> Figured
>> I should mention that...
>>
>> *Will Stevens*
>> CTO
>>
>> 
>>
>> On Mon, Jan 8, 2018 at 8:26 AM, Marc-Aurèle Brothier <
>> ma...@exoscale.ch>
>> wrote:
>>
>> > Same opinion as Rafael described.
>> >
>> > On Mon, Jan 8, 2018 at 11:30 AM, Rafael Weingärtner <
>> > rafaelweingart...@gmail.com> wrote:
>> >
>> > > I did not fully understand what you meant.
>> > >
>> > > Are you talking about the merge commit that can be created when a
>> PR is
>> > > merged? Or, are you talking about a merge commit that is added to
>> a PR
>> > when
>> > > a conflict is solved by its author(s)?
>> > >
>> > >
>> > > I do not have problems with the first type of merge commits.
>> However, I
>> > > think we should not allow the second type to get into our code
>> base.
>> > >
>> > > On Mon, Jan 8, 2018 at 7:45 AM, Daan Hoogland <
>> daan.hoogl...@gmail.com>
>> > > wrote:
>> > >
>> > > > Devs,
>> > > >
>> > > > I see a lot of merge master to branch commits appearing on PRs.
>> This is
>> > > > against prior (non-hard) agreements on how we work. It is
>> getting to be
>> > > the
>> > > > daily practice so;
>> > > > How do we feel about
>> > > > 1. not using merge commits anymore?
>> > > > 2. merging back as a way of solving conflicts?
>> > > > and
>> > > > Do we need to make a policy of it or do we let it evolve, at
>> the risk
>> > of
>> > > > having more hard to track feature/version matrices?
>> > > >
>> > > > --
>> > > > Daan
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Rafael Weingärtner
>> > >
>> >
>>
>> nicolas.vazq...@shapeblue.com
>> www.shapeblue.com
>> ,
>> @shapeblue
>>
>>
>>
>>
>>
>>
>> daan.hoogl...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>>
>
>
> --
> Rafael Weingärtner
>



-- 
Rafael Weingärtner

Re: [DISCUSS] new way of github working

[Will Stevens]

If the new approach is adopted, we will likely have to change the
functionality of the 'tools' here:
https://github.com/apache/cloudstack/tree/master/tools/git

Especially 'git-pr' creates merges with the "would be deprecated" style, so
we will probably want to adapt our tracked tooling to conform with any new
styles we adopt.

Cheers,

*Will Stevens*
CTO



On Mon, Jan 15, 2018 at 3:06 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Daan,
>
> Now that master is open for merges again, can we get a feedback here? It
> might be interesting to find a consensus and a standardize way of working
> for everybody before we start merging things in master again …
>
>
>
> On Mon, Jan 8, 2018 at 8:40 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > This might be my lack of expertise in Git (Github). I like the merge
> > commits (when merging a PR) because I can easily find the date when
> > something has been introduced to the code base. Of course, this can also
> be
> > achieved through Jira tickets and Github PRs history. This means I would
> > not mind adopting the merge and squash option on Github.
> >
> > On the other hand, regarding the second issue, I prefer the philosophy of
> > single commit PRs; otherwise, it feels pretty hard to track what was
> > introduced by a PR then. I recall seeing PRs with 100+ commits laying
> > around, and I confess that I cannot find myself in the middle of that
> > mayhem..
> >
> > Daan, could you provide more insights on the benefits of having a commit
> > per change in a PR?
> >
> > On Mon, Jan 8, 2018 at 7:30 PM, Daan Hoogland <
> daan.hoogl...@shapeblue.com
> > > wrote:
> >
> >> Marc-Aurèle and Rafael, I mean both. I know we used to require the
> first,
> >> to create the release notes in a concise way and we used to ban the
> other
> >> because it leads to unnavigable revision trees. But now that squash and
> >> merge is a functionality of github one might argue that it doesn’t
> matter
> >> anymore. Personally, I am against squashing persé, in any case. I am not
> >> the law (other than during some triathlons) so we jointly might decide
> >> differently.
> >>
> >> On 08/01/2018, 16:50, "Nicolas Vazquez" 
> >> wrote:
> >>
> >> The same as Rafael described. If it is the second case I would
> prefer
> >> rebasing the target branch and push force instead of including merge
> >> commits in a PR
> >>
> >> Obtener Outlook para Android
> >>
> >> 
> >> From: williamstev...@gmail.com  on behalf
> >> of Will Stevens 
> >> Sent: Monday, January 8, 2018 11:34:42 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: [DISCUSS] new way of github working
> >>
> >> Just a note Daan.  If a PR is merged with the `git pr ` tool in
> >> our
> >> utilities folder, it will automatically include the merge commit.
> >> Figured
> >> I should mention that...
> >>
> >> *Will Stevens*
> >> CTO
> >>
> >> 
> >>
> >> On Mon, Jan 8, 2018 at 8:26 AM, Marc-Aurèle Brothier <
> >> ma...@exoscale.ch>
> >> wrote:
> >>
> >> > Same opinion as Rafael described.
> >> >
> >> > On Mon, Jan 8, 2018 at 11:30 AM, Rafael Weingärtner <
> >> > rafaelweingart...@gmail.com> wrote:
> >> >
> >> > > I did not fully understand what you meant.
> >> > >
> >> > > Are you talking about the merge commit that can be created when
> a
> >> PR is
> >> > > merged? Or, are you talking about a merge commit that is added
> to
> >> a PR
> >> > when
> >> > > a conflict is solved by its author(s)?
> >> > >
> >> > >
> >> > > I do not have problems with the first type of merge commits.
> >> However, I
> >> > > think we should not allow the second type to get into our code
> >> base.
> >> > >
> >> > > On Mon, Jan 8, 2018 at 7:45 AM, Daan Hoogland <
> >> daan.hoogl...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Devs,
> >> > > >
> >> > > > I see a lot of merge master to branch commits appearing on
> PRs.
> >> This is
> >> > > > against prior (non-hard) agreements on how we work. It is
> >> getting to be
> >> > > the
> >> > > > daily practice so;
> >> > > > How do we feel about
> >> > > > 1. not using merge commits anymore?
> >> > > > 2. merging back as a way of solving conflicts?
> >> > > > and
> >> > > > Do we need to make a policy of it or do we let it evolve, at
> >> the risk
> >> > of
> >> > > > having more hard to track feature/version matrices?
> >> > > >
> >> > > > --
> >> > > > Daan
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Rafael Weingärtner
> >> > >
> >> >
> >>
> >> nicolas.vazq...@shapeblue.com
> >> www.shapeblue.com
> >> ,
> >> @shapeblue
> >>
> >>
> >>
> >>
> >>
> >>
> >> daan.hoogl...@shapeblue.com
> >> www.shapeblue.com
> >> 53 Chand

KVM on ubuntu

[Paul Angus]

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: [DISCUSS] new way of github working

[Rene Moser]

On 01/15/2018 09:06 PM, Rafael Weingärtner wrote:
> Daan,
> 
> Now that master is open for merges again, can we get a feedback here? It
> might be interesting to find a consensus and a standardize way of working
> for everybody before we start merging things in master again …

+1 to allow merge commits on master branch to keep history of a series
of patches when they help to understand the change.

René

4.11 RC1 KVM Issue: Incorrect hostname/no IP address

[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: [DISCUSS] running sVM and VR as HVM on XenServer

[Pierre-Luc Dion]

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 internal
> > > > > > management networks. I'd be wary trying to manage it from an
> > external
> > > > > > service like cloudstack lest it get reset upon XenServer patch.
> > This
> > > > > alone
> > > > > > makes me favor option #2. I also think option #2 simplifies
> network
> > > > > design
> > > > > > for users.
> > > > > >
> > > > > > Agreed on making this as consistent across flows as possible.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jan 12, 2018 at 9:44 AM, Rafael Weingärtner <
> > > > > > rafaelweingart...@gmail.com> wrote:
> > > > > >
> 

Re: KVM on ubuntu

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

[Wido den Hollander]

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

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