DNS service on VR not responding

[Indra Pramana]

Dear all,

All our guest VMs are having our virtual router (VR)'s IP address on
/etc/resolv.conf. In the past two weeks, I just realised that the DNS
service on the VR is not working, and doesn't respond to DNS queries from
the DNS clients on the guest VM.

I have tried to stop and start back the VR, but the problem persists.

DHCP services seems to be running fine, only DNS services are not working.
>From what I understand, both services are provided by dnsmasq, correct?

Any advice on how can I resolve the problem?

Looking forward to your reply, thank you.

Cheers.

Re: DNS service on VR not responding

[Rafael Weingartner]

Have you taken a look at dnsmasq.log in the VR ?
What do you mean with not responding? The addresses are not being resolved
to ip addresses?


On Sun, Jul 20, 2014 at 11:53 AM, Indra Pramana  wrote:

> Dear all,
>
> All our guest VMs are having our virtual router (VR)'s IP address on
> /etc/resolv.conf. In the past two weeks, I just realised that the DNS
> service on the VR is not working, and doesn't respond to DNS queries from
> the DNS clients on the guest VM.
>
> I have tried to stop and start back the VR, but the problem persists.
>
> DHCP services seems to be running fine, only DNS services are not working.
> From what I understand, both services are provided by dnsmasq, correct?
>
> Any advice on how can I resolve the problem?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>



-- 
Rafael Weingärtner

Re: [DISCUSS] [PROPOSAL] SAML2 plugin for SSO/SLO in CloudStack

[Rohit Yadav]

Hi,

I'm assuming no one objects the proposal and the spec, I'll move forward
with the first implementation starting next week but will be mostly
offline till 28th July.

Regards.

Rohit Yadav wrote:

Hi guys,

There has been a lot of interest [4] around auth related problems in
CloudStach such as -- SSO/SLO (single sign on / log out), 2-factor
authentication, role based network/IP/CIDR checking etc.

A lot of challenge in implementing them in CloudStack is because of two
divergent authentication mechanisms (one that is
username/password/cookie based, other which is api/secret keys or
hmac/signature based).

This thread tries to kickstart a project in that direction which will in
short term try to implement a SAML2 plugin and in long term have a much
better authentication framework.

Let me start by briefly explaining what SAML2 [1] is -- it's an XML
based authentication and authorization protocol widely used to implement
single sign on service. Having a SAML plugin in ACS will give users and
organization a new mode of authentication who already have such an
infrastructure in place.

A SAML based SSO infrastructure consists of three entities - user-agent
(UA), service provider (SP) and identity provider (IdP). The UA is the
user/browser, the SP is the application that the UA is accessing (i.e.
Apache CloudStack UI) and the IdP is the identity service and does
authentication and authorization, management of users among other
things. IdP could be backed by LDAP, AD etc. For the scope of this
feature, we only need to implement SAML SP plugin in CloudStack and use
any free SAML 2.0 compliant IdP server [5] for testing.

For this I researched and explored ways of implementing that and have a
first draft which needs to be discussed and iterated in the ACS dev
community.

After comparing many opensource SAML 2.0 implementations, their
security and stability, we'll use OpenSAML [2] which is the most stable
and widely used Java implementation. Since within CloudStack, we've been
using Spring (for DI etc.) I explored and found Spring security SAML
extension [3] which fits perfectly and it too uses OpenSAML.

I also have a working proof-of-concept general implementation using the
above based on which I've put together a design document draft on this
feature for your review:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin

There are some complex stories/cases around security and user management
in CloudStack, some of which are listed under 'open ended questions' in
the draft above most of which I'm not sure how to address.

After first round of discussion, I'll go ahead with a basic
implementation of this feature. The second phase will address broader
use cases.

Comments, questions, suggestions?

References:

[1] http://en.wikipedia.org/wiki/SAML_2.0
[2] https://wiki.shibboleth.net/confluence/display/OpenSAML/Home
[3] http://projects.spring.io/spring-security-saml
[4] John Burwell's talk on SSO in CloudStack:
https://www.youtube.com/watch?v=kCR0TzrfCOM
[5] https://idp.ssocircle.com/sso/UI/Login

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab


Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design &
Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure
Support
CloudStack Bootcamp Training
Courses

This email and any attachments to it may be confidential and are
intended solely for the use of the individual to whom it is addressed.
Any views or opinions expressed are solely those of the author and do
not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither
take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in
error. Shape Blue Ltd is a company incorporated in England & Wales.
ShapeBlue Services India LLP is a company incorporated in India and is
operated under license from Shape Blue Ltd. Shape Blue Brasil
Consultoria Ltda is a company incorporated in Brasil and is operated
under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
registered by The Republic of South Africa and is traded under license
from Shape Blue Ltd. ShapeBlue is a registered trademark.


--
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab


Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
Cl

Re: DNS service on VR not responding

[Indra Pramana]

Hi Rafael,

Good day to you, and thank you for your reply.

Can't find anything wrong on dnsmasq.log / daemon.log, just some log
entries related to DHCP, nothing on DNS. I masked the IP addresses since
they are public.

===
Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPDISCOVER(eth0) X.X.X.X
06:62:a8:01:13:37
Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPOFFER(eth0) X.X.X.X
06:62:a8:01:13:37
Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPREQUEST(eth0) X.X.X.X
06:62:a8:01:13:37
Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
06:62:a8:01:13:37 yy
Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPINFORM(eth0) X.X.X.X
06:43:4a:01:12:65
Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
06:43:4a:01:12:65 zz
===

Yes, the guest VMs are having difficulties resolving domains into IP
addresses because of the problem on the VR's DNS server.

$ host www.google.com X.X.X.X (where X.X.X.X is the IP address of the VR)
;; connection timed out; no servers could be reached

However, from within the VR, I am able to resolve domains just fine.

Any advise where can I start troubleshooting this?

Looking forward to your reply, thank you.

Cheers.



On Sun, Jul 20, 2014 at 11:26 PM, Rafael Weingartner <
rafaelweingart...@gmail.com> wrote:

> Have you taken a look at dnsmasq.log in the VR ?
> What do you mean with not responding? The addresses are not being resolved
> to ip addresses?
>
>
> On Sun, Jul 20, 2014 at 11:53 AM, Indra Pramana  wrote:
>
> > Dear all,
> >
> > All our guest VMs are having our virtual router (VR)'s IP address on
> > /etc/resolv.conf. In the past two weeks, I just realised that the DNS
> > service on the VR is not working, and doesn't respond to DNS queries from
> > the DNS clients on the guest VM.
> >
> > I have tried to stop and start back the VR, but the problem persists.
> >
> > DHCP services seems to be running fine, only DNS services are not
> working.
> > From what I understand, both services are provided by dnsmasq, correct?
> >
> > Any advice on how can I resolve the problem?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
>
>
>
> --
> Rafael Weingärtner
>

Re: DNS service on VR not responding

[Rafael Weingartner]

Good day to you too,
Sure I guess I point a way, so you can start troubleshooting.


   1. Check if the VMs can reach the VR.
   2. Check if the VMs are really configured to use VR as the DNS server.
   3. Change the DNS server to be any other such as 8.8.8.8 and 8.8.4.4
   (just to see if there is nothing blocking the way), the name resolution
   should work with those servers.
   4. Enable the dnsmasq debug, and try to see if something interesting
   appears in dnsmasq.log.




On Sun, Jul 20, 2014 at 2:06 PM, Indra Pramana  wrote:

> Hi Rafael,
>
> Good day to you, and thank you for your reply.
>
> Can't find anything wrong on dnsmasq.log / daemon.log, just some log
> entries related to DHCP, nothing on DNS. I masked the IP addresses since
> they are public.
>
> ===
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPDISCOVER(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPOFFER(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPREQUEST(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> 06:62:a8:01:13:37 yy
> Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPINFORM(eth0) X.X.X.X
> 06:43:4a:01:12:65
> Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> 06:43:4a:01:12:65 zz
> ===
>
> Yes, the guest VMs are having difficulties resolving domains into IP
> addresses because of the problem on the VR's DNS server.
>
> $ host www.google.com X.X.X.X (where X.X.X.X is the IP address of the VR)
> ;; connection timed out; no servers could be reached
>
> However, from within the VR, I am able to resolve domains just fine.
>
> Any advise where can I start troubleshooting this?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
> On Sun, Jul 20, 2014 at 11:26 PM, Rafael Weingartner <
> rafaelweingart...@gmail.com> wrote:
>
> > Have you taken a look at dnsmasq.log in the VR ?
> > What do you mean with not responding? The addresses are not being
> resolved
> > to ip addresses?
> >
> >
> > On Sun, Jul 20, 2014 at 11:53 AM, Indra Pramana  wrote:
> >
> > > Dear all,
> > >
> > > All our guest VMs are having our virtual router (VR)'s IP address on
> > > /etc/resolv.conf. In the past two weeks, I just realised that the DNS
> > > service on the VR is not working, and doesn't respond to DNS queries
> from
> > > the DNS clients on the guest VM.
> > >
> > > I have tried to stop and start back the VR, but the problem persists.
> > >
> > > DHCP services seems to be running fine, only DNS services are not
> > working.
> > > From what I understand, both services are provided by dnsmasq, correct?
> > >
> > > Any advice on how can I resolve the problem?
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Rafael Weingärtner

RE: DNS service on VR not responding

[Santhosh Edukulla]

Run trace route from guest vms, the result will yield to the point where packet 
drop is happening, could be a network acl rule issue, but tracert command can 
lead to some answers.

List running ports as well on VR, do a telnet to dns port on router from guest 
vm to verify for its response.

Santhosh

From: Indra Pramana [in...@sg.or.id]
Sent: Sunday, July 20, 2014 1:06 PM
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: DNS service on VR not responding

Hi Rafael,

Good day to you, and thank you for your reply.

Can't find anything wrong on dnsmasq.log / daemon.log, just some log
entries related to DHCP, nothing on DNS. I masked the IP addresses since
they are public.

===
Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPDISCOVER(eth0) X.X.X.X
06:62:a8:01:13:37
Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPOFFER(eth0) X.X.X.X
06:62:a8:01:13:37
Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPREQUEST(eth0) X.X.X.X
06:62:a8:01:13:37
Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
06:62:a8:01:13:37 yy
Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPINFORM(eth0) X.X.X.X
06:43:4a:01:12:65
Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
06:43:4a:01:12:65 zz
===

Yes, the guest VMs are having difficulties resolving domains into IP
addresses because of the problem on the VR's DNS server.

$ host www.google.com X.X.X.X (where X.X.X.X is the IP address of the VR)
;; connection timed out; no servers could be reached

However, from within the VR, I am able to resolve domains just fine.

Any advise where can I start troubleshooting this?

Looking forward to your reply, thank you.

Cheers.



On Sun, Jul 20, 2014 at 11:26 PM, Rafael Weingartner <
rafaelweingart...@gmail.com> wrote:

> Have you taken a look at dnsmasq.log in the VR ?
> What do you mean with not responding? The addresses are not being resolved
> to ip addresses?
>
>
> On Sun, Jul 20, 2014 at 11:53 AM, Indra Pramana  wrote:
>
> > Dear all,
> >
> > All our guest VMs are having our virtual router (VR)'s IP address on
> > /etc/resolv.conf. In the past two weeks, I just realised that the DNS
> > service on the VR is not working, and doesn't respond to DNS queries from
> > the DNS clients on the guest VM.
> >
> > I have tried to stop and start back the VR, but the problem persists.
> >
> > DHCP services seems to be running fine, only DNS services are not
> working.
> > From what I understand, both services are provided by dnsmasq, correct?
> >
> > Any advice on how can I resolve the problem?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
>
>
>
> --
> Rafael Weingärtner
>

Re: DNS service on VR not responding

[Indra Pramana]

Hi Rafael,

Good day to you, and thank you for your reply.

1. Yes, the guest VMs can reach the VR. Able to ping.

64 bytes from X.X.X.2: icmp_req=4 ttl=64 time=2.00 ms
64 bytes from X.X.X.2: icmp_req=5 ttl=64 time=0.291 ms
64 bytes from X.X.X.2: icmp_req=6 ttl=64 time=0.384 ms
^C
--- X.X.X.2 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4999ms
rtt min/avg/max/mdev = 0.270/0.603/2.006/0.628 ms

2. Yes, the VMs are really configured to use VR as the DNS server,
according to /etc/resolv.conf, together with 8.8.8.8 and 8.8.4.4

/etc/resolv.conf on guest VMs:

===
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver X.X.X.2 (the VR's IP)
nameserver 8.8.8.8
nameserver 8.8.4.4
search cs1cloud.internal
===

3. Yes, if I remove or comment out the first nameserver entry for the VR's
IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be running fine
and will be able to resolve domains properly.

4. May I know how to enable the dnsmasq debug? Any documentation / steps on
how to do it? I believe I have to do it on the VR itself?

Looking forward to your reply, thank you.

Cheers.




On Mon, Jul 21, 2014 at 1:17 AM, Rafael Weingartner <
rafaelweingart...@gmail.com> wrote:

> Good day to you too,
> Sure I guess I point a way, so you can start troubleshooting.
>
>
>1. Check if the VMs can reach the VR.
>2. Check if the VMs are really configured to use VR as the DNS server.
>3. Change the DNS server to be any other such as 8.8.8.8 and 8.8.4.4
>(just to see if there is nothing blocking the way), the name resolution
>should work with those servers.
>4. Enable the dnsmasq debug, and try to see if something interesting
>appears in dnsmasq.log.
>
>
>
>
> On Sun, Jul 20, 2014 at 2:06 PM, Indra Pramana  wrote:
>
> > Hi Rafael,
> >
> > Good day to you, and thank you for your reply.
> >
> > Can't find anything wrong on dnsmasq.log / daemon.log, just some log
> > entries related to DHCP, nothing on DNS. I masked the IP addresses since
> > they are public.
> >
> > ===
> > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPDISCOVER(eth0) X.X.X.X
> > 06:62:a8:01:13:37
> > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPOFFER(eth0) X.X.X.X
> > 06:62:a8:01:13:37
> > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPREQUEST(eth0) X.X.X.X
> > 06:62:a8:01:13:37
> > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> > 06:62:a8:01:13:37 yy
> > Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPINFORM(eth0) X.X.X.X
> > 06:43:4a:01:12:65
> > Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> > 06:43:4a:01:12:65 zz
> > ===
> >
> > Yes, the guest VMs are having difficulties resolving domains into IP
> > addresses because of the problem on the VR's DNS server.
> >
> > $ host www.google.com X.X.X.X (where X.X.X.X is the IP address of the
> VR)
> > ;; connection timed out; no servers could be reached
> >
> > However, from within the VR, I am able to resolve domains just fine.
> >
> > Any advise where can I start troubleshooting this?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> >
> > On Sun, Jul 20, 2014 at 11:26 PM, Rafael Weingartner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > Have you taken a look at dnsmasq.log in the VR ?
> > > What do you mean with not responding? The addresses are not being
> > resolved
> > > to ip addresses?
> > >
> > >
> > > On Sun, Jul 20, 2014 at 11:53 AM, Indra Pramana 
> wrote:
> > >
> > > > Dear all,
> > > >
> > > > All our guest VMs are having our virtual router (VR)'s IP address on
> > > > /etc/resolv.conf. In the past two weeks, I just realised that the DNS
> > > > service on the VR is not working, and doesn't respond to DNS queries
> > from
> > > > the DNS clients on the guest VM.
> > > >
> > > > I have tried to stop and start back the VR, but the problem persists.
> > > >
> > > > DHCP services seems to be running fine, only DNS services are not
> > > working.
> > > > From what I understand, both services are provided by dnsmasq,
> correct?
> > > >
> > > > Any advice on how can I resolve the problem?
> > > >
> > > > Looking forward to your reply, thank you.
> > > >
> > > > Cheers.
> > > >
> > >
> > >
> > >
> > > --
> > > Rafael Weingärtner
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>

Re: What to modify to increase instance password length?

[Ian Duffy]

Hi Harikrishna,

Pulled over the related commits. Had some merge conflicts.


On 19 July 2014 21:14, Ian Duffy  wrote:

> Hi sorry about the slow response. Will get on this tomorrow away from a
> computer for the weekend.
> On 18 Jul 2014 13:36, "Harikrishna Patnala" <
> harikrishna.patn...@citrix.com> wrote:
>
>> Hi Ian,
>>
>> The commit was made only in 4.4 and not in master.
>> Can you cherry pick the same to master.
>>
>> Thanks,
>> Harikrishna
>> On 26-Jun-2014, at 12:23 am, Ian Duffy  wrote:
>>
>> > Just pushed a change for this to the 4.4-forward branch.
>> >
>> > Daan, will you review / cherrypick?
>> 96412e3e58fd1ced9d269e4552aaa6410bedf556
>> >
>> > Testing done:
>> >
>> > Brought up simulator.
>> >
>> > Changed password flag for the builtin template.
>> >
>> > Brought up VM, password was displayed at length of 6. Stopped the VM,
>> reset
>> > the password, new password was displayed at length of 6.
>> >
>> > Went into global settings, modified the value for vm.password.length to
>> 20.
>> > Restarted the management server.
>> > Created a new VM, password was displayed at length of 20. Stopped the
>> VM,
>> > reset the password, new password was displayed at length of 20.
>> >
>> > Thanks,
>> >
>> > Ian
>> >
>> > On 25 June 2014 18:50, Nux!  wrote:
>> >
>> >> Volunteer to do it in time for 4.4?
>> >>
>> >> Lucian
>> >>
>> >> --
>> >> Sent from the Delta quadrant using Borg technology!
>> >>
>> >> Nux!
>> >> www.nux.ro
>> >>
>> >>
>> >> - Original Message -
>> >> From: "ilya musayev" 
>> >> To: dev@cloudstack.apache.org
>> >> Sent: Wednesday, 25 June, 2014 6:30:25 PM
>> >> Subject: Re: What to modify to increase instance password length?
>> >>
>> >> You should ask if this can be done as global setting variable - not
>> hard
>> >> coded.
>> >>
>> >> This should be an easy one.
>> >>
>> >> On 6/25/14, 10:14 AM, Nux! wrote:
>> >>> I should submit a bug report to rewrite ACS in a scripting language.
>> >>>
>> >>> Cheers :)
>> >>>
>> >>> --
>> >>> Sent from the Delta quadrant using Borg technology!
>> >>>
>> >>> Nux!
>> >>> www.nux.ro
>> >>>
>> >>>
>> >>> - Original Message -
>> >>> From: "Ian Duffy" 
>> >>> To: "CloudStack Dev" 
>> >>> Sent: Wednesday, 25 June, 2014 6:11:23 PM
>> >>> Subject: Re: What to modify to increase instance password length?
>> >>>
>> >>> Afaik yes. (Will to be corrected on this but it appears to be hard
>> coded)
>> >>>
>> >>>
>> >>> On 25 June 2014 18:06, Nux!  wrote:
>> >>>
>>  Thanks, Ian,
>> 
>>  This means I need to modify the source, rebuild the RPMs and update,
>>  right? (ie it's not something that I can just modify on the mgmt
>> server
>>  right now).
>> 
>>  Lucian
>> 
>>  --
>>  Sent from the Delta quadrant using Borg technology!
>> 
>>  Nux!
>>  www.nux.ro
>> 
>> 
>>  - Original Message -
>>  From: "Ian Duffy" 
>>  To: "CloudStack Dev" 
>>  Sent: Wednesday, 25 June, 2014 6:02:12 PM
>>  Subject: Re: What to modify to increase instance password length?
>> 
>>  Hi Lucian,
>> 
>>  Take a look at server/src/com/cloud/server/ManagementServerImpl.java
>> 
>>  Line 895 - 898
>> 
>>  @Override
>>  public String generateRandomPassword() {
>>  return PasswordGenerator.generateRandomPassword(6);
>>  }
>> 
>> 
>> 
>> 
>>  On 25 June 2014 17:16, Nux!  wrote:
>> 
>> > Hi guys,
>> >
>> > Can anyone tell me which changes I should make in order to increase
>> > password length for instances?
>> > Currently I get something like "tK2yptbby" which might have been
>> secure
>>  10
>> > years ago, but now it's way too short.
>> >
>> > Thanks!
>> > Lucian
>> >
>> > --
>> > Sent from the Delta quadrant using Borg technology!
>> >
>> > Nux!
>> > www.nux.ro
>> >
>> >
>> >>
>> >>
>>
>>

Re: DNS service on VR not responding

[Indra Pramana]

Hi Santhosh,

Good day to you, and thank you for your email.

Traceroute packets seems to be dropped, I think it's by default. See result
below:

# traceroute X.X.X.2
traceroute to X.X.X.2 (X.X.X.2), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *

However, I am able to ping, and there is a response when I tried to telnet
to port 53.

64 bytes from X.X.X.2: icmp_req=4 ttl=64 time=2.00 ms
64 bytes from X.X.X.2: icmp_req=5 ttl=64 time=0.291 ms
64 bytes from X.X.X.2: icmp_req=6 ttl=64 time=0.384 ms
^C
--- X.X.X.2 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4999ms
rtt min/avg/max/mdev = 0.270/0.603/2.006/0.628 ms

# telnet X.X.X.2 53
Trying X.X.X.2...
Connected to X.X.X.2.
Escape character is '^]'.

netstat -a on the VR shows the service is listening on domain port (53).

tcp0  0 r-2606-VM:domain*:* LISTEN

tcp0  0 X.X.X.2:domain *:* LISTEN

udp   156992  0 r-2606-VM:domain*:*

udp   164032  0 X.X.X.2:domain *:*

Can you advise if there's anything else I need to check?

Looking forward to your reply, thank you.

Cheers.




On Mon, Jul 21, 2014 at 1:17 AM, Santhosh Edukulla <
santhosh.eduku...@citrix.com> wrote:

> Run trace route from guest vms, the result will yield to the point where
> packet drop is happening, could be a network acl rule issue, but tracert
> command can lead to some answers.
>
> List running ports as well on VR, do a telnet to dns port on router from
> guest vm to verify for its response.
>
> Santhosh
> 
> From: Indra Pramana [in...@sg.or.id]
> Sent: Sunday, July 20, 2014 1:06 PM
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: DNS service on VR not responding
>
> Hi Rafael,
>
> Good day to you, and thank you for your reply.
>
> Can't find anything wrong on dnsmasq.log / daemon.log, just some log
> entries related to DHCP, nothing on DNS. I masked the IP addresses since
> they are public.
>
> ===
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPDISCOVER(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPOFFER(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPREQUEST(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> 06:62:a8:01:13:37 yy
> Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPINFORM(eth0) X.X.X.X
> 06:43:4a:01:12:65
> Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> 06:43:4a:01:12:65 zz
> ===
>
> Yes, the guest VMs are having difficulties resolving domains into IP
> addresses because of the problem on the VR's DNS server.
>
> $ host www.google.com X.X.X.X (where X.X.X.X is the IP address of the VR)
> ;; connection timed out; no servers could be reached
>
> However, from within the VR, I am able to resolve domains just fine.
>
> Any advise where can I start troubleshooting this?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
> On Sun, Jul 20, 2014 at 11:26 PM, Rafael Weingartner <
> rafaelweingart...@gmail.com> wrote:
>
> > Have you taken a look at dnsmasq.log in the VR ?
> > What do you mean with not responding? The addresses are not being
> resolved
> > to ip addresses?
> >
> >
> > On Sun, Jul 20, 2014 at 11:53 AM, Indra Pramana  wrote:
> >
> > > Dear all,
> > >
> > > All our guest VMs are having our virtual router (VR)'s IP address on
> > > /etc/resolv.conf. In the past two weeks, I just realised that the DNS
> > > service on the VR is not working, and doesn't respond to DNS queries
> from
> > > the DNS clients on the guest VM.
> > >
> > > I have tried to stop and start back the VR, but the problem persists.
> > >
> > > DHCP services seems to be running fine, only DNS services are not
> > working.
> > > From what I understand, both services are provided by dnsmasq, correct?
> > >
> > > Any advice on how can I resolve the problem?
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>

RE: DNS service on VR not responding

[Santhosh Edukulla]

Do a traceroute to an external domain say google.com from guest vm, as you 
mentioned below, both by commenting out vr ip and not, in resolv.conf, you may 
see the difference.

"Yes, if I remove or comment out the first nameserver entry for the VR's
IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be running fine
and will be able to resolve domains properly."


Santhosh

From: Indra Pramana [in...@sg.or.id]
Sent: Sunday, July 20, 2014 1:48 PM
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: DNS service on VR not responding

Hi Santhosh,

Good day to you, and thank you for your email.

Traceroute packets seems to be dropped, I think it's by default. See result
below:

# traceroute X.X.X.2
traceroute to X.X.X.2 (X.X.X.2), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *

However, I am able to ping, and there is a response when I tried to telnet
to port 53.

64 bytes from X.X.X.2: icmp_req=4 ttl=64 time=2.00 ms
64 bytes from X.X.X.2: icmp_req=5 ttl=64 time=0.291 ms
64 bytes from X.X.X.2: icmp_req=6 ttl=64 time=0.384 ms
^C
--- X.X.X.2 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4999ms
rtt min/avg/max/mdev = 0.270/0.603/2.006/0.628 ms

# telnet X.X.X.2 53
Trying X.X.X.2...
Connected to X.X.X.2.
Escape character is '^]'.

netstat -a on the VR shows the service is listening on domain port (53).

tcp0  0 r-2606-VM:domain*:* LISTEN

tcp0  0 X.X.X.2:domain *:* LISTEN

udp   156992  0 r-2606-VM:domain*:*

udp   164032  0 X.X.X.2:domain *:*

Can you advise if there's anything else I need to check?

Looking forward to your reply, thank you.

Cheers.




On Mon, Jul 21, 2014 at 1:17 AM, Santhosh Edukulla <
santhosh.eduku...@citrix.com> wrote:

> Run trace route from guest vms, the result will yield to the point where
> packet drop is happening, could be a network acl rule issue, but tracert
> command can lead to some answers.
>
> List running ports as well on VR, do a telnet to dns port on router from
> guest vm to verify for its response.
>
> Santhosh
> 
> From: Indra Pramana [in...@sg.or.id]
> Sent: Sunday, July 20, 2014 1:06 PM
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: DNS service on VR not responding
>
> Hi Rafael,
>
> Good day to you, and thank you for your reply.
>
> Can't find anything wrong on dnsmasq.log / daemon.log, just some log
> entries related to DHCP, nothing on DNS. I masked the IP addresses since
> they are public.
>
> ===
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPDISCOVER(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPOFFER(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPREQUEST(eth0) X.X.X.X
> 06:62:a8:01:13:37
> Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> 06:62:a8:01:13:37 yy
> Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPINFORM(eth0) X.X.X.X
> 06:43:4a:01:12:65
> Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> 06:43:4a:01:12:65 zz
> ===
>
> Yes, the guest VMs are having difficulties resolving domains into IP
> addresses because of the problem on the VR's DNS server.
>
> $ host www.google.com X.X.X.X (where X.X.X.X is the IP address of the VR)
> ;; connection timed out; no servers could be reached
>
> However, from within the VR, I am able to resolve domains just fine.
>
> Any advise where can I start troubleshooting this?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
> On Sun, Jul 20, 2014 at 11:26 PM, Rafael Weingartner <
> rafaelweingart...@gmail.com> wrote:
>
> > Have you taken a look at dnsmasq.log in the VR ?
> > What do you mean with not responding? The addresses are not being
> resolved
> > to ip addresses?
> >
> >
> > On Sun, Jul 20, 2014 at 11:53 AM, Indra Pramana  wrote:
> >
> > > Dear all,
> > >
> > > All our guest VMs are having our virtual router (VR)'s IP address on
> > > /etc/resolv.conf. In the past two weeks, I just realised that the DNS
> > > service on the VR is not working, and doesn't respond to DNS queries
> from
> > > the DNS clients on the guest VM.
> > >
> > > I have tried to stop and start back the VR, but the problem persists.
> > >
> > > DHCP services seems to be running fine, only DNS services are not
> > working.
> > > From what I understand, both services are provided by dnsmasq, correct?
> > >
> > > Any advice on how can I resolve the problem?
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>

Re: What to modify to increase instance password length?

[Harikrishna Patnala]

Thanks Ian.

On 20-Jul-2014, at 11:07 pm, Ian Duffy 
mailto:i...@ianduffy.ie>> wrote:

Hi Harikrishna,

Pulled over the related commits. Had some merge conflicts.


On 19 July 2014 21:14, Ian Duffy mailto:i...@ianduffy.ie>> 
wrote:

Hi sorry about the slow response. Will get on this tomorrow away from a 
computer for the weekend.

On 18 Jul 2014 13:36, "Harikrishna Patnala" 
mailto:harikrishna.patn...@citrix.com>> wrote:
Hi Ian,

The commit was made only in 4.4 and not in master.
Can you cherry pick the same to master.

Thanks,
Harikrishna
On 26-Jun-2014, at 12:23 am, Ian Duffy 
mailto:i...@ianduffy.ie>> wrote:

> Just pushed a change for this to the 4.4-forward branch.
>
> Daan, will you review / cherrypick? 96412e3e58fd1ced9d269e4552aaa6410bedf556
>
> Testing done:
>
> Brought up simulator.
>
> Changed password flag for the builtin template.
>
> Brought up VM, password was displayed at length of 6. Stopped the VM, reset
> the password, new password was displayed at length of 6.
>
> Went into global settings, modified the value for vm.password.length to 20.
> Restarted the management server.
> Created a new VM, password was displayed at length of 20. Stopped the VM,
> reset the password, new password was displayed at length of 20.
>
> Thanks,
>
> Ian
>
> On 25 June 2014 18:50, Nux! mailto:n...@li.nux.ro>> wrote:
>
>> Volunteer to do it in time for 4.4?
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>>
>> - Original Message -
>> From: "ilya musayev" 
>> mailto:ilya.mailing.li...@gmail.com>>
>> To: dev@cloudstack.apache.org
>> Sent: Wednesday, 25 June, 2014 6:30:25 PM
>> Subject: Re: What to modify to increase instance password length?
>>
>> You should ask if this can be done as global setting variable - not hard
>> coded.
>>
>> This should be an easy one.
>>
>> On 6/25/14, 10:14 AM, Nux! wrote:
>>> I should submit a bug report to rewrite ACS in a scripting language.
>>>
>>> Cheers :)
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>>
>>> - Original Message -
>>> From: "Ian Duffy" mailto:i...@ianduffy.ie>>
>>> To: "CloudStack Dev" 
>>> mailto:dev@cloudstack.apache.org>>
>>> Sent: Wednesday, 25 June, 2014 6:11:23 PM
>>> Subject: Re: What to modify to increase instance password length?
>>>
>>> Afaik yes. (Will to be corrected on this but it appears to be hard coded)
>>>
>>>
>>> On 25 June 2014 18:06, Nux! mailto:n...@li.nux.ro>> wrote:
>>>
 Thanks, Ian,

 This means I need to modify the source, rebuild the RPMs and update,
 right? (ie it's not something that I can just modify on the mgmt server
 right now).

 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro


 - Original Message -
 From: "Ian Duffy" mailto:i...@ianduffy.ie>>
 To: "CloudStack Dev" 
 mailto:dev@cloudstack.apache.org>>
 Sent: Wednesday, 25 June, 2014 6:02:12 PM
 Subject: Re: What to modify to increase instance password length?

 Hi Lucian,

 Take a look at server/src/com/cloud/server/ManagementServerImpl.java

 Line 895 - 898

 @Override
 public String generateRandomPassword() {
 return PasswordGenerator.generateRandomPassword(6);
 }




 On 25 June 2014 17:16, Nux! mailto:n...@li.nux.ro>> wrote:

> Hi guys,
>
> Can anyone tell me which changes I should make in order to increase
> password length for instances?
> Currently I get something like "tK2yptbby" which might have been secure
 10
> years ago, but now it's way too short.
>
> Thanks!
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
>
>>
>>

Re: [DISCUSS] [PROPOSAL] SAML2 plugin for SSO/SLO in CloudStack

[Sebastien Goasguen]

> On 20 Jul 2014, at 17:35, Rohit Yadav  wrote:
> 
> Hi,
> 
> I'm assuming no one objects the proposal and the spec, I'll move forward
> with the first implementation starting next week but will be mostly
> offline till 28th July.
> 

+1 from me , most definitely.

Your email was clear, thanks for putting up the design doc on the wiki. I agree 
with a first step to implement an SP.

-sebastien

> Regards.
> 
> Rohit Yadav wrote:
>> Hi guys,
>> 
>> There has been a lot of interest [4] around auth related problems in
>> CloudStach such as -- SSO/SLO (single sign on / log out), 2-factor
>> authentication, role based network/IP/CIDR checking etc.
>> 
>> A lot of challenge in implementing them in CloudStack is because of two
>> divergent authentication mechanisms (one that is
>> username/password/cookie based, other which is api/secret keys or
>> hmac/signature based).
>> 
>> This thread tries to kickstart a project in that direction which will in
>> short term try to implement a SAML2 plugin and in long term have a much
>> better authentication framework.
>> 
>> Let me start by briefly explaining what SAML2 [1] is -- it's an XML
>> based authentication and authorization protocol widely used to implement
>> single sign on service. Having a SAML plugin in ACS will give users and
>> organization a new mode of authentication who already have such an
>> infrastructure in place.
>> 
>> A SAML based SSO infrastructure consists of three entities - user-agent
>> (UA), service provider (SP) and identity provider (IdP). The UA is the
>> user/browser, the SP is the application that the UA is accessing (i.e.
>> Apache CloudStack UI) and the IdP is the identity service and does
>> authentication and authorization, management of users among other
>> things. IdP could be backed by LDAP, AD etc. For the scope of this
>> feature, we only need to implement SAML SP plugin in CloudStack and use
>> any free SAML 2.0 compliant IdP server [5] for testing.
>> 
>> For this I researched and explored ways of implementing that and have a
>> first draft which needs to be discussed and iterated in the ACS dev
>> community.
>> 
>> After comparing many opensource SAML 2.0 implementations, their
>> security and stability, we'll use OpenSAML [2] which is the most stable
>> and widely used Java implementation. Since within CloudStack, we've been
>> using Spring (for DI etc.) I explored and found Spring security SAML
>> extension [3] which fits perfectly and it too uses OpenSAML.
>> 
>> I also have a working proof-of-concept general implementation using the
>> above based on which I've put together a design document draft on this
>> feature for your review:
>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin
>> 
>> There are some complex stories/cases around security and user management
>> in CloudStack, some of which are listed under 'open ended questions' in
>> the draft above most of which I'm not sure how to address.
>> 
>> After first round of discussion, I'll go ahead with a basic
>> implementation of this feature. The second phase will address broader
>> use cases.
>> 
>> Comments, questions, suggestions?
>> 
>> References:
>> 
>> [1] http://en.wikipedia.org/wiki/SAML_2.0
>> [2] https://wiki.shibboleth.net/confluence/display/OpenSAML/Home
>> [3] http://projects.spring.io/spring-security-saml
>> [4] John Burwell's talk on SSO in CloudStack:
>> https://www.youtube.com/watch?v=kCR0TzrfCOM
>> [5] https://idp.ssocircle.com/sso/UI/Login
>> 
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>> 
>> 
>> Find out more about ShapeBlue and our range of CloudStack related services
>> 
>> IaaS Cloud Design &
>> Build
>> CSForge – rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Infrastructure
>> Support
>> CloudStack Bootcamp Training
>> Courses
>> 
>> This email and any attachments to it may be confidential and are
>> intended solely for the use of the individual to whom it is addressed.
>> Any views or opinions expressed are solely those of the author and do
>> not necessarily represent those of Shape Blue Ltd or related companies.
>> If you are not the intended recipient of this email, you must neither
>> take any action based upon its contents, nor copy or show it to anyone.
>> Please contact the sender if you believe you have received this email in
>> error. Shape Blue Ltd is a company incorporated in England & Wales.
>> ShapeBlue Services India LLP is a company incorporated in India and is
>> operated under license from Shape Blue Ltd. Shape Blue Brasil
>> Consultoria Ltda is a company incorporated in Brasil and is operated
>> under license from Shape Blue Ltd. ShapeBlue

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22799/
---

(Updated July 21, 2014, 3:56 a.m.)


Review request for cloudstack, Mike Tutkowski and Tim Mackey.


Changes
---

add test case


Repository: cloudstack-git


Description
---

As discussed in mailing list, this patch is applied for golden primary storage 
in [1].
I have changed the term from "golden" to "base" because there are some 
functions and variables in CloudStack also use "base" for base image.
This patch only apply for Xen Server.

[1]: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+Storage


Diffs
-

  api/src/com/cloud/deploy/DeployDestination.java 
4ded5ebe7a18252da471ee25019856f2b2f772e0 
  api/src/com/cloud/storage/StoragePool.java 
8e03c3348f3a6dd3156ab9e440126ea317957dc0 
  api/src/com/cloud/template/VirtualMachineTemplate.java 
599212bb039fdbb78511019e8f0a6ea4b4a84440 
  api/src/org/apache/cloudstack/api/ApiConstants.java 
ae5d6f05b6b52f60b151369a641cb11fcbb558af 
  api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 
2350f6b389203e2c6cc2182fe03fe9a95e936b81 
  
api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
 ae44bc9373232d242e4ebdcf76844969f0fe69fc 
  
api/src/org/apache/cloudstack/api/command/admin/storage/ListStoragePoolsCmd.java
 ed123db 
  
api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
 3d1a77353257c814efaf60875ffdf99603bc414e 
  
api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
 f478c9bc8eebf867a03deb4add1bf695ac3ec0ad 
  api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 
3571866fe74dca9aa5fe0d11373313eab97e94ac 
  api/src/org/apache/cloudstack/api/response/TemplateResponse.java 
3e21043e339103c021d3c9e767acac8b3837f760 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java PRE-CREATION 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java PRE-CREATION 
  core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java 
29e53b0d9581f764a17ea285606213d2c045b029 
  core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java 
b201c386f4975913f13c575d7685e50cedc7d92f 
  core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
33361e87265df05e00bfa6dba810d2b68ae8d923 
  core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java 
66feaecb5ef20053db50956e2801fec096a350c9 
  core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
114c8854d1504436523aa99c78bf2b4d84a12077 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
 1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
 dfdbd8ab92c47799f6ad23637fa63e030f0be968 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
 f93f4efac83c565cd33eb7eb67dcaca335f1c226 
  engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java 
ee6721ab445a5222d0087dc9170e0b58f9eef91a 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
4aa5fc80d9660d2f985db98124c33465bd99767f 
  
engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
 b1ac2f853374d6f1ddd9087919dbc16db0433f59 
  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 6256e2526ef9bd4632a5e3873c4d9531eb301c7f 
  engine/schema/src/com/cloud/storage/VMTemplateVO.java 
9a77cbf873aa9e422985fbcdc0ae7e18b8c78d4c 
  engine/schema/src/com/cloud/storage/VolumeVO.java 
e328253a596891029c2b55bea81b7ead425251ee 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
 a976bfbf6fe46306d20ad939c335bba6b9b7be54 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
 92793f1fb1a08a455a78667ba4a39ae162378360 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/StoragePoolVO.java 
1508ce0b28c83968c25d9601b6dae34e1a73dbb0 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/store/TemplateObject.java
 7288d454c30fdb81445e43549145f1f2da8533e4 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/ClusterScopeStoragePoolAllocator.java
 ea084c7555468001a12376640d9785b1cf852948 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
 446e101141bafde28615d766fdffd3a36ee8f3ce 
  
engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java 
c1aa8c2f0d49eb6bc6ff124dd4d87b7b714f62e9 
  
engine/storage/src/org/apache/cloudstack/storage/volume/datastore/PrimaryDataStoreHelper.java
 6b129755009413faae6685a62cfb3ae7b62b42f3 
  
engine/storage/volume/src/org/apache/cloudstack/storage/datastore/PrimaryDataStoreImpl.java
 f3c9e790277a4dc27fa

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

> On July 18, 2014, 4:16 a.m., Mike Tutkowski wrote:
> > Hi,
> > 
> > It's been a while since we've had any activity review wise on this feature.
> > 
> > Can you guys tell me where we're currently at?
> > 
> > Thanks!
> > Mike

Sorry Mike,

There are some troubles with my machines last week.

I have updated new diff and adding integration tests. Fooling around with 
marvin is great but may be I need more times with it.

Thanks!

Hieu LE


- Hieu


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22799/#review48109
---


On July 21, 2014, 3:56 a.m., Hieu LE wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22799/
> ---
> 
> (Updated July 21, 2014, 3:56 a.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski and Tim Mackey.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> As discussed in mailing list, this patch is applied for golden primary 
> storage in [1].
> I have changed the term from "golden" to "base" because there are some 
> functions and variables in CloudStack also use "base" for base image.
> This patch only apply for Xen Server.
> 
> [1]: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+Storage
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/deploy/DeployDestination.java 
> 4ded5ebe7a18252da471ee25019856f2b2f772e0 
>   api/src/com/cloud/storage/StoragePool.java 
> 8e03c3348f3a6dd3156ab9e440126ea317957dc0 
>   api/src/com/cloud/template/VirtualMachineTemplate.java 
> 599212bb039fdbb78511019e8f0a6ea4b4a84440 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 
> ae5d6f05b6b52f60b151369a641cb11fcbb558af 
>   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 
> 2350f6b389203e2c6cc2182fe03fe9a95e936b81 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>  ae44bc9373232d242e4ebdcf76844969f0fe69fc 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/ListStoragePoolsCmd.java
>  ed123db 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
>  3d1a77353257c814efaf60875ffdf99603bc414e 
>   
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
>  f478c9bc8eebf867a03deb4add1bf695ac3ec0ad 
>   api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 
> 3571866fe74dca9aa5fe0d11373313eab97e94ac 
>   api/src/org/apache/cloudstack/api/response/TemplateResponse.java 
> 3e21043e339103c021d3c9e767acac8b3837f760 
>   core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java PRE-CREATION 
>   core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java PRE-CREATION 
>   core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java 
> 29e53b0d9581f764a17ea285606213d2c045b029 
>   core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java 
> b201c386f4975913f13c575d7685e50cedc7d92f 
>   
> core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
> 33361e87265df05e00bfa6dba810d2b68ae8d923 
>   core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java 
> 66feaecb5ef20053db50956e2801fec096a350c9 
>   core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
> 114c8854d1504436523aa99c78bf2b4d84a12077 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
>  1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
>  dfdbd8ab92c47799f6ad23637fa63e030f0be968 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
>  f93f4efac83c565cd33eb7eb67dcaca335f1c226 
>   engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java 
> ee6721ab445a5222d0087dc9170e0b58f9eef91a 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> 4aa5fc80d9660d2f985db98124c33465bd99767f 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
>  b1ac2f853374d6f1ddd9087919dbc16db0433f59 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  6256e2526ef9bd4632a5e3873c4d9531eb301c7f 
>   engine/schema/src/com/cloud/storage/VMTemplateVO.java 
> 9a77cbf873aa9e422985fbcdc0ae7e18b8c78d4c 
>   engine/schema/src/com/cloud/storage/VolumeVO.java 
> e328253a596891029c2b55bea81b7ead425251ee 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>  a976bfbf6fe46306d20ad939c335bba6b9b7be54 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>  92793f1fb1a08a455a78667ba4a39ae162378360 
>   
> engine/schema/sr

Review Request 23723: Added the extra space in the error message which was having readability issue.

[Damodar Reddy Talakanti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23723/
---

Review request for cloudstack and Santhosh Edukulla.


Repository: cloudstack-git


Description
---

Added the extra space in the error message which was having readability issue.


Diffs
-

  
api/src/org/apache/cloudstack/api/command/user/firewall/CreateEgressFirewallRuleCmd.java
 90aed5e 

Diff: https://reviews.apache.org/r/23723/diff/


Testing
---


Thanks,

Damodar Reddy Talakanti

Re: Review Request 23723: Added the extra space in the error message which was having readability issue.

[Santhosh Edukulla]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23723/#review48197
---

Ship it!


Ship It!

- Santhosh Edukulla


On July 21, 2014, 4:04 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23723/
> ---
> 
> (Updated July 21, 2014, 4:04 a.m.)
> 
> 
> Review request for cloudstack and Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added the extra space in the error message which was having readability issue.
> 
> 
> Diffs
> -
> 
>   
> api/src/org/apache/cloudstack/api/command/user/firewall/CreateEgressFirewallRuleCmd.java
>  90aed5e 
> 
> Diff: https://reviews.apache.org/r/23723/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Mike Tutkowski]

Thanks!

Adding Marvin tests is not a prerequisite to your code being committed. I
just strongly recommend you consider such tests.

Essentially it is ideal to have Marvin tests, but not required.

I'm glad to see the list of tests you've performed manually. Thanks for
adding that to Review Board.


On Sun, Jul 20, 2014 at 9:59 PM, Hieu LE  wrote:

>
>
> > On July 18, 2014, 4:16 a.m., Mike Tutkowski wrote:
> > > Hi,
> > >
> > > It's been a while since we've had any activity review wise on this
> feature.
> > >
> > > Can you guys tell me where we're currently at?
> > >
> > > Thanks!
> > > Mike
>
> Sorry Mike,
>
> There are some troubles with my machines last week.
>
> I have updated new diff and adding integration tests. Fooling around with
> marvin is great but may be I need more times with it.
>
> Thanks!
>
> Hieu LE
>
>
> - Hieu
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22799/#review48109
> ---
>
>
> On July 21, 2014, 3:56 a.m., Hieu LE wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/22799/
> > ---
> >
> > (Updated July 21, 2014, 3:56 a.m.)
> >
> >
> > Review request for cloudstack, Mike Tutkowski and Tim Mackey.
> >
> >
> > Repository: cloudstack-git
> >
> >
> > Description
> > ---
> >
> > As discussed in mailing list, this patch is applied for golden primary
> storage in [1].
> > I have changed the term from "golden" to "base" because there are some
> functions and variables in CloudStack also use "base" for base image.
> > This patch only apply for Xen Server.
> >
> > [1]:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+Storage
> >
> >
> > Diffs
> > -
> >
> >   api/src/com/cloud/deploy/DeployDestination.java
> 4ded5ebe7a18252da471ee25019856f2b2f772e0
> >   api/src/com/cloud/storage/StoragePool.java
> 8e03c3348f3a6dd3156ab9e440126ea317957dc0
> >   api/src/com/cloud/template/VirtualMachineTemplate.java
> 599212bb039fdbb78511019e8f0a6ea4b4a84440
> >   api/src/org/apache/cloudstack/api/ApiConstants.java
> ae5d6f05b6b52f60b151369a641cb11fcbb558af
> >   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java
> 2350f6b389203e2c6cc2182fe03fe9a95e936b81
> >
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
> ae44bc9373232d242e4ebdcf76844969f0fe69fc
> >
> api/src/org/apache/cloudstack/api/command/admin/storage/ListStoragePoolsCmd.java
> ed123db
> >
> api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
> 3d1a77353257c814efaf60875ffdf99603bc414e
> >
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
> f478c9bc8eebf867a03deb4add1bf695ac3ec0ad
> >   api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java
> 3571866fe74dca9aa5fe0d11373313eab97e94ac
> >   api/src/org/apache/cloudstack/api/response/TemplateResponse.java
> 3e21043e339103c021d3c9e767acac8b3837f760
> >   core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java
> PRE-CREATION
> >   core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java
> PRE-CREATION
> >   core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java
> 29e53b0d9581f764a17ea285606213d2c045b029
> >   core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java
> b201c386f4975913f13c575d7685e50cedc7d92f
> >
> core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java
> 33361e87265df05e00bfa6dba810d2b68ae8d923
> >
> core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java
> 66feaecb5ef20053db50956e2801fec096a350c9
> >
> core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java
> 114c8854d1504436523aa99c78bf2b4d84a12077
> >
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
> 1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9
> >
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
> dfdbd8ab92c47799f6ad23637fa63e030f0be968
> >
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
> f93f4efac83c565cd33eb7eb67dcaca335f1c226
> >
> engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java
> ee6721ab445a5222d0087dc9170e0b58f9eef91a
> >   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> 4aa5fc80d9660d2f985db98124c33465bd99767f
> >
> engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
> b1ac2f853374d6f1ddd9087919dbc16db0433f59
> >
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
> 6256e2526ef9bd4632a5e3873c4d9531eb301c7f
> >   engine/schema/src/com/cloud/storage/VMTemplateVO.java
> 9a77cbf873aa9e422985fbc

RE: DNS service on VR not responding

[Sanjeev Neelarapu]

Hi,

Can you check if the VR is able to resolve the domain names by pinging from VR 
? 

-Sanjeev

-Original Message-
From: Vihar [mailto:vih1...@gmail.com] 
Sent: Monday, July 21, 2014 5:43 AM
To: us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: RE: DNS service on VR not responding

Hi,

Yes, if I remove or comment out the first nameserver entry for the VR's IP, and 
only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be running fine and will be 
able to resolve domains properly."

Are you able to ping the first DNS server IP address that you commented out?

Regards
Vihar K
 On Jul 20, 2014 11:29 PM, "Santhosh Edukulla" 
wrote:

> Do a traceroute to an external domain say google.com from guest vm, as 
> you mentioned below, both by commenting out vr ip and not, in 
> resolv.conf, you may see the difference.
>
> "Yes, if I remove or comment out the first nameserver entry for the 
> VR's IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be 
> running fine and will be able to resolve domains properly."
>
>
> Santhosh
> 
> From: Indra Pramana [in...@sg.or.id]
> Sent: Sunday, July 20, 2014 1:48 PM
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: DNS service on VR not responding
>
> Hi Santhosh,
>
> Good day to you, and thank you for your email.
>
> Traceroute packets seems to be dropped, I think it's by default. See 
> result
> below:
>
> # traceroute X.X.X.2
> traceroute to X.X.X.2 (X.X.X.2), 30 hops max, 60 byte packets
>  1  * * *
>  2  * * *
>  3  * * *
>
> However, I am able to ping, and there is a response when I tried to 
> telnet to port 53.
>
> 64 bytes from X.X.X.2: icmp_req=4 ttl=64 time=2.00 ms
> 64 bytes from X.X.X.2: icmp_req=5 ttl=64 time=0.291 ms
> 64 bytes from X.X.X.2: icmp_req=6 ttl=64 time=0.384 ms ^C
> --- X.X.X.2 ping statistics ---
> 6 packets transmitted, 6 received, 0% packet loss, time 4999ms rtt 
> min/avg/max/mdev = 0.270/0.603/2.006/0.628 ms
>
> # telnet X.X.X.2 53
> Trying X.X.X.2...
> Connected to X.X.X.2.
> Escape character is '^]'.
>
> netstat -a on the VR shows the service is listening on domain port (53).
>
> tcp0  0 r-2606-VM:domain*:* LISTEN
>
> tcp0  0 X.X.X.2:domain *:* LISTEN
>
> udp   156992  0 r-2606-VM:domain*:*
>
> udp   164032  0 X.X.X.2:domain *:*
>
> Can you advise if there's anything else I need to check?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
>
> On Mon, Jul 21, 2014 at 1:17 AM, Santhosh Edukulla < 
> santhosh.eduku...@citrix.com> wrote:
>
> > Run trace route from guest vms, the result will yield to the point 
> > where packet drop is happening, could be a network acl rule issue, 
> > but tracert command can lead to some answers.
> >
> > List running ports as well on VR, do a telnet to dns port on router 
> > from guest vm to verify for its response.
> >
> > Santhosh
> > 
> > From: Indra Pramana [in...@sg.or.id]
> > Sent: Sunday, July 20, 2014 1:06 PM
> > To: us...@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Subject: Re: DNS service on VR not responding
> >
> > Hi Rafael,
> >
> > Good day to you, and thank you for your reply.
> >
> > Can't find anything wrong on dnsmasq.log / daemon.log, just some log 
> > entries related to DHCP, nothing on DNS. I masked the IP addresses 
> > since they are public.
> >
> > ===
> > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPDISCOVER(eth0) X.X.X.X
> > 06:62:a8:01:13:37
> > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPOFFER(eth0) X.X.X.X
> > 06:62:a8:01:13:37
> > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPREQUEST(eth0) X.X.X.X
> > 06:62:a8:01:13:37
> > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> > 06:62:a8:01:13:37 yy
> > Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPINFORM(eth0) X.X.X.X
> > 06:43:4a:01:12:65
> > Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> > 06:43:4a:01:12:65 zz
> > ===
> >
> > Yes, the guest VMs are having difficulties resolving domains into IP 
> > addresses because of the problem on the VR's DNS server.
> >
> > $ host www.google.com X.X.X.X (where X.X.X.X is the IP address of 
> > the
> VR)
> > ;; connection timed out; no servers could be reached
> >
> > However, from within the VR, I am able to resolve domains just fine.
> >
> > Any advise where can I start troubleshooting this?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> >
> > On Sun, Jul 20, 2014 at 11:26 PM, Rafael Weingartner < 
> > rafaelweingart...@gmail.com> wrote:
> >
> > > Have you taken a look at dnsmasq.log in the VR ?
> > > What do you mean with not responding? The addresses are not being
> > resolved
> > > to ip addresses?
> > >
> > >
> > > On Sun, Jul 20, 2014 at 11:53 AM, Indra Pramana 
> wrote:
> > >
> > > > Dear all,
> > > >
> > > > All our guest VMs are having our virtual router (VR)'s

Re: Review Request 23550: Fixed coverity reported issues in UserVmManagerImpl

[Santhosh Edukulla]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23550/#review48198
---

Ship it!


Ship It!

- Santhosh Edukulla


On July 16, 2014, 12:37 p.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23550/
> ---
> 
> (Updated July 16, 2014, 12:37 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland and Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed coverity reported issues in UserVmManagerImpl
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java dac4acf 
> 
> Diff: https://reviews.apache.org/r/23550/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Review Request 23550: Fixed coverity reported issues in UserVmManagerImpl

[Santhosh Edukulla]

> On July 16, 2014, 3:35 p.m., Santhosh Edukulla wrote:
> > server/src/com/cloud/vm/UserVmManagerImpl.java, line 856
> > 
> >
> > I believe we are verifying the max size of an integer? If yes, use 
> > limits,  something like Integer.MAX_VALUE, integer size varies according to 
> > platform. That way we dont need to worry about the numerical value and it 
> > is taken care automatically.
> 
> Rajani Karuturi wrote:
> Integer.parseInt would never return a value > Integer.MAX_VALUE. It will 
> throw NumberFormatException and NumbersUtil would return the default value 
> -1. The max check would always be false and hence not required. 
> 
> Also, Java integer size is platform independent and would always be 2^31 
> -1.

Ok, just add coverity to bugs column, as inquired on dev list.


- Santhosh


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23550/#review47889
---


On July 16, 2014, 12:37 p.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23550/
> ---
> 
> (Updated July 16, 2014, 12:37 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland and Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed coverity reported issues in UserVmManagerImpl
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java dac4acf 
> 
> Diff: https://reviews.apache.org/r/23550/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

RE: Review Request 22799: Golden (Base) Primary Storage feature

[Sudha Ponnaganti]

Mike / Hieu,

Thank you for your consideration. Even if it is not needed at the review time, 
can Marvin tests ( if applicable, simulator tests) can be added before you 
close on the feature. That would help to run regression tests on this feature 
for all releases. 

Some sort of automated tests ( unit tests or Marvin tests in place of unit 
tests) must be checked in for feature to be accepted. This was followed closely 
in the earlier releases and slowly this is being ignored. Can reviewers be more 
stringent regarding this merge criteria. 

Thanks
/Sudha

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Sunday, July 20, 2014 9:16 PM
To: dev@cloudstack.apache.org; Hieu LE
Cc: Tim Mackey
Subject: Re: Review Request 22799: Golden (Base) Primary Storage feature

Thanks!

Adding Marvin tests is not a prerequisite to your code being committed. I just 
strongly recommend you consider such tests.

Essentially it is ideal to have Marvin tests, but not required.

I'm glad to see the list of tests you've performed manually. Thanks for adding 
that to Review Board.


On Sun, Jul 20, 2014 at 9:59 PM, Hieu LE  wrote:

>
>
> > On July 18, 2014, 4:16 a.m., Mike Tutkowski wrote:
> > > Hi,
> > >
> > > It's been a while since we've had any activity review wise on this
> feature.
> > >
> > > Can you guys tell me where we're currently at?
> > >
> > > Thanks!
> > > Mike
>
> Sorry Mike,
>
> There are some troubles with my machines last week.
>
> I have updated new diff and adding integration tests. Fooling around 
> with marvin is great but may be I need more times with it.
>
> Thanks!
>
> Hieu LE
>
>
> - Hieu
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22799/#review48109
> ---
>
>
> On July 21, 2014, 3:56 a.m., Hieu LE wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/22799/
> > ---
> >
> > (Updated July 21, 2014, 3:56 a.m.)
> >
> >
> > Review request for cloudstack, Mike Tutkowski and Tim Mackey.
> >
> >
> > Repository: cloudstack-git
> >
> >
> > Description
> > ---
> >
> > As discussed in mailing list, this patch is applied for golden 
> > primary
> storage in [1].
> > I have changed the term from "golden" to "base" because there are 
> > some
> functions and variables in CloudStack also use "base" for base image.
> > This patch only apply for Xen Server.
> >
> > [1]:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+
> Storage
> >
> >
> > Diffs
> > -
> >
> >   api/src/com/cloud/deploy/DeployDestination.java
> 4ded5ebe7a18252da471ee25019856f2b2f772e0
> >   api/src/com/cloud/storage/StoragePool.java
> 8e03c3348f3a6dd3156ab9e440126ea317957dc0
> >   api/src/com/cloud/template/VirtualMachineTemplate.java
> 599212bb039fdbb78511019e8f0a6ea4b4a84440
> >   api/src/org/apache/cloudstack/api/ApiConstants.java
> ae5d6f05b6b52f60b151369a641cb11fcbb558af
> >   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java
> 2350f6b389203e2c6cc2182fe03fe9a95e936b81
> >
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStorageP
> oolCmd.java ae44bc9373232d242e4ebdcf76844969f0fe69fc
> >
> api/src/org/apache/cloudstack/api/command/admin/storage/ListStoragePoo
> lsCmd.java
> ed123db
> >
> api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStorageP
> oolCmd.java 3d1a77353257c814efaf60875ffdf99603bc414e
> >
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTempla
> teCmd.java f478c9bc8eebf867a03deb4add1bf695ac3ec0ad
> >   
> > api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java
> 3571866fe74dca9aa5fe0d11373313eab97e94ac
> >   api/src/org/apache/cloudstack/api/response/TemplateResponse.java
> 3e21043e339103c021d3c9e767acac8b3837f760
> >   core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java
> PRE-CREATION
> >   core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java
> PRE-CREATION
> >   core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java
> 29e53b0d9581f764a17ea285606213d2c045b029
> >   core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java
> b201c386f4975913f13c575d7685e50cedc7d92f
> >
> core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTe
> st.java
> 33361e87265df05e00bfa6dba810d2b68ae8d923
> >
> core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.
> java
> 66feaecb5ef20053db50956e2801fec096a350c9
> >
> core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.jav
> a
> 114c8854d1504436523aa99c78bf2b4d84a12077
> >
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/Prim
> aryDataStoreParameters.java
> 1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9
> >
> engine/api/src/org/apac

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Mike Tutkowski]

Thanks for the note, Sudha.

I was not aware we were treating Marvin tests are a requirement. That is
interesting to know as I've not seen that rule followed all the time (as
you say, perhaps people have been backing off on that informally).

I agree, though, that automated tests are critical and going to become more
so as additional features continue to be added to CloudStack.


On Sun, Jul 20, 2014 at 10:23 PM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:

> Mike / Hieu,
>
> Thank you for your consideration. Even if it is not needed at the review
> time, can Marvin tests ( if applicable, simulator tests) can be added
> before you close on the feature. That would help to run regression tests on
> this feature for all releases.
>
> Some sort of automated tests ( unit tests or Marvin tests in place of unit
> tests) must be checked in for feature to be accepted. This was followed
> closely in the earlier releases and slowly this is being ignored. Can
> reviewers be more stringent regarding this merge criteria.
>
> Thanks
> /Sudha
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Sunday, July 20, 2014 9:16 PM
> To: dev@cloudstack.apache.org; Hieu LE
> Cc: Tim Mackey
> Subject: Re: Review Request 22799: Golden (Base) Primary Storage feature
>
> Thanks!
>
> Adding Marvin tests is not a prerequisite to your code being committed. I
> just strongly recommend you consider such tests.
>
> Essentially it is ideal to have Marvin tests, but not required.
>
> I'm glad to see the list of tests you've performed manually. Thanks for
> adding that to Review Board.
>
>
> On Sun, Jul 20, 2014 at 9:59 PM, Hieu LE  wrote:
>
> >
> >
> > > On July 18, 2014, 4:16 a.m., Mike Tutkowski wrote:
> > > > Hi,
> > > >
> > > > It's been a while since we've had any activity review wise on this
> > feature.
> > > >
> > > > Can you guys tell me where we're currently at?
> > > >
> > > > Thanks!
> > > > Mike
> >
> > Sorry Mike,
> >
> > There are some troubles with my machines last week.
> >
> > I have updated new diff and adding integration tests. Fooling around
> > with marvin is great but may be I need more times with it.
> >
> > Thanks!
> >
> > Hieu LE
> >
> >
> > - Hieu
> >
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/22799/#review48109
> > ---
> >
> >
> > On July 21, 2014, 3:56 a.m., Hieu LE wrote:
> > >
> > > ---
> > > This is an automatically generated e-mail. To reply, visit:
> > > https://reviews.apache.org/r/22799/
> > > ---
> > >
> > > (Updated July 21, 2014, 3:56 a.m.)
> > >
> > >
> > > Review request for cloudstack, Mike Tutkowski and Tim Mackey.
> > >
> > >
> > > Repository: cloudstack-git
> > >
> > >
> > > Description
> > > ---
> > >
> > > As discussed in mailing list, this patch is applied for golden
> > > primary
> > storage in [1].
> > > I have changed the term from "golden" to "base" because there are
> > > some
> > functions and variables in CloudStack also use "base" for base image.
> > > This patch only apply for Xen Server.
> > >
> > > [1]:
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+
> > Storage
> > >
> > >
> > > Diffs
> > > -
> > >
> > >   api/src/com/cloud/deploy/DeployDestination.java
> > 4ded5ebe7a18252da471ee25019856f2b2f772e0
> > >   api/src/com/cloud/storage/StoragePool.java
> > 8e03c3348f3a6dd3156ab9e440126ea317957dc0
> > >   api/src/com/cloud/template/VirtualMachineTemplate.java
> > 599212bb039fdbb78511019e8f0a6ea4b4a84440
> > >   api/src/org/apache/cloudstack/api/ApiConstants.java
> > ae5d6f05b6b52f60b151369a641cb11fcbb558af
> > >   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java
> > 2350f6b389203e2c6cc2182fe03fe9a95e936b81
> > >
> > api/src/org/apache/cloudstack/api/command/admin/storage/CreateStorageP
> > oolCmd.java ae44bc9373232d242e4ebdcf76844969f0fe69fc
> > >
> > api/src/org/apache/cloudstack/api/command/admin/storage/ListStoragePoo
> > lsCmd.java
> > ed123db
> > >
> > api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStorageP
> > oolCmd.java 3d1a77353257c814efaf60875ffdf99603bc414e
> > >
> > api/src/org/apache/cloudstack/api/command/user/template/RegisterTempla
> > teCmd.java f478c9bc8eebf867a03deb4add1bf695ac3ec0ad
> > >
> > > api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java
> > 3571866fe74dca9aa5fe0d11373313eab97e94ac
> > >   api/src/org/apache/cloudstack/api/response/TemplateResponse.java
> > 3e21043e339103c021d3c9e767acac8b3837f760
> > >   core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java
> > PRE-CREATION
> > >   core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java
> > PRE-CREATION
> > >   core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.ja

Re: Why is the I/O speed of VM so terrible when using CloudStack4.2 + KVM deployment

[David Nalley]

IIRC, virtio wasn't the default until EL6.4.

--David

On Sun, Jul 20, 2014 at 10:12 PM, evanitsharp  wrote:
> Dear all:
>  I/O speed of our guest VMs are so slow when uploading or downloading 
> file from them.
>  I have tried Basic and Advanced network, but I got the same result.
>
> Our environment is :
>  CloudStack 4.2.1 + KVM Host(with rhel6.3 running on it).
>
> But if I use CentOS 6.4 instead of rhel 6.3 as operating system of KVM host, 
> The I/O speed is normal.
> Also, CloudStack 4.1.1 doesn't have this problem.The problem only occuring on 
> CloudStack 4.2 or later version
>
> Here are my test data around different version of CloudStack deployment:
> PS: Target VM are virtual machines on KVM Host with WEB or FTP service
> CloudStack versionNetwork type of CloudStackKVM software versionOperating 
> system of KVMStorage type of VMOperating system of VMread/write speed of VM's 
> diskAverage speed when downloading file to PC of LAN from target VMAverage 
> speed when downloading file to target  VM from server of LAN
>
> 4.1.1BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img 
> version 0.12.1rhel6.3sharedrhel6.349.8 MB/sWEB:38.9 MB/s  FTP:42.2 
> MB/sWEB:41.0 MB/s  FTP:31.7 MB/s
> 4.1.1BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img 
> version 0.12.1rhel6.3localrhel6.3116 MB/sWEB:80.6 MB/s  FTP:80.2 MB/sWEB:103 
> MB/s  FTP:64.1 MB/s
>
>
> 4.2.1BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img 
> version 0.12.1rhel6.346.0 MB/sWEB:1.05 MB/s  FTP:1 MB/sWEB:700 KB/s  FTP:14 
> MB/s
> 4.2.1AdvancedQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img 
> version 0.12.1CentOS release 6.4 (Final)sharedrhel6.340.6 MB/sWEB:23.8 
> MB/sWEB:22.6 KB/s
> 4.2.1AdvancedQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img 
> version 0.12.1CentOS release 6.4 (Final)localrhel6.348.7 MB/sWEB:24.2 MB/s  
> FTP:24.5MB/sWEB:24.2 MB/s  FTP:24.8MB/s
>
> 4.3BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img version 
> 0.12.1rhel6.3sharedrhel6.335.9 MB/sWEB:218 KB/s  FTP:211.9 KB/sWEB:811 KB/s  
> FTP:3.1 MB/s
> 4.3BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img version 
> 0.12.2rhel6.3localrhel6.348.5 MB/sWEB:217 KB/s  FTP:212.5 KB/sWEB:708 KB/s  
> FTP:3.0 MB/s
>
>
>
> Any advice on how can I resolve the problem?
> Looking forward to your reply, thank you.
>
> Evan
>
>
>
>
> Evan
>
> Mail:evanitsh...@gmail.com

Re: DNS service on VR not responding

[Indra Pramana]

Hi Vihar,

Yes I can.

Looking forward to your reply, thank you.

Cheers.



On Mon, Jul 21, 2014 at 8:13 AM, Vihar  wrote:

> Hi,
>
> Yes, if I remove or comment out the first nameserver entry for the VR's
> IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be running fine
> and will be able to resolve domains properly."
>
> Are you able to ping the first DNS server IP address that you commented
> out?
>
> Regards
> Vihar K
>  On Jul 20, 2014 11:29 PM, "Santhosh Edukulla" <
> santhosh.eduku...@citrix.com>
> wrote:
>
> > Do a traceroute to an external domain say google.com from guest vm, as
> > you mentioned below, both by commenting out vr ip and not, in
> resolv.conf,
> > you may see the difference.
> >
> > "Yes, if I remove or comment out the first nameserver entry for the VR's
> > IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be running fine
> > and will be able to resolve domains properly."
> >
> >
> > Santhosh
> > 
> > From: Indra Pramana [in...@sg.or.id]
> > Sent: Sunday, July 20, 2014 1:48 PM
> > To: us...@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Subject: Re: DNS service on VR not responding
> >
> > Hi Santhosh,
> >
> > Good day to you, and thank you for your email.
> >
> > Traceroute packets seems to be dropped, I think it's by default. See
> result
> > below:
> >
> > # traceroute X.X.X.2
> > traceroute to X.X.X.2 (X.X.X.2), 30 hops max, 60 byte packets
> >  1  * * *
> >  2  * * *
> >  3  * * *
> >
> > However, I am able to ping, and there is a response when I tried to
> telnet
> > to port 53.
> >
> > 64 bytes from X.X.X.2: icmp_req=4 ttl=64 time=2.00 ms
> > 64 bytes from X.X.X.2: icmp_req=5 ttl=64 time=0.291 ms
> > 64 bytes from X.X.X.2: icmp_req=6 ttl=64 time=0.384 ms
> > ^C
> > --- X.X.X.2 ping statistics ---
> > 6 packets transmitted, 6 received, 0% packet loss, time 4999ms
> > rtt min/avg/max/mdev = 0.270/0.603/2.006/0.628 ms
> >
> > # telnet X.X.X.2 53
> > Trying X.X.X.2...
> > Connected to X.X.X.2.
> > Escape character is '^]'.
> >
> > netstat -a on the VR shows the service is listening on domain port (53).
> >
> > tcp0  0 r-2606-VM:domain*:*
> LISTEN
> >
> > tcp0  0 X.X.X.2:domain *:* LISTEN
> >
> > udp   156992  0 r-2606-VM:domain*:*
> >
> > udp   164032  0 X.X.X.2:domain *:*
> >
> > Can you advise if there's anything else I need to check?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> >
> >
> > On Mon, Jul 21, 2014 at 1:17 AM, Santhosh Edukulla <
> > santhosh.eduku...@citrix.com> wrote:
> >
> > > Run trace route from guest vms, the result will yield to the point
> where
> > > packet drop is happening, could be a network acl rule issue, but
> tracert
> > > command can lead to some answers.
> > >
> > > List running ports as well on VR, do a telnet to dns port on router
> from
> > > guest vm to verify for its response.
> > >
> > > Santhosh
> > > 
> > > From: Indra Pramana [in...@sg.or.id]
> > > Sent: Sunday, July 20, 2014 1:06 PM
> > > To: us...@cloudstack.apache.org
> > > Cc: dev@cloudstack.apache.org
> > > Subject: Re: DNS service on VR not responding
> > >
> > > Hi Rafael,
> > >
> > > Good day to you, and thank you for your reply.
> > >
> > > Can't find anything wrong on dnsmasq.log / daemon.log, just some log
> > > entries related to DHCP, nothing on DNS. I masked the IP addresses
> since
> > > they are public.
> > >
> > > ===
> > > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPDISCOVER(eth0) X.X.X.X
> > > 06:62:a8:01:13:37
> > > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPOFFER(eth0) X.X.X.X
> > > 06:62:a8:01:13:37
> > > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPREQUEST(eth0) X.X.X.X
> > > 06:62:a8:01:13:37
> > > Jul 20 16:21:51 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> > > 06:62:a8:01:13:37 yy
> > > Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPINFORM(eth0) X.X.X.X
> > > 06:43:4a:01:12:65
> > > Jul 20 16:23:53 r-2606-VM dnsmasq[3519]: DHCPACK(eth0) X.X.X.X
> > > 06:43:4a:01:12:65 zz
> > > ===
> > >
> > > Yes, the guest VMs are having difficulties resolving domains into IP
> > > addresses because of the problem on the VR's DNS server.
> > >
> > > $ host www.google.com X.X.X.X (where X.X.X.X is the IP address of the
> > VR)
> > > ;; connection timed out; no servers could be reached
> > >
> > > However, from within the VR, I am able to resolve domains just fine.
> > >
> > > Any advise where can I start troubleshooting this?
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> > >
> > >
> > > On Sun, Jul 20, 2014 at 11:26 PM, Rafael Weingartner <
> > > rafaelweingart...@gmail.com> wrote:
> > >
> > > > Have you taken a look at dnsmasq.log in the VR ?
> > > > What do you mean with not responding? The addresses are not being
> > > resolved
> > > > to ip addresses?
> > > >
> > > >
> > > > On Sun, Jul 20, 2014 at 11:53 AM, Indra P

Re: DNS service on VR not responding

[Indra Pramana]

Hi Sanjeev,

Good day to you, and thank you for your reply.

Yes, I can resolve domains without any issues from within the VR itself.

root@r-2606-VM:/etc# ping yahoo.com
PING yahoo.com (98.139.183.24): 56 data bytes
64 bytes from 98.139.183.24: icmp_seq=0 ttl=47 time=250.473 ms
64 bytes from 98.139.183.24: icmp_seq=1 ttl=47 time=239.240 ms
64 bytes from 98.139.183.24: icmp_seq=2 ttl=45 time=247.605 ms
64 bytes from 98.139.183.24: icmp_seq=3 ttl=45 time=244.913 ms
^C--- yahoo.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 239.240/245.558/250.473/4.144 ms

root@r-2606-VM:/etc# ping google.com
PING google.com (74.125.68.102): 56 data bytes
64 bytes from 74.125.68.102: icmp_seq=0 ttl=52 time=1.353 ms
64 bytes from 74.125.68.102: icmp_seq=1 ttl=52 time=1.199 ms
64 bytes from 74.125.68.102: icmp_seq=2 ttl=52 time=1.268 ms
64 bytes from 74.125.68.102: icmp_seq=3 ttl=52 time=1.287 ms
^C--- google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.199/1.277/1.353/0.055 ms

The VR uses 8.8.8.8 and 8.8.4.4 to resolve domains.

root@r-2606-VM:/etc# cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

I can ping both name servers without any issues.

root@r-2606-VM:/etc# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=52 time=4.693 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=2.390 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=2.523 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=2.458 ms
^C--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.390/3.016/4.693/0.969 ms

root@r-2606-VM:/etc# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 56 data bytes
64 bytes from 8.8.4.4: icmp_seq=0 ttl=52 time=2.649 ms
64 bytes from 8.8.4.4: icmp_seq=1 ttl=52 time=2.458 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=52 time=2.436 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=52 time=2.393 ms
^C--- 8.8.4.4 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.393/2.484/2.649/0.098 ms

Looking forward to your reply, thank you.

Cheers.




On Mon, Jul 21, 2014 at 12:18 PM, Sanjeev Neelarapu <
sanjeev.neelar...@citrix.com> wrote:

> Hi,
>
> Can you check if the VR is able to resolve the domain names by pinging
> from VR ?
>
> -Sanjeev
>
> -Original Message-
> From: Vihar [mailto:vih1...@gmail.com]
> Sent: Monday, July 21, 2014 5:43 AM
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: RE: DNS service on VR not responding
>
> Hi,
>
> Yes, if I remove or comment out the first nameserver entry for the VR's
> IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be running fine
> and will be able to resolve domains properly."
>
> Are you able to ping the first DNS server IP address that you commented
> out?
>
> Regards
> Vihar K
>  On Jul 20, 2014 11:29 PM, "Santhosh Edukulla" <
> santhosh.eduku...@citrix.com>
> wrote:
>
> > Do a traceroute to an external domain say google.com from guest vm, as
> > you mentioned below, both by commenting out vr ip and not, in
> > resolv.conf, you may see the difference.
> >
> > "Yes, if I remove or comment out the first nameserver entry for the
> > VR's IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be
> > running fine and will be able to resolve domains properly."
> >
> >
> > Santhosh
> > 
> > From: Indra Pramana [in...@sg.or.id]
> > Sent: Sunday, July 20, 2014 1:48 PM
> > To: us...@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Subject: Re: DNS service on VR not responding
> >
> > Hi Santhosh,
> >
> > Good day to you, and thank you for your email.
> >
> > Traceroute packets seems to be dropped, I think it's by default. See
> > result
> > below:
> >
> > # traceroute X.X.X.2
> > traceroute to X.X.X.2 (X.X.X.2), 30 hops max, 60 byte packets
> >  1  * * *
> >  2  * * *
> >  3  * * *
> >
> > However, I am able to ping, and there is a response when I tried to
> > telnet to port 53.
> >
> > 64 bytes from X.X.X.2: icmp_req=4 ttl=64 time=2.00 ms
> > 64 bytes from X.X.X.2: icmp_req=5 ttl=64 time=0.291 ms
> > 64 bytes from X.X.X.2: icmp_req=6 ttl=64 time=0.384 ms ^C
> > --- X.X.X.2 ping statistics ---
> > 6 packets transmitted, 6 received, 0% packet loss, time 4999ms rtt
> > min/avg/max/mdev = 0.270/0.603/2.006/0.628 ms
> >
> > # telnet X.X.X.2 53
> > Trying X.X.X.2...
> > Connected to X.X.X.2.
> > Escape character is '^]'.
> >
> > netstat -a on the VR shows the service is listening on domain port (53).
> >
> > tcp0  0 r-2606-VM:domain*:*
> LISTEN
> >
> > tcp0  0 X.X.X.2:domain *:* LISTEN
> >
> > udp   156992  0 r-2606-VM:domain*:*
> >
> > udp   164032  0 X.X.X.2:domain *:*
> >
> > Can you advise if there's anything else I need to check?
> >
> > Looking 

Re: Review Request 23550: Fixed coverity reported issues in UserVmManagerImpl

[Rajani Karuturi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23550/
---

(Updated July 21, 2014, 4:58 a.m.)


Review request for cloudstack, daan Hoogland and Santhosh Edukulla.


Bugs: COVERITY
https://issues.apache.org/jira/browse/COVERITY


Repository: cloudstack-git


Description
---

Fixed coverity reported issues in UserVmManagerImpl


Diffs
-

  server/src/com/cloud/vm/UserVmManagerImpl.java dac4acf 

Diff: https://reviews.apache.org/r/23550/diff/


Testing
---


Thanks,

Rajani Karuturi

Re: Review Request 23723: Added the extra space in the error message which was having readability issue.

[Damodar Reddy Talakanti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23723/
---

(Updated July 21, 2014, 4:59 a.m.)


Review request for cloudstack and Santhosh Edukulla.


Changes
---

added defect id


Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-7142

https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-7142


Repository: cloudstack-git


Description
---

Added the extra space in the error message which was having readability issue.


Diffs
-

  
api/src/org/apache/cloudstack/api/command/user/firewall/CreateEgressFirewallRuleCmd.java
 90aed5e 

Diff: https://reviews.apache.org/r/23723/diff/


Testing
---


Thanks,

Damodar Reddy Talakanti

Re: Review Request 23723: Added the extra space in the error message which was having readability issue.

[Damodar Reddy Talakanti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23723/
---

(Updated July 21, 2014, 5 a.m.)


Review request for cloudstack and Santhosh Edukulla.


Changes
---

added defect id


Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-7142

https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-7142


Repository: cloudstack-git


Description
---

Added the extra space in the error message which was having readability issue.


Diffs
-

  
api/src/org/apache/cloudstack/api/command/user/firewall/CreateEgressFirewallRuleCmd.java
 90aed5e 

Diff: https://reviews.apache.org/r/23723/diff/


Testing
---


Thanks,

Damodar Reddy Talakanti

Re: Review Request 23603: Fixed CLOUDSTACK-6983: unable to register lxc template

[Kishan Kavala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23603/#review48201
---



utils/src/org/apache/cloudstack/utils/template/TemplateUtils.java


You can add isCorrectExtension check for tar file type


- Kishan Kavala


On July 17, 2014, 11:56 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23603/
> ---
> 
> (Updated July 17, 2014, 11:56 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Marcus Sorensen.
> 
> 
> Bugs: CLOUDSTACK-6983
> https://issues.apache.org/jira/browse/CLOUDSTACK-6983
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added a check for tar.gz format in checktemplate
> 
> 
> Diffs
> -
> 
>   utils/src/org/apache/cloudstack/utils/template/TemplateUtils.java bad94de 
> 
> Diff: https://reviews.apache.org/r/23603/diff/
> 
> 
> Testing
> ---
> 
> manually tested register template on lxc
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases

[ASF Subversion and Git Services]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23605/#review48203
---


Commit 43dffaad5fd197c87a8dab087066f677a095dee7 in cloudstack's branch 
refs/heads/master from Koushik Das
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=43dffaa ]

Revert "CLOUDSTACK-7107: Disabling failed test case"

This reverts commit 186606a0bf82402e7755cd7998f133023cc96c6c.


- ASF Subversion and Git Services


On July 17, 2014, 7:47 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23605/
> ---
> 
> (Updated July 17, 2014, 7:47 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107
> https://issues.apache.org/jira/browse/CLOUDSTACK-7074
> https://issues.apache.org/jira/browse/CLOUDSTACK-7107
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Disabling failed test cases on master.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_primary_storage.py 66aec59 
>   test/integration/smoke/test_vm_life_cycle.py 240ab68 
> 
> Diff: https://reviews.apache.org/r/23605/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

Thank you, Sudha and Mike,

So I will implement some regression test on Marvin to ensure this feature.

BRs.


On Mon, Jul 21, 2014 at 11:30 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Thanks for the note, Sudha.
>
> I was not aware we were treating Marvin tests are a requirement. That is
> interesting to know as I've not seen that rule followed all the time (as
> you say, perhaps people have been backing off on that informally).
>
> I agree, though, that automated tests are critical and going to become
> more so as additional features continue to be added to CloudStack.
>
>
>  On Sun, Jul 20, 2014 at 10:23 PM, Sudha Ponnaganti <
> sudha.ponnaga...@citrix.com> wrote:
>
>> Mike / Hieu,
>>
>> Thank you for your consideration. Even if it is not needed at the review
>> time, can Marvin tests ( if applicable, simulator tests) can be added
>> before you close on the feature. That would help to run regression tests on
>> this feature for all releases.
>>
>> Some sort of automated tests ( unit tests or Marvin tests in place of
>> unit tests) must be checked in for feature to be accepted. This was
>> followed closely in the earlier releases and slowly this is being ignored.
>> Can reviewers be more stringent regarding this merge criteria.
>>
>> Thanks
>> /Sudha
>>
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: Sunday, July 20, 2014 9:16 PM
>> To: dev@cloudstack.apache.org; Hieu LE
>> Cc: Tim Mackey
>> Subject: Re: Review Request 22799: Golden (Base) Primary Storage feature
>>
>> Thanks!
>>
>> Adding Marvin tests is not a prerequisite to your code being committed. I
>> just strongly recommend you consider such tests.
>>
>> Essentially it is ideal to have Marvin tests, but not required.
>>
>> I'm glad to see the list of tests you've performed manually. Thanks for
>> adding that to Review Board.
>>
>>
>> On Sun, Jul 20, 2014 at 9:59 PM, Hieu LE  wrote:
>>
>> >
>> >
>> > > On July 18, 2014, 4:16 a.m., Mike Tutkowski wrote:
>> > > > Hi,
>> > > >
>> > > > It's been a while since we've had any activity review wise on this
>> > feature.
>> > > >
>> > > > Can you guys tell me where we're currently at?
>> > > >
>> > > > Thanks!
>> > > > Mike
>> >
>> > Sorry Mike,
>> >
>> > There are some troubles with my machines last week.
>> >
>> > I have updated new diff and adding integration tests. Fooling around
>> > with marvin is great but may be I need more times with it.
>> >
>> > Thanks!
>> >
>> > Hieu LE
>> >
>> >
>> > - Hieu
>> >
>> >
>> > ---
>> > This is an automatically generated e-mail. To reply, visit:
>> > https://reviews.apache.org/r/22799/#review48109
>> > ---
>> >
>> >
>> > On July 21, 2014, 3:56 a.m., Hieu LE wrote:
>> > >
>> > > ---
>> > > This is an automatically generated e-mail. To reply, visit:
>> > > https://reviews.apache.org/r/22799/
>> > > ---
>> > >
>> > > (Updated July 21, 2014, 3:56 a.m.)
>> > >
>> > >
>> > > Review request for cloudstack, Mike Tutkowski and Tim Mackey.
>> > >
>> > >
>> > > Repository: cloudstack-git
>> > >
>> > >
>> > > Description
>> > > ---
>> > >
>> > > As discussed in mailing list, this patch is applied for golden
>> > > primary
>> > storage in [1].
>> > > I have changed the term from "golden" to "base" because there are
>> > > some
>> > functions and variables in CloudStack also use "base" for base image.
>> > > This patch only apply for Xen Server.
>> > >
>> > > [1]:
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+
>> > Storage
>> > >
>> > >
>> > > Diffs
>> > > -
>> > >
>> > >   api/src/com/cloud/deploy/DeployDestination.java
>> > 4ded5ebe7a18252da471ee25019856f2b2f772e0
>> > >   api/src/com/cloud/storage/StoragePool.java
>> > 8e03c3348f3a6dd3156ab9e440126ea317957dc0
>> > >   api/src/com/cloud/template/VirtualMachineTemplate.java
>> > 599212bb039fdbb78511019e8f0a6ea4b4a84440
>> > >   api/src/org/apache/cloudstack/api/ApiConstants.java
>> > ae5d6f05b6b52f60b151369a641cb11fcbb558af
>> > >   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java
>> > 2350f6b389203e2c6cc2182fe03fe9a95e936b81
>> > >
>> > api/src/org/apache/cloudstack/api/command/admin/storage/CreateStorageP
>> > oolCmd.java ae44bc9373232d242e4ebdcf76844969f0fe69fc
>> > >
>> > api/src/org/apache/cloudstack/api/command/admin/storage/ListStoragePoo
>> > lsCmd.java
>> > ed123db
>> > >
>> > api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStorageP
>> > oolCmd.java 3d1a77353257c814efaf60875ffdf99603bc414e
>> > >
>> > api/src/org/apache/cloudstack/api/command/user/template/RegisterTempla
>> > teCmd.java f478c9bc8eebf867a03deb4add1bf695ac3ec0ad
>> > >
>> > > api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java
>> > 3571866fe74dca9aa5fe0d11373313eab97e94ac
>> > >   api