Re: Upgrading OS on hypervisors

[Rakesh v]

Hello Ivan

We upgrade only when critical security patch is released like meltdown and L1TF 
else we don't do upgrades for every single kernel release

Sent from my iPhone

> On 13-Dec-2018, at 11:05 PM, Ivan Kudryavtsev  
> wrote:
> 
> Rakesh,
> No magic exists. Migrate forth, reboot, and migrate back. What I'm really
> wondering about is why you upgrade every time, Ubuntu releases a new
> kernel... There are a pretty small amount of fixes related to KVM and hosts
> are located in the private networks, they are single-tenant. Maybe you just
> have to change to policy for that?
> 
> чт, 13 дек. 2018 г. в 16:54, Rakesh v :
> 
>> Hello Folks
>> 
>> I have a question regarding upgrading OS on hypervisor. We have few
>> platforms with around 200 hypervisors in each platforms. Every time a new
>> Ubuntu kernel comes in with new security patch like L1TF fix or other , we
>> need to upgrade kernel on all hypervisors. Before rebooting hypervisor we
>> enable maintenance on it so that all vm's are migrated away. During this
>> maintenance we always see some Network interruptions because of live
>> migrations.
>> 
>> How are you guys handling such situations and how are doing the OS
>> upgrades? If you have some suggestions or using some automation tools then
>> please let know
>> 
>> I want to reduce time taken to upgrade all hypervisors without any impact
>> to Networks or VM's
>> 
>> Sent from my iPhone
> 
> 
> 
> -- 
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ 

Re: Upgrading OS on hypervisors

[Ivan Kudryavtsev]

Rakesh,
No magic exists. Migrate forth, reboot, and migrate back. What I'm really
wondering about is why you upgrade every time, Ubuntu releases a new
kernel... There are a pretty small amount of fixes related to KVM and hosts
are located in the private networks, they are single-tenant. Maybe you just
have to change to policy for that?

чт, 13 дек. 2018 г. в 16:54, Rakesh v :

> Hello Folks
>
> I have a question regarding upgrading OS on hypervisor. We have few
> platforms with around 200 hypervisors in each platforms. Every time a new
> Ubuntu kernel comes in with new security patch like L1TF fix or other , we
> need to upgrade kernel on all hypervisors. Before rebooting hypervisor we
> enable maintenance on it so that all vm's are migrated away. During this
> maintenance we always see some Network interruptions because of live
> migrations.
>
> How are you guys handling such situations and how are doing the OS
> upgrades? If you have some suggestions or using some automation tools then
> please let know
>
> I want to reduce time taken to upgrade all hypervisors without any impact
> to Networks or VM's
>
> Sent from my iPhone



-- 
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ 

Upgrading OS on hypervisors

[Rakesh v]

Hello Folks

I have a question regarding upgrading OS on hypervisor. We have few platforms 
with around 200 hypervisors in each platforms. Every time a new Ubuntu kernel 
comes in with new security patch like L1TF fix or other , we need to upgrade 
kernel on all hypervisors. Before rebooting hypervisor we enable maintenance on 
it so that all vm's are migrated away. During this maintenance we always see 
some Network interruptions because of live migrations. 

How are you guys handling such situations and how are doing the OS upgrades? If 
you have some suggestions or using some automation tools then please let know

I want to reduce time taken to upgrade all hypervisors without any impact to 
Networks or VM's

Sent from my iPhone

Re: Resource Allocation Question

[Andrija Panic]

In my case, hyperthreading number of cores (whatever OS sees as number of
cores) times the TurboBoost GHZ is what I get, so for 2x8 cored 2.6Ghz (32
cores with hyperthreading) I get 32 x 3.4 Ghz, which is not what you can
achieve at any time (that frequency can be obtained on only very few cores
at any moment, not nearly all cores).

Go to Host in GUI and check its statistics, you will see - take into
account any overprovisioning applied

Cheers

On Thu, Dec 13, 2018, 20:19 Rafael Weingärtner  You have a four core CPU, with 8 threads each? Then, each thread is 2.4
> GHz. So, 2.4 * 4 * 8.
>
> On Thu, Dec 13, 2018 at 6:14 PM Asai  wrote:
>
> > Greetings,
> >
> > I have a simple question regarding Cloudstack resource allocation.
> >
> > In the dashboard, I’m seeing that our Memory is 25 out of 30 GB and the
> > circle is colored red.  # of CPUs is 20 out of 24 and is colored red.
> But
> > CPU is 33 GHz out of 76 GHz.  We have a single Xeon E5-2620 v3 @ 2.40GHz.
> > This is a 4 core / 8 thread CPU.  How is that we have 76 GHz available?
> It
> > seems like we’d have around 57 or so GHz available.
> >
> > Thanks for your assistance.
> >
> > Asai
> >
> >
> >
>
> --
> Rafael Weingärtner
>

Re: CloudStack Collab in Brazil

[Rafael Weingärtner]

Hello CloudStackers,

I had a few meetings with the TDC folks, and we seem to be moving on. They
have a slightly different organization than ApacheCon though. Therefore, we
were asked to provide them with some “track topics” that fit in the area of
Cloud Computing. Then, we could direct presentations to one of these
tracks. The idea is that the international tracks (the ones that will be in
English) will not be parallelized to enable the audience to attend all of
them (this means, one for each day). Also, the tracks will receive
presentations from other people that are not in our bubble, and this is
great (at least I found this awesome), because different people with
different backgrounds would come together on the same track, which in turn
means, people that might not know ACS would have the opportunity not just
to meet the solution, but also the people behind it.

So, this is what I have in mind:

   - Cloud computing (area/topic)
  - cloud orchestration -- this would be the track where topics
  regarding features, and cloud orchestration systems (e.g. CloudStack)
  design and structure would be presented
  - DevOps -- track for presentations that address the day-to-day of
  CloudStack (or OpenStack) developers and the daily life of operators with
  tasks such as debugging and troubleshooting
  - tests -- track for discussing the Q process and testing methods
  for clouds
  - cloud open source ecosystem -- track focusing on the cloud
  ecosystem, where people can address things relating the job market,
  business opportunities, and the management process of highly
heterogeneous
  and distributed communities in OpenSource (such as CloudStack)


What do you guys think of these divisions for the CFP?
Also, we might need help to review and select presentation proposals. Would
some of you guys be willing to help on this process?

And last, but not least, it would be awesome if companies linked to ACS are
interested to be the sponsors of tracks or the event. They have sent me the
brochure and sponsorship prospects from 2018 so we can get to know better
the conference [1]. The attendance report and prospectus are in English,
and for instance, in 2018 the TDC event in Florianopolis (where we are
proposing to have CCC in 2019) received about 4000 people. The sponsorship
prospectus for 2019 events is being prepared, and I guess if there are
interested parties on this, you can reach them directly, or if you have
some problems to do that, I can help you guys as well.

[1]
https://www.dropbox.com/sh/53ujp2usf402dlj/AAA1a2jZPddGcAT8ZosRiGCAa?dl=0

On Wed, Oct 24, 2018 at 8:16 PM Tutkowski, Mike 
wrote:

> Thanks, Rafael!
>
> The dates work for me.
>
> Get Outlook for iOS
> 
> From: Rafael Weingärtner 
> Sent: Wednesday, October 24, 2018 5:02:14 PM
> To: users
> Cc: dev
> Subject: Re: CloudStack Collab in Brazil
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
>
> Yes, they already have a date set. It should be 23 -  27 April, 2019.
> I should be talking with them again this week to check what we need to move
> thing forward.
>
> What do you guys think about these dates?
>
> On Mon, Oct 22, 2018 at 5:07 PM Tutkowski, Mike  >
> wrote:
>
> > Hi Rafael,
> >
> > Do you have a specific date in mind for CCC Brazil? It sounds like, in
> > general, we are looking at April.
> >
> > Thanks!
> > Mike
> >
> > On 10/1/18, 12:51 PM, "Rafael Weingärtner" 
> > wrote:
> >
> > NetApp Security WARNING: This is an external email. Do not click
> links
> > or open attachments unless you recognize the sender and know the content
> is
> > safe.
> >
> >
> >
> >
> > Yes, that is what I also believe. From the feedback, I think we can
> > easily
> > use 10 presentations. I will move on with the organization. I think
> it
> > is
> > feasible to get more room space in case we receive more presentation
> > and
> > people. I will try to not overlap presentations though (like we did
> in
> > ApacheCon).
> >
> > On Mon, Oct 1, 2018 at 3:36 PM Tutkowski, Mike <
> > mike.tutkow...@netapp.com>
> > wrote:
> >
> > > I guess it depends on how many people expect to be able to attend.
> > >
> > > Ten presentation slots is probably a good starting point.
> > >
> > > Get Outlook for iOS
> > > 
> > > From: Rafael Weingärtner 
> > > Sent: Monday, October 1, 2018 10:10:55 AM
> > > To: users
> > > Cc: dev
> > > Subject: Re: CloudStack Collab in Brazil
> > >
> > > NetApp Security WARNING: This is an external email. Do not click
> > links or
> > > open attachments unless you recognize the sender and know the
> > content is
> > > safe.
> > >
> > >
> > >
> > >
> > > Thank you guys for the 

Re: Resource Allocation Question

[Rafael Weingärtner]

You have a four core CPU, with 8 threads each? Then, each thread is 2.4
GHz. So, 2.4 * 4 * 8.

On Thu, Dec 13, 2018 at 6:14 PM Asai  wrote:

> Greetings,
>
> I have a simple question regarding Cloudstack resource allocation.
>
> In the dashboard, I’m seeing that our Memory is 25 out of 30 GB and the
> circle is colored red.  # of CPUs is 20 out of 24 and is colored red.  But
> CPU is 33 GHz out of 76 GHz.  We have a single Xeon E5-2620 v3 @ 2.40GHz.
> This is a 4 core / 8 thread CPU.  How is that we have 76 GHz available?  It
> seems like we’d have around 57 or so GHz available.
>
> Thanks for your assistance.
>
> Asai
>
>
>

-- 
Rafael Weingärtner

Resource Allocation Question

[Asai]

Greetings,

I have a simple question regarding Cloudstack resource allocation.

In the dashboard, I’m seeing that our Memory is 25 out of 30 GB and the circle 
is colored red.  # of CPUs is 20 out of 24 and is colored red.  But CPU is 33 
GHz out of 76 GHz.  We have a single Xeon E5-2620 v3 @ 2.40GHz.  This is a 4 
core / 8 thread CPU.  How is that we have 76 GHz available?  It seems like we’d 
have around 57 or so GHz available.

Thanks for your assistance.

Asai

Re: How to Reorganise Storage Tags

[Andrija Panic]

Hi Melanie,

I did change it, yes (tags on existing offerings) and no need to restart
mgmt, just I once had to wait for a minute or two, but Im sure it was me
messed up something at that specific moment.

Tags are evaluated during creation of the volume only (and obviously when
changing offering as you can see) and not relevant later for the volume -
vs. i.e. cache mode (writeback etc.) which is read during starting VM
(attaching volume to VM in boot process).

Let me know if I can help more.

Cheers

On Thu, Dec 13, 2018, 18:41 Melanie Desaive  Hi andrija,
>
> thanks a lot for your answer.
>
> Indeed is absolutely sufficient for me to know that I may change
> disk_offering_id for a volume. I would assume it is not necessary to shut
> down/restart the VM or restart management service, but will try tomorrow.
>
> I will figure out a suitable path to migrate the volumes to their
> destination pools and also change the offering to those with the desired
> tags that way. Absolutely ok for me to do it in two or more steps.
>
> Anyone ever changed disk_offering.tags manually?
>
> Anyway, happy to see a solution for my task and looking forward to try it
> out tomorrow.
>
> Greetings,
>
> Melanie
>
> ⁣Gesendet mit BlueMail ​
>
> Am 13. Dez. 2018, 17:32, um 17:32, Andrija Panic 
> schrieb:
> >Hi Melanie,
> >
> >when  moving volume to new storage, when you want to change disk
> >offering
> >(or compute offering for ROOT disk...), ACS doesn't allow that - it
> >lists
> >only offerings that have same tag as current offering (not good...)
> >
> >We have inhouse patch, so that you CAN do that, by making sure to list
> >all
> >offergins that have TAG that matches the TAG of the new destination
> >pool of
> >the volume (hope Im clear here).
> >
> >All volumes read tag from their offering - so just either change
> >disk_offering_id filed for each moved/migrated volume  to point to same
> >sized offering on new storage - and then normally change it once more
> >via
> >UI to a new once etc - or manualy change to smaller disk offering (DB
> >edit)
> >and later via UI/API to correct (same size) disk offering (or bigger if
> >you
> >want to really resize)
> >
> >I can try to share a patch in a non-developer, copy/paste way - in case
> >you
> >want to patch your ACS to support this (as explained at the begining of
> >the
> >email...)
> >
> >Hope that helps
> >
> >Cheers
> >
> >On Thu, 13 Dec 2018 at 13:50, Melanie Desaive
> >
> >wrote:
> >
> >> Hi all,
> >>
> >> we are currently reorganizing our SAN Setup and I would like to
> >> introduce new storage tags on my existing volumes.
> >>
> >> I was naively assuming to simply change the tags or offering by GUI
> >or
> >> API calls.
> >>
> >> Does not seem to work. Only way to change the tags, seems to be by
> >using
> >> a new disk offering, which is denied, when the tags between old and
> >new
> >> offering differ. :( Or am I missing something?
> >>
> >> I had a look into the cloud database, and the storage tags, seem to
> >be
> >> only stored in
> >>
> >>   disk_offering.tags
> >> and
> >>   storage_pool_tags.tag
> >>
> >> Would it be a valid option for me to update disk_offering.tags by SQL
> >to
> >> the desired value or could that break some deeper logic?
> >>
> >> Or is there even a better way to change the storage tags for existing
> >> volumes. (With or without downtime for the VMs)
> >>
> >> Looking forward to any advice!
> >>
> >> Greetings,
> >>
> >> Melanie
> >> --
> >> --
> >>
> >> Heinlein Support GmbH
> >> Linux: Akademie - Support - Hosting
> >>
> >> http://www.heinlein-support.de
> >> Tel: 030 / 40 50 51 - 0
> >> Fax: 030 / 40 50 51 - 19
> >>
> >> Zwangsangaben lt. §35a GmbHG:
> >> HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
> >> Geschäftsführer: Peer Heinlein  -- Sitz: Berlin
> >>
> >>
> >
> >--
> >
> >Andrija Panić
>

Re: How to Reorganise Storage Tags

[Melanie Desaive]

Hi andrija,

thanks a lot for your answer.

Indeed is absolutely sufficient for me to know that I may change 
disk_offering_id for a volume. I would assume it is not necessary to shut 
down/restart the VM or restart management service, but will try tomorrow.

I will figure out a suitable path to migrate the volumes to their destination 
pools and also change the offering to those with the desired tags that way. 
Absolutely ok for me to do it in two or more steps.

Anyone ever changed disk_offering.tags manually?

Anyway, happy to see a solution for my task and looking forward to try it out 
tomorrow.

Greetings,

Melanie

⁣Gesendet mit BlueMail ​

Am 13. Dez. 2018, 17:32, um 17:32, Andrija Panic  
schrieb:
>Hi Melanie,
>
>when  moving volume to new storage, when you want to change disk
>offering
>(or compute offering for ROOT disk...), ACS doesn't allow that - it
>lists
>only offerings that have same tag as current offering (not good...)
>
>We have inhouse patch, so that you CAN do that, by making sure to list
>all
>offergins that have TAG that matches the TAG of the new destination
>pool of
>the volume (hope Im clear here).
>
>All volumes read tag from their offering - so just either change
>disk_offering_id filed for each moved/migrated volume  to point to same
>sized offering on new storage - and then normally change it once more
>via
>UI to a new once etc - or manualy change to smaller disk offering (DB
>edit)
>and later via UI/API to correct (same size) disk offering (or bigger if
>you
>want to really resize)
>
>I can try to share a patch in a non-developer, copy/paste way - in case
>you
>want to patch your ACS to support this (as explained at the begining of
>the
>email...)
>
>Hope that helps
>
>Cheers
>
>On Thu, 13 Dec 2018 at 13:50, Melanie Desaive
>
>wrote:
>
>> Hi all,
>>
>> we are currently reorganizing our SAN Setup and I would like to
>> introduce new storage tags on my existing volumes.
>>
>> I was naively assuming to simply change the tags or offering by GUI
>or
>> API calls.
>>
>> Does not seem to work. Only way to change the tags, seems to be by
>using
>> a new disk offering, which is denied, when the tags between old and
>new
>> offering differ. :( Or am I missing something?
>>
>> I had a look into the cloud database, and the storage tags, seem to
>be
>> only stored in
>>
>>   disk_offering.tags
>> and
>>   storage_pool_tags.tag
>>
>> Would it be a valid option for me to update disk_offering.tags by SQL
>to
>> the desired value or could that break some deeper logic?
>>
>> Or is there even a better way to change the storage tags for existing
>> volumes. (With or without downtime for the VMs)
>>
>> Looking forward to any advice!
>>
>> Greetings,
>>
>> Melanie
>> --
>> --
>>
>> Heinlein Support GmbH
>> Linux: Akademie - Support - Hosting
>>
>> http://www.heinlein-support.de
>> Tel: 030 / 40 50 51 - 0
>> Fax: 030 / 40 50 51 - 19
>>
>> Zwangsangaben lt. §35a GmbHG:
>> HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
>> Geschäftsführer: Peer Heinlein  -- Sitz: Berlin
>>
>>
>
>--
>
>Andrija Panić

Re: How to Reorganise Storage Tags

[Andrija Panic]

Hi Melanie,

when  moving volume to new storage, when you want to change disk offering
(or compute offering for ROOT disk...), ACS doesn't allow that - it lists
only offerings that have same tag as current offering (not good...)

We have inhouse patch, so that you CAN do that, by making sure to list all
offergins that have TAG that matches the TAG of the new destination pool of
the volume (hope Im clear here).

All volumes read tag from their offering - so just either change
disk_offering_id filed for each moved/migrated volume  to point to same
sized offering on new storage - and then normally change it once more via
UI to a new once etc - or manualy change to smaller disk offering (DB edit)
and later via UI/API to correct (same size) disk offering (or bigger if you
want to really resize)

I can try to share a patch in a non-developer, copy/paste way - in case you
want to patch your ACS to support this (as explained at the begining of the
email...)

Hope that helps

Cheers

On Thu, 13 Dec 2018 at 13:50, Melanie Desaive 
wrote:

> Hi all,
>
> we are currently reorganizing our SAN Setup and I would like to
> introduce new storage tags on my existing volumes.
>
> I was naively assuming to simply change the tags or offering by GUI or
> API calls.
>
> Does not seem to work. Only way to change the tags, seems to be by using
> a new disk offering, which is denied, when the tags between old and new
> offering differ. :( Or am I missing something?
>
> I had a look into the cloud database, and the storage tags, seem to be
> only stored in
>
>   disk_offering.tags
> and
>   storage_pool_tags.tag
>
> Would it be a valid option for me to update disk_offering.tags by SQL to
> the desired value or could that break some deeper logic?
>
> Or is there even a better way to change the storage tags for existing
> volumes. (With or without downtime for the VMs)
>
> Looking forward to any advice!
>
> Greetings,
>
> Melanie
> --
> --
>
> Heinlein Support GmbH
> Linux: Akademie - Support - Hosting
>
> http://www.heinlein-support.de
> Tel: 030 / 40 50 51 - 0
> Fax: 030 / 40 50 51 - 19
>
> Zwangsangaben lt. §35a GmbHG:
> HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
> Geschäftsführer: Peer Heinlein  -- Sitz: Berlin
>
>

-- 

Andrija Panić

Re: URGENT: Unable to schedule async job for command com.cloud.vm.VmWorkStart, unexpected exception

[Andrija Panic]

Done it once (8h old DB)...make sure to kill any new VMs that were created
in that period of time (and volumes/templates on the end storage).

You might run into situation that some VMs are i.e. powered on during that
last 8h, so DB state for that VM will not be in sync with reality, but that
should be synced shorty after.

I.e. hope that a very few changes/creations of any resources have happened
during that period - and expect some stuff will need to be manually
synced/fixed/repeated - i.e. user created PF rule on VR, but now you have
restored DB so - that might be a challenge to fix without pissing off users
:)

Fingers crossed!

On Thu, Dec 13, 2018, 14:33 Ugo Vasi  Hi all,
> is there anyone who tried to restore the database a day ago and
> restarted cloudstack manager?
>
> The two situations differ for the status of the VM / VR and I do not
> know what to expect and bearing in mind that the problem could recur.
>
> The statistics don't interest me.
>
>
> Il 13/12/18 10:39, Ugo Vasi ha scritto:
> > We have verified that the problem is not tied to a vm but it also
> > concerns the other VMs that are stopped. Trying to restart them gives
> > the same error message.
> >
> > Restoring the previous day's database which problems might imply?
> >
> >
> > Il 13/12/18 09:01, Ugo Vasi ha scritto:
> >> Hi all,
> >> I'm trying to reboot a vm after the host it ran on crashed and
> >> restarted from the HA system. All the VMs running on the rebooted
> >> host were restarted on other hosts except one.
> >> In the web interface and using cloudmonkey I get this message:
> >>   "Unable to schedule async job for command com.cloud.vm.VmWorkStart,
> >> unexpected exception."
> >>
> >> In the management-server.log file there would seem to be a problem
> >> when creating an element that is duplicated (Duplicate entry ''
> >> for key 'PRIMARY'):
> >>
> >> 2018-12-13 08:44:06,659 DEBUG [c.c.a.ApiServlet]
> >> (qtp1096283470-445:ctx-6c065e06) (logid:87edf8d7) ===START===
> >> 10.80.0.6 -- GET
> >>
> command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
> >> 2018-12-13 08:44:06,665 DEBUG [c.c.a.ApiServer]
> >> (qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) CIDRs
> >> from which account 'Acct[26e597f2-b5ca-11e8-a619-c8cbb8cb15cd-admin]'
> >> is allowed to perform API calls: 0.0.0.0/0,::/0
> >> 2018-12-13 08:44:06,693 INFO  [o.a.c.f.j.i.AsyncJobMonitor]
> >> (API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:7e0c4dc9) Add
> >> job-1343 into job monitoring
> >> 2018-12-13 08:44:06,698 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> >> (qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) submit
> >> async job-1343, details: AsyncJobVO {id:1343, userId: 2, accountId:
> >> 2, instanceType: VirtualMachine, instanceId: 8, cmd:
> >> org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin,
> >> cmdInfo:
> >>
> {"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface
>
> >>
> com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"},
>
> >> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> >> result: null, initMsid: 220777304233416, completeMsid: null,
> >> lastUpdated: null, lastPolled: null, created: null}
> >> 2018-12-13 08:44:06,700 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> >> (API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:6e9a71c5) Executing
> >> AsyncJobVO {id:1343, userId: 2, accountId: 2, instanceType:
> >> VirtualMachine, instanceId: 8, cmd:
> >> org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin,
> >> cmdInfo:
> >>
> {"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface
>
> >>
> com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"},
>
> >> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> >> result: null, initMsid: 220777304233416, completeMsid: null,
> >> lastUpdated: null, lastPolled: null, created: null}
> >> 2018-12-13 08:44:06,705 DEBUG [c.c.a.ApiServlet]
> >> (qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7)
> >> ===END===  10.80.0.6 -- GET
> >>
> command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
> >> 2018-12-13 08:44:06,745 DEBUG [c.c.n.NetworkModelImpl]
> >> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5)
> >> (logid:6e9a71c5) Service SecurityGroup is not supported in the
> >> network id=205
> >> 2018-12-13 08:44:06,752 DEBUG [c.c.n.NetworkModelImpl]
> >> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5)
> >> (logid:6e9a71c5) Service SecurityGroup is not supported in the
> >> network id=205
> >> 2018-12-13 

Re: AW:DNS in virtual router not stable

[Ivan X Yue]

Hi, Ben,

Thanks for the reply.  We have been thinking about updating /etc/hosts of 
each of the VM to add the entries for other VMs.  Then we don't have 
dependency to the DNS in the virtual router.  But there's lots of work as 
VMs are being added / removed continuously in our case.  I just hope there 
will be easier solution.

Thanks
Ivan




From:   Benjamin Naber 
To: "users@cloudstack.apache.org" 
Date:   2018/12/13 09:39 AM
Subject:AW:DNS in virtual router not stable



Hi Ivan,

I've seen this problem to. The solution is to handle your ip address by 
the host youre adding static by api or gui. The router VM uses the old 
host entries set in /etc/hosts if you cleanup vpc network. The host file 
will be cleared.

Kind Regards

Ben

Von meinem Huawei-Mobiltelefon gesendet

 Originalnachricht 
Betreff: DNS in virtual router not stable
Von: Ivan X Yue 
An: users@cloudstack.apache.org
Cc:


Hi, all, 

We are using Cloudstack 4.9.2 with KVM and advance networking


We are having VPC network, and need to continuously adding / removing VM. 
One issue we found is, from time-to-time, on the VM deployed, it gets 
error that the hostname of the other VM is not resolved.  We dig into the 
VR, and it seems that every time a VM is added or removed, the dnsmasq 
needs to be restarted.  And based on /var/log/dnsmasq.log, there is 2 
second delay before dnsmasq is running again.  Quite likely while restart 
is happening, the DNS is not working and therefore VM will not be able to 
resolve hostname. 

Dec 12 15:22:55 dnsmasq[6479]: exiting on receipt of SIGTERM
Dec 12 15:22:57 dnsmasq[6747]: started, version 2.62 cachesize 150
Dec 12 15:26:36 dnsmasq[6747]: exiting on receipt of SIGTERM
Dec 12 15:26:38 dnsmasq[28921]: started, version 2.62 cachesize 150


We don't see this issue in CloudStack 4.11.  In 4.11, we also see dnsmasq 
being restarted in dnsmasq.log, but there is no delay between exiting and 
started. 

Is there anything we can do in 4.9.2 to have the DNS more stable.  e.g. 
can dnsmasq not being restarted even new VM info is added?  Or can it just 

reload the VM info?


Thanks
Ivan

Re: new committer: Boris Stoyanov (AKA Bobby)

[Simon Weller]

Congrats Bobby, much deserved!



From: Paul Angus 
Sent: Thursday, December 13, 2018 3:22 AM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Cc: Boris Stoyanov
Subject: new committer: Boris Stoyanov (AKA Bobby)

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack
has invited Boris Stoyanov to become a committer and we are pleased
to announce that he has accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.



paul.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue

AW:DNS in virtual router not stable

[Benjamin Naber]

Hi Ivan,

I've seen this problem to. The solution is to handle your ip address by the 
host youre adding static by api or gui. The router VM uses the old host entries 
set in /etc/hosts if you cleanup vpc network. The host file will be cleared.

Kind Regards

Ben

Von meinem Huawei-Mobiltelefon gesendet

 Originalnachricht 
Betreff: DNS in virtual router not stable
Von: Ivan X Yue 
An: users@cloudstack.apache.org
Cc:


Hi, all, 

We are using Cloudstack 4.9.2 with KVM and advance networking


We are having VPC network, and need to continuously adding / removing VM. 
One issue we found is, from time-to-time, on the VM deployed, it gets 
error that the hostname of the other VM is not resolved.  We dig into the 
VR, and it seems that every time a VM is added or removed, the dnsmasq 
needs to be restarted.  And based on /var/log/dnsmasq.log, there is 2 
second delay before dnsmasq is running again.  Quite likely while restart 
is happening, the DNS is not working and therefore VM will not be able to 
resolve hostname. 

Dec 12 15:22:55 dnsmasq[6479]: exiting on receipt of SIGTERM
Dec 12 15:22:57 dnsmasq[6747]: started, version 2.62 cachesize 150
Dec 12 15:26:36 dnsmasq[6747]: exiting on receipt of SIGTERM
Dec 12 15:26:38 dnsmasq[28921]: started, version 2.62 cachesize 150


We don't see this issue in CloudStack 4.11.  In 4.11, we also see dnsmasq 
being restarted in dnsmasq.log, but there is no delay between exiting and 
started. 

Is there anything we can do in 4.9.2 to have the DNS more stable.  e.g. 
can dnsmasq not being restarted even new VM info is added?  Or can it just 
reload the VM info?


Thanks
Ivan

Re: new committer: Boris Stoyanov (AKA Bobby)

[David Merrill]

Congratulations Bobby!

David Merrill
Senior Systems Engineer,
Managed and Private/Hybrid Cloud Services
OTELCO
92 Oak Street, Portland ME 04101
office 207.772.5678 
www.otelco.com /business/managed-services



Confidentiality Message
The information contained in this e-mail transmission may be confidential and 
legally privileged. If you are not the intended recipient, you are notified 
that any dissemination, distribution, copying or other use of this information, 
including attachments, is prohibited. If you received this message in error, 
please call me at 207.772.5678  so this error can be 
corrected.
 

On 12/13/18, 4:29 AM, "Paul Angus"  wrote:

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack
has invited Boris Stoyanov to become a committer and we are pleased
to announce that he has accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.



paul.an...@shapeblue.com 

https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.shapeblue.com=E,1,nlORnGdUEbciiUrUkTr9xyZn1xdp_w08yCq7iIvb9x2ptc1qqqw7JDt95iwLE-dBWXIiznkWkF4seNyqjPple__CogCxN6f-gbjbh4wV6g,,=1
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Re: URGENT: Unable to schedule async job for command com.cloud.vm.VmWorkStart, unexpected exception

[Ugo Vasi]

Hi all,
is there anyone who tried to restore the database a day ago and 
restarted cloudstack manager?


The two situations differ for the status of the VM / VR and I do not 
know what to expect and bearing in mind that the problem could recur.


The statistics don't interest me.


Il 13/12/18 10:39, Ugo Vasi ha scritto:
We have verified that the problem is not tied to a vm but it also 
concerns the other VMs that are stopped. Trying to restart them gives 
the same error message.


Restoring the previous day's database which problems might imply?


Il 13/12/18 09:01, Ugo Vasi ha scritto:

Hi all,
I'm trying to reboot a vm after the host it ran on crashed and 
restarted from the HA system. All the VMs running on the rebooted 
host were restarted on other hosts except one.

In the web interface and using cloudmonkey I get this message:
  "Unable to schedule async job for command com.cloud.vm.VmWorkStart, 
unexpected exception."


In the management-server.log file there would seem to be a problem 
when creating an element that is duplicated (Duplicate entry '' 
for key 'PRIMARY'):


2018-12-13 08:44:06,659 DEBUG [c.c.a.ApiServlet] 
(qtp1096283470-445:ctx-6c065e06) (logid:87edf8d7) ===START=== 
10.80.0.6 -- GET 
command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
2018-12-13 08:44:06,665 DEBUG [c.c.a.ApiServer] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) CIDRs 
from which account 'Acct[26e597f2-b5ca-11e8-a619-c8cbb8cb15cd-admin]' 
is allowed to perform API calls: 0.0.0.0/0,::/0
2018-12-13 08:44:06,693 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:7e0c4dc9) Add 
job-1343 into job monitoring
2018-12-13 08:44:06,698 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) submit 
async job-1343, details: AsyncJobVO {id:1343, userId: 2, accountId: 
2, instanceType: VirtualMachine, instanceId: 8, cmd: 
org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, 
cmdInfo: 
{"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface 
com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"}, 
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, 
result: null, initMsid: 220777304233416, completeMsid: null, 
lastUpdated: null, lastPolled: null, created: null}
2018-12-13 08:44:06,700 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:6e9a71c5) Executing 
AsyncJobVO {id:1343, userId: 2, accountId: 2, instanceType: 
VirtualMachine, instanceId: 8, cmd: 
org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, 
cmdInfo: 
{"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface 
com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"}, 
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, 
result: null, initMsid: 220777304233416, completeMsid: null, 
lastUpdated: null, lastPolled: null, created: null}
2018-12-13 08:44:06,705 DEBUG [c.c.a.ApiServlet] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) 
===END===  10.80.0.6 -- GET 
command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
2018-12-13 08:44:06,745 DEBUG [c.c.n.NetworkModelImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Service SecurityGroup is not supported in the 
network id=205
2018-12-13 08:44:06,752 DEBUG [c.c.n.NetworkModelImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Service SecurityGroup is not supported in the 
network id=205
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) DeploymentPlanner allocation algorithm: null
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Trying to allocate a host and storage pools from 
dc:1, pod:null,cluster:null, requested cpu: 8000, requested ram: 
8594128896
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Is ROOT volume READY (pool already allocated)?: Yes
2018-12-13 08:44:06,783 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Deploy avoids pods: [], clusters: [], hosts: []
2018-12-13 08:44:06,784 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) 

DNS in virtual router not stable

[Ivan X Yue]

Hi, all, 

We are using Cloudstack 4.9.2 with KVM and advance networking


We are having VPC network, and need to continuously adding / removing VM. 
One issue we found is, from time-to-time, on the VM deployed, it gets 
error that the hostname of the other VM is not resolved.  We dig into the 
VR, and it seems that every time a VM is added or removed, the dnsmasq 
needs to be restarted.  And based on /var/log/dnsmasq.log, there is 2 
second delay before dnsmasq is running again.  Quite likely while restart 
is happening, the DNS is not working and therefore VM will not be able to 
resolve hostname. 

Dec 12 15:22:55 dnsmasq[6479]: exiting on receipt of SIGTERM
Dec 12 15:22:57 dnsmasq[6747]: started, version 2.62 cachesize 150
Dec 12 15:26:36 dnsmasq[6747]: exiting on receipt of SIGTERM
Dec 12 15:26:38 dnsmasq[28921]: started, version 2.62 cachesize 150


We don't see this issue in CloudStack 4.11.  In 4.11, we also see dnsmasq 
being restarted in dnsmasq.log, but there is no delay between exiting and 
started. 

Is there anything we can do in 4.9.2 to have the DNS more stable.  e.g. 
can dnsmasq not being restarted even new VM info is added?  Or can it just 
reload the VM info?


Thanks
Ivan

How to Reorganise Storage Tags

[Melanie Desaive]

Hi all,

we are currently reorganizing our SAN Setup and I would like to
introduce new storage tags on my existing volumes.

I was naively assuming to simply change the tags or offering by GUI or
API calls.

Does not seem to work. Only way to change the tags, seems to be by using
a new disk offering, which is denied, when the tags between old and new
offering differ. :( Or am I missing something?

I had a look into the cloud database, and the storage tags, seem to be
only stored in

  disk_offering.tags
and
  storage_pool_tags.tag

Would it be a valid option for me to update disk_offering.tags by SQL to
the desired value or could that break some deeper logic?

Or is there even a better way to change the storage tags for existing
volumes. (With or without downtime for the VMs)

Looking forward to any advice!

Greetings,

Melanie
-- 
--

Heinlein Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de
Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin



signature.asc
Description: OpenPGP digital signature

Re: URGENT: Unable to schedule async job for command com.cloud.vm.VmWorkStart, unexpected exception

[Rene Moser]

Hi

On 12/13/18 11:50 AM, Ugo Vasi wrote:
> Hi René ,
> the cloustack installation is 4.11.1.0. From the issue you reported to
> me I do not understand if the problem has been solved or not..
> 
> The big problem is that I can not perform any new jobs.
> 
> In addition to the stopped VM there are two routes that were running on
> the host that has crashed.
> 
> One of these routers was redundant as a master of one of the isolated
> networks along with another that has taken its place and is now working.

As far as I can see, this issue is not solved. It is exactly the same
issue we encountered. It seems, that after a while "job timeout? job
cleanup time?" you will be able to run jobs again.

The guys from shapeblue should know more.

Regards
René

Re: new committer: Boris Stoyanov (AKA Bobby)

[Boris Stoyanov]

Thanks all! 

It’s an honor for me, I look forward to brake your code! :) 

Bobby.


boris.stoya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

> On 13 Dec 2018, at 13:49, Gabriel Beims Bräscher  wrote:
> 
> Congrats Bobby, well deserved!
> 
> Em qui, 13 de dez de 2018 às 09:24, Rohit Yadav 
> escreveu:
> 
>> Welcome Bobby (Boris)! Well deserved.
>> 
>> 
>> - Rohit
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Paul Angus 
>> Sent: Thursday, December 13, 2018 2:52:12 PM
>> To: users@cloudstack.apache.org; d...@cloudstack.apache.org
>> Cc: Boris Stoyanov
>> Subject: new committer: Boris Stoyanov (AKA Bobby)
>> 
>> Hi Everyone,
>> 
>> The Project Management Committee (PMC) for Apache CloudStack
>> has invited Boris Stoyanov to become a committer and we are pleased
>> to announce that he has accepted.
>> 
>> Please join me in congratulating Bobby!
>> 
>> 
>> Being a committer enables easier contribution to the
>> project since there is no need to go via the patch
>> submission process. This should enable better productivity.
>> Being a PMC member enables assistance with the management
>> and to guide the direction of the project.
>> 
>> 
>> 
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> Amadeus House, Floral Street, London  WC2E 9DPUK
>> @shapeblue
>> 
>> 
>> 
>> 
>> rohit.ya...@shapeblue.com
>> www.shapeblue.com
>> Amadeus House, Floral Street, London  WC2E 9DPUK
>> @shapeblue
>> 
>> 
>> 
>> 

Re: new committer: Boris Stoyanov (AKA Bobby)

[Gabriel Beims Bräscher]

Congrats Bobby, well deserved!

Em qui, 13 de dez de 2018 às 09:24, Rohit Yadav 
escreveu:

> Welcome Bobby (Boris)! Well deserved.
>
>
> - Rohit
>
> 
>
>
>
> 
> From: Paul Angus 
> Sent: Thursday, December 13, 2018 2:52:12 PM
> To: users@cloudstack.apache.org; d...@cloudstack.apache.org
> Cc: Boris Stoyanov
> Subject: new committer: Boris Stoyanov (AKA Bobby)
>
> Hi Everyone,
>
> The Project Management Committee (PMC) for Apache CloudStack
> has invited Boris Stoyanov to become a committer and we are pleased
> to announce that he has accepted.
>
> Please join me in congratulating Bobby!
>
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> Being a PMC member enables assistance with the management
> and to guide the direction of the project.
>
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>

Re: new committer: Boris Stoyanov (AKA Bobby)

[Rohit Yadav]

Welcome Bobby (Boris)! Well deserved.


- Rohit






From: Paul Angus 
Sent: Thursday, December 13, 2018 2:52:12 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Cc: Boris Stoyanov
Subject: new committer: Boris Stoyanov (AKA Bobby)

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack
has invited Boris Stoyanov to become a committer and we are pleased
to announce that he has accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.



paul.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




rohit.ya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Re: new committer: Boris Stoyanov (AKA Bobby)

[Nicolas Vazquez]

Congratulations Bobby!


Regards,

Nicolas Vazquez


From: Dingane Hlaluku 
Sent: Thursday, December 13, 2018 7:54:56 AM
To: d...@cloudstack.apache.org; users@cloudstack.apache.org
Cc: Boris Stoyanov
Subject: Re: new committer: Boris Stoyanov (AKA Bobby)

Congratulations Bobby, well deserved.


Regards,


From: Glenn Wagner 
Sent: Thursday, December 13, 2018 12:20:36 PM
To: d...@cloudstack.apache.org; users@cloudstack.apache.org
Cc: Boris Stoyanov
Subject: RE: new committer: Boris Stoyanov (AKA Bobby)

Congrats Bobby

-Glenn

glenn.wag...@shapeblue.com
www.shapeblue.com
Winter Suite, 1st Floor, The Avenues, Drama Street, Somerset West, Cape Town  
7129South Africa
@shapeblue




dingane.hlal...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DP
@shapeblue




nicolas.vazq...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DP
@shapeblue
  
 


-Original Message-
From: Paul Angus 
Sent: Thursday, 13 December 2018 11:22 AM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Cc: Boris Stoyanov 
Subject: new committer: Boris Stoyanov (AKA Bobby)

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack has invited Boris 
Stoyanov to become a committer and we are pleased to announce that he has 
accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the project since there is no 
need to go via the patch submission process. This should enable better 
productivity.
Being a PMC member enables assistance with the management and to guide the 
direction of the project.



paul.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue

Re: new committer: Boris Stoyanov (AKA Bobby)

[Dingane Hlaluku]

Congratulations Bobby, well deserved.


Regards,


From: Glenn Wagner 
Sent: Thursday, December 13, 2018 12:20:36 PM
To: d...@cloudstack.apache.org; users@cloudstack.apache.org
Cc: Boris Stoyanov
Subject: RE: new committer: Boris Stoyanov (AKA Bobby)

Congrats Bobby

-Glenn

glenn.wag...@shapeblue.com
www.shapeblue.com
Winter Suite, 1st Floor, The Avenues, Drama Street, Somerset West, Cape Town  
7129South Africa
@shapeblue




dingane.hlal...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DP
@shapeblue
  
 


-Original Message-
From: Paul Angus 
Sent: Thursday, 13 December 2018 11:22 AM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Cc: Boris Stoyanov 
Subject: new committer: Boris Stoyanov (AKA Bobby)

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack has invited Boris 
Stoyanov to become a committer and we are pleased to announce that he has 
accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the project since there is no 
need to go via the patch submission process. This should enable better 
productivity.
Being a PMC member enables assistance with the management and to guide the 
direction of the project.



paul.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue

Re: URGENT: Unable to schedule async job for command com.cloud.vm.VmWorkStart, unexpected exception

[Ugo Vasi]

Hi René ,
the cloustack installation is 4.11.1.0. From the issue you reported to 
me I do not understand if the problem has been solved or not..


The big problem is that I can not perform any new jobs.

In addition to the stopped VM there are two routes that were running on 
the host that has crashed.


One of these routers was redundant as a master of one of the isolated 
networks along with another that has taken its place and is now working.






Il 13/12/18 11:07, Rene Moser ha scritto:

Hi

I think you hit https://github.com/apache/cloudstack/issues/2880

Is this already 4.11.2?

We have also seen this in our lab, could not really reproduce it, seems
to be a race condition.

Regards
René

On 12/13/18 9:01 AM, Ugo Vasi wrote:

Hi all,
I'm trying to reboot a vm after the host it ran on crashed and restarted
from the HA system. All the VMs running on the rebooted host were
restarted on other hosts except one.
In the web interface and using cloudmonkey I get this message:
   "Unable to schedule async job for command com.cloud.vm.VmWorkStart,
unexpected exception."

In the management-server.log file there would seem to be a problem when
creating an element that is duplicated (Duplicate entry '' for key
'PRIMARY'):

2018-12-13 08:44:06,659 DEBUG [c.c.a.ApiServlet]
(qtp1096283470-445:ctx-6c065e06) (logid:87edf8d7) ===START=== 10.80.0.6
-- GET
command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015

2018-12-13 08:44:06,665 DEBUG [c.c.a.ApiServer]
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) CIDRs
from which account 'Acct[26e597f2-b5ca-11e8-a619-c8cbb8cb15cd-admin]' is
allowed to perform API calls: 0.0.0.0/0,::/0
2018-12-13 08:44:06,693 INFO  [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:7e0c4dc9) Add job-1343
into job monitoring
2018-12-13 08:44:06,698 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) submit
async job-1343, details: AsyncJobVO {id:1343, userId: 2, accountId: 2,
instanceType: VirtualMachine, instanceId: 8, cmd:
org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, cmdInfo:
{"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface
com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 220777304233416, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2018-12-13 08:44:06,700 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:6e9a71c5) Executing
AsyncJobVO {id:1343, userId: 2, accountId: 2, instanceType:
VirtualMachine, instanceId: 8, cmd:
org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, cmdInfo:
{"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface
com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 220777304233416, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2018-12-13 08:44:06,705 DEBUG [c.c.a.ApiServlet]
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7)
===END===  10.80.0.6 -- GET
command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015

2018-12-13 08:44:06,745 DEBUG [c.c.n.NetworkModelImpl]
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
Service SecurityGroup is not supported in the network id=205
2018-12-13 08:44:06,752 DEBUG [c.c.n.NetworkModelImpl]
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
Service SecurityGroup is not supported in the network id=205
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
DeploymentPlanner allocation algorithm: null
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
Trying to allocate a host and storage pools from dc:1,
pod:null,cluster:null, requested cpu: 8000, requested ram: 8594128896
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
Is ROOT volume READY (pool already allocated)?: Yes
2018-12-13 08:44:06,783 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
Deploy avoids pods: [], clusters: [], hosts: []
2018-12-13 08:44:06,784 DEBUG 

RE: new committer: Boris Stoyanov (AKA Bobby)

[Glenn Wagner]

Congrats Bobby 

-Glenn

glenn.wag...@shapeblue.com 
www.shapeblue.com
Winter Suite, 1st Floor, The Avenues, Drama Street, Somerset West, Cape Town  
7129South Africa
@shapeblue
  
 


-Original Message-
From: Paul Angus  
Sent: Thursday, 13 December 2018 11:22 AM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Cc: Boris Stoyanov 
Subject: new committer: Boris Stoyanov (AKA Bobby)

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack has invited Boris 
Stoyanov to become a committer and we are pleased to announce that he has 
accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the project since there is no 
need to go via the patch submission process. This should enable better 
productivity.
Being a PMC member enables assistance with the management and to guide the 
direction of the project.



paul.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
  
 

Re: new committer: Boris Stoyanov (AKA Bobby)

[Dag Sonstebo]

Congratulations Bobby!

Regards, 
Dag Sonstebo
Cloud Architect
ShapeBlue
 S: +44 20 3603 0540  | dag.sonst...@shapeblue.com | http://www.shapeblue.com 
 | Twitter:@ShapeBlue 


On 13/12/2018, 09:29, "Paul Angus"  wrote:

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack
has invited Boris Stoyanov to become a committer and we are pleased
to announce that he has accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.



paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 




dag.sonst...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Re: new committer: Boris Stoyanov (AKA Bobby)

[Andrija Panic]

Congrats Bobby !

On Thu, 13 Dec 2018 at 10:58, Sateesh Chodapuneedi <
sateesh.chodapune...@accelerite.com> wrote:

> Hearty Congratulations, Bobby!
> Well deserved.
> Bobby has been actively helping with validation of MRs under review. Also
> helping users in users list.
>
> Regards,
> Sateesh
>
>
> -Original Message-
> From: Paul Angus 
> Reply-To: "d...@cloudstack.apache.org" 
> Date: Thursday, 13 December 2018 at 14:59
> To: "users@cloudstack.apache.org" , "
> d...@cloudstack.apache.org" 
> Cc: Boris Stoyanov 
> Subject: new committer: Boris Stoyanov (AKA Bobby)
>
> Hi Everyone,
>
> The Project Management Committee (PMC) for Apache CloudStack
> has invited Boris Stoyanov to become a committer and we are pleased
> to announce that he has accepted.
>
> Please join me in congratulating Bobby!
>
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> Being a PMC member enables assistance with the management
> and to guide the direction of the project.
>
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>
>
>

-- 

Andrija Panić

Re: URGENT: Unable to schedule async job for command com.cloud.vm.VmWorkStart, unexpected exception

[Rene Moser]

Hi

I think you hit https://github.com/apache/cloudstack/issues/2880

Is this already 4.11.2?

We have also seen this in our lab, could not really reproduce it, seems
to be a race condition.

Regards
René

On 12/13/18 9:01 AM, Ugo Vasi wrote:
> Hi all,
> I'm trying to reboot a vm after the host it ran on crashed and restarted
> from the HA system. All the VMs running on the rebooted host were
> restarted on other hosts except one.
> In the web interface and using cloudmonkey I get this message:
>   "Unable to schedule async job for command com.cloud.vm.VmWorkStart,
> unexpected exception."
> 
> In the management-server.log file there would seem to be a problem when
> creating an element that is duplicated (Duplicate entry '' for key
> 'PRIMARY'):
> 
> 2018-12-13 08:44:06,659 DEBUG [c.c.a.ApiServlet]
> (qtp1096283470-445:ctx-6c065e06) (logid:87edf8d7) ===START=== 10.80.0.6
> -- GET
> command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
> 
> 2018-12-13 08:44:06,665 DEBUG [c.c.a.ApiServer]
> (qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) CIDRs
> from which account 'Acct[26e597f2-b5ca-11e8-a619-c8cbb8cb15cd-admin]' is
> allowed to perform API calls: 0.0.0.0/0,::/0
> 2018-12-13 08:44:06,693 INFO  [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:7e0c4dc9) Add job-1343
> into job monitoring
> 2018-12-13 08:44:06,698 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) submit
> async job-1343, details: AsyncJobVO {id:1343, userId: 2, accountId: 2,
> instanceType: VirtualMachine, instanceId: 8, cmd:
> org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, cmdInfo:
> {"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface
> com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 220777304233416, completeMsid: null,
> lastUpdated: null, lastPolled: null, created: null}
> 2018-12-13 08:44:06,700 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:6e9a71c5) Executing
> AsyncJobVO {id:1343, userId: 2, accountId: 2, instanceType:
> VirtualMachine, instanceId: 8, cmd:
> org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, cmdInfo:
> {"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface
> com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 220777304233416, completeMsid: null,
> lastUpdated: null, lastPolled: null, created: null}
> 2018-12-13 08:44:06,705 DEBUG [c.c.a.ApiServlet]
> (qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7)
> ===END===  10.80.0.6 -- GET
> command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
> 
> 2018-12-13 08:44:06,745 DEBUG [c.c.n.NetworkModelImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
> Service SecurityGroup is not supported in the network id=205
> 2018-12-13 08:44:06,752 DEBUG [c.c.n.NetworkModelImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
> Service SecurityGroup is not supported in the network id=205
> 2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
> DeploymentPlanner allocation algorithm: null
> 2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
> Trying to allocate a host and storage pools from dc:1,
> pod:null,cluster:null, requested cpu: 8000, requested ram: 8594128896
> 2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
> Is ROOT volume READY (pool already allocated)?: Yes
> 2018-12-13 08:44:06,783 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
> Deploy avoids pods: [], clusters: [], hosts: []
> 2018-12-13 08:44:06,784 DEBUG [c.c.d.DeploymentPlanningManagerImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
> This VM has last host_id specified, trying to choose the same host: 10
> 2018-12-13 08:44:06,794 DEBUG [c.c.c.CapacityManagerImpl]
> (API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5)
> Host: 10 has cpu capability (cpu:12, speed:3000) to support 

Re: new committer: Boris Stoyanov (AKA Bobby)

[Sateesh Chodapuneedi]

Hearty Congratulations, Bobby!
Well deserved.
Bobby has been actively helping with validation of MRs under review. Also 
helping users in users list.

Regards,
Sateesh
 

-Original Message-
From: Paul Angus 
Reply-To: "d...@cloudstack.apache.org" 
Date: Thursday, 13 December 2018 at 14:59
To: "users@cloudstack.apache.org" , 
"d...@cloudstack.apache.org" 
Cc: Boris Stoyanov 
Subject: new committer: Boris Stoyanov (AKA Bobby)

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack
has invited Boris Stoyanov to become a committer and we are pleased
to announce that he has accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.



paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Re: URGENT: Unable to schedule async job for command com.cloud.vm.VmWorkStart, unexpected exception

[Ugo Vasi]

We have verified that the problem is not tied to a vm but it also 
concerns the other VMs that are stopped. Trying to restart them gives 
the same error message.


Restoring the previous day's database which problems might imply?


Il 13/12/18 09:01, Ugo Vasi ha scritto:

Hi all,
I'm trying to reboot a vm after the host it ran on crashed and 
restarted from the HA system. All the VMs running on the rebooted host 
were restarted on other hosts except one.

In the web interface and using cloudmonkey I get this message:
  "Unable to schedule async job for command com.cloud.vm.VmWorkStart, 
unexpected exception."


In the management-server.log file there would seem to be a problem 
when creating an element that is duplicated (Duplicate entry '' 
for key 'PRIMARY'):


2018-12-13 08:44:06,659 DEBUG [c.c.a.ApiServlet] 
(qtp1096283470-445:ctx-6c065e06) (logid:87edf8d7) ===START=== 
10.80.0.6 -- GET 
command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
2018-12-13 08:44:06,665 DEBUG [c.c.a.ApiServer] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) CIDRs 
from which account 'Acct[26e597f2-b5ca-11e8-a619-c8cbb8cb15cd-admin]' 
is allowed to perform API calls: 0.0.0.0/0,::/0
2018-12-13 08:44:06,693 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:7e0c4dc9) Add 
job-1343 into job monitoring
2018-12-13 08:44:06,698 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) submit 
async job-1343, details: AsyncJobVO {id:1343, userId: 2, accountId: 2, 
instanceType: VirtualMachine, instanceId: 8, cmd: 
org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, cmdInfo: 
{"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface 
com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"}, 
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, 
result: null, initMsid: 220777304233416, completeMsid: null, 
lastUpdated: null, lastPolled: null, created: null}
2018-12-13 08:44:06,700 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:6e9a71c5) Executing 
AsyncJobVO {id:1343, userId: 2, accountId: 2, instanceType: 
VirtualMachine, instanceId: 8, cmd: 
org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, cmdInfo: 
{"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface 
com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"}, 
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, 
result: null, initMsid: 220777304233416, completeMsid: null, 
lastUpdated: null, lastPolled: null, created: null}
2018-12-13 08:44:06,705 DEBUG [c.c.a.ApiServlet] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) 
===END===  10.80.0.6 -- GET 
command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
2018-12-13 08:44:06,745 DEBUG [c.c.n.NetworkModelImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Service SecurityGroup is not supported in the network 
id=205
2018-12-13 08:44:06,752 DEBUG [c.c.n.NetworkModelImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Service SecurityGroup is not supported in the network 
id=205
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) DeploymentPlanner allocation algorithm: null
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Trying to allocate a host and storage pools from 
dc:1, pod:null,cluster:null, requested cpu: 8000, requested ram: 
8594128896
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Is ROOT volume READY (pool already allocated)?: Yes
2018-12-13 08:44:06,783 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Deploy avoids pods: [], clusters: [], hosts: []
2018-12-13 08:44:06,784 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) This VM has last host_id specified, trying to choose 
the same host: 10
2018-12-13 08:44:06,794 DEBUG [c.c.c.CapacityManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) 
(logid:6e9a71c5) Host: 10 has cpu capability (cpu:12, speed:3000) to 
support requested CPU: 4 and requested speed: 2000
2018-12-13 

Re: new committer: Boris Stoyanov (AKA Bobby)

[Jochim, Ingo]

Great to hear. :-)


> Am 13.12.2018 um 10:29 schrieb Paul Angus :
> 
> Hi Everyone,
> 
> The Project Management Committee (PMC) for Apache CloudStack
> has invited Boris Stoyanov to become a committer and we are pleased
> to announce that he has accepted.
> 
> Please join me in congratulating Bobby!
> 
> 
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> Being a PMC member enables assistance with the management
> and to guide the direction of the project.
> 
> 
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
> 
> 
> 

new committer: Boris Stoyanov (AKA Bobby)

[Paul Angus]

Hi Everyone,

The Project Management Committee (PMC) for Apache CloudStack
has invited Boris Stoyanov to become a committer and we are pleased
to announce that he has accepted.

Please join me in congratulating Bobby!


Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.



paul.an...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

URGENT: Unable to schedule async job for command com.cloud.vm.VmWorkStart, unexpected exception

[Ugo Vasi]

Hi all,
I'm trying to reboot a vm after the host it ran on crashed and restarted 
from the HA system. All the VMs running on the rebooted host were 
restarted on other hosts except one.

In the web interface and using cloudmonkey I get this message:
  "Unable to schedule async job for command com.cloud.vm.VmWorkStart, 
unexpected exception."


In the management-server.log file there would seem to be a problem when 
creating an element that is duplicated (Duplicate entry '' for key 
'PRIMARY'):


2018-12-13 08:44:06,659 DEBUG [c.c.a.ApiServlet] 
(qtp1096283470-445:ctx-6c065e06) (logid:87edf8d7) ===START=== 10.80.0.6 
-- GET 
command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
2018-12-13 08:44:06,665 DEBUG [c.c.a.ApiServer] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) CIDRs 
from which account 'Acct[26e597f2-b5ca-11e8-a619-c8cbb8cb15cd-admin]' is 
allowed to perform API calls: 0.0.0.0/0,::/0
2018-12-13 08:44:06,693 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:7e0c4dc9) Add job-1343 
into job monitoring
2018-12-13 08:44:06,698 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) submit 
async job-1343, details: AsyncJobVO {id:1343, userId: 2, accountId: 2, 
instanceType: VirtualMachine, instanceId: 8, cmd: 
org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, cmdInfo: 
{"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface 
com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"}, 
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, 
result: null, initMsid: 220777304233416, completeMsid: null, 
lastUpdated: null, lastPolled: null, created: null}
2018-12-13 08:44:06,700 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343) (logid:6e9a71c5) Executing 
AsyncJobVO {id:1343, userId: 2, accountId: 2, instanceType: 
VirtualMachine, instanceId: 8, cmd: 
org.apache.cloudstack.api.command.admin.vm.StartVMCmdByAdmin, cmdInfo: 
{"response":"json","ctxUserId":"2","httpmethod":"GET","ctxStartEventId":"6170","id":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","ctxDetails":"{\"interface 
com.cloud.vm.VirtualMachine\":\"dde566b2-ef2c-4f86-a82b-c8286f0c24f7\"}","ctxAccountId":"2","uuid":"dde566b2-ef2c-4f86-a82b-c8286f0c24f7","cmdEventType":"VM.START","_":"1544687047015"}, 
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, 
result: null, initMsid: 220777304233416, completeMsid: null, 
lastUpdated: null, lastPolled: null, created: null}
2018-12-13 08:44:06,705 DEBUG [c.c.a.ApiServlet] 
(qtp1096283470-445:ctx-6c065e06 ctx-c8b27e4a) (logid:87edf8d7) 
===END===  10.80.0.6 -- GET 
command=startVirtualMachine=json=dde566b2-ef2c-4f86-a82b-c8286f0c24f7&_=1544687047015
2018-12-13 08:44:06,745 DEBUG [c.c.n.NetworkModelImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
Service SecurityGroup is not supported in the network id=205
2018-12-13 08:44:06,752 DEBUG [c.c.n.NetworkModelImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
Service SecurityGroup is not supported in the network id=205
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
DeploymentPlanner allocation algorithm: null
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
Trying to allocate a host and storage pools from dc:1, 
pod:null,cluster:null, requested cpu: 8000, requested ram: 8594128896
2018-12-13 08:44:06,774 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
Is ROOT volume READY (pool already allocated)?: Yes
2018-12-13 08:44:06,783 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
Deploy avoids pods: [], clusters: [], hosts: []
2018-12-13 08:44:06,784 DEBUG [c.c.d.DeploymentPlanningManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
This VM has last host_id specified, trying to choose the same host: 10
2018-12-13 08:44:06,794 DEBUG [c.c.c.CapacityManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
Host: 10 has cpu capability (cpu:12, speed:3000) to support requested 
CPU: 4 and requested speed: 2000
2018-12-13 08:44:06,794 DEBUG [c.c.c.CapacityManagerImpl] 
(API-Job-Executor-8:ctx-b5905c86 job-1343 ctx-eb44a3e5) (logid:6e9a71c5) 
Checking if host: 10 has enough capacity for requested CPU: 8000 and 
requested RAM: 8594128896 , cpuOverprovisioningFactor: 1.0
2018-12-13 08:44:06,797 DEBUG