Ok, so the next step is to track that stdout and see if you can see
what jsvc complains about when it fails to start up the service.
On Wed, Sep 25, 2013 at 4:56 PM, Mike Tutkowski
<mike.tutkow...@solidfire.com> wrote:
> These also look good:
>
> mtutkowski@ubuntu:/etc/cloudstack/agent$ uname -m
> x86_64
> mtutkowski@ubuntu:/etc/cloudstack/agent$ virsh -c qemu:///system list
> Id Name State
> ----------------------------------
>
> mtutkowski@ubuntu:/etc/cloudstack/agent$ sudo ls -la
> /var/run/libvirt/libvirt-sock
> srwxrwx--- 1 root libvirtd 0 Sep 25 16:05 /var/run/libvirt/libvirt-sock
> mtutkowski@ubuntu:/etc/cloudstack/agent$ ls -l /dev/kvm
> crw-rw----+ 1 root kvm 10, 232 Sep 25 15:22 /dev/kvm
>
>
>
> On Wed, Sep 25, 2013 at 4:53 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> This is my new agent.properties file (with comments removed...looks
>> decent):
>>
>> guid=6b4aa1c2-2ac9-3c60-aabe-704aed40c684
>> resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
>> workers=5
>> host=192.168.233.1
>> port=8250
>> cluster=1
>> pod=1
>> zone=1
>> local.storage.uuid=aced86a2-2dd6-450a-93e5-1bc0ec3c73be
>> private.network.device=cloudbr0
>> public.network.device=cloudbr0
>> guest.network.device=cloudbr0
>>
>> Yeah, I was always writing stuff out using the logger. I should look into
>> redirecting stdout and stderr.
>>
>> Here were my steps to start and check the process status:
>>
>> mtutkowski@ubuntu:/etc/cloudstack/agent$ sudo /usr/sbin/service
>> cloudstack-agent start
>> * Starting CloudStack Agent cloudstack-agent
>> [ OK ]
>> mtutkowski@ubuntu:/etc/cloudstack/agent$ sudo ps -ef | grep jsvc
>> 1000 4605 3725 0 16:47 pts/1 00:00:00 grep --color=auto jsvc
>>
>> Also, this might be of interest:
>>
>> mtutkowski@ubuntu:/etc/cloudstack/agent$ lsmod | grep kvm
>> kvm_intel 137721 0
>> kvm 415549 1 kvm_intel
>>
>> mtutkowski@ubuntu:/etc/cloudstack/agent$ egrep -c '(vmx|svm)'
>> /proc/cpuinfo
>> 1
>>
>> mtutkowski@ubuntu:/etc/cloudstack/agent$ kvm-ok
>> INFO: /dev/kvm exists
>> KVM acceleration can be used
>>
>> mtutkowski@ubuntu:/etc/cloudstack/agent$ egrep -c ' lm ' /proc/cpuinfo
>> 1
>>
>> On Wed, Sep 25, 2013 at 4:39 PM, Marcus Sorensen <shadow...@gmail.com>wrote:
>>
>>> So you:
>>>
>>> 1. run that command
>>> 2. get a brand new agent.properties as a result
>>> 3. start the service
>>>
>>> but you don't see it in the process table?
>>>
>>> The agent's STDOUT doesn't go to the agent log, only log4j stuff. So
>>> if there were an error not printed via logger you'd not see it. I'm
>>> not as familiar with the debian/ubuntu stuff off the top of my head,
>>> but in /etc/init.d/cloudstack-agent on CentOS we do:
>>>
>>> start() {
>>> echo -n $"Starting $PROGNAME: "
>>> if hostname --fqdn >/dev/null 2>&1 ; then
>>> $JSVC -cp "$CLASSPATH" -pidfile "$PIDFILE" \
>>> -errfile $LOGDIR/cloudstack-agent.err -outfile
>>> $LOGDIR/cloudstack-agent.out $CLASS
>>> RETVAL=$?
>>> echo
>>> else
>>>
>>>
>>> Which sends STDOUT to cloudstack-agent.out and errors to
>>> cloudstack-agent.err. You can look to see what Ubuntu does.
>>>
>>> Out of curiosity, what do you get when you do 'lsmod | grep kvm' ? I
>>> know you didn't end up using it, but the devcloud-kvm instructions for
>>> vmware fusion tell you to ensure that your guest has hardware
>>> virtualization passthrough enabled, I'm wondering if it isn't.
>>>
>>> On Wed, Sep 25, 2013 at 4:11 PM, Mike Tutkowski
>>> <mike.tutkow...@solidfire.com> wrote:
>>> > These results look good:
>>> >
>>> > mtutkowski@ubuntu:~$ sudo cloudstack-setup-agent -m 192.168.233.1 -z 1
>>> -p 1
>>> > -c 1 -g 6b4aa1c2-2ac9-3c60-aabe-704aed40c684 -a --pubNic=cloudbr0
>>> > --prvNic=cloudbr0 --guestNic=cloudbr0
>>> > Starting to configure your system:
>>> > Configure Apparmor ... [OK]
>>> > Configure Network ... [OK]
>>> > Configure Libvirt ... [OK]
>>> > Configure Firewall ... [OK]
>>> > Configure Nfs ... [OK]
>>> > Configure cloudAgent ... [OK]
>>> > CloudStack Agent setup is done!
>>> >
>>> > However, these results are the same:
>>> >
>>> > mtutkowski@ubuntu:~$ ps -ef | grep jsvc
>>> > 1000 4314 3725 0 16:10 pts/1 00:00:00 grep --color=auto jsvc
>>> >
>>> >
>>> > On Wed, Sep 25, 2013 at 3:48 PM, Mike Tutkowski <
>>> > mike.tutkow...@solidfire.com> wrote:
>>> >
>>> >> This appears to be the offending method:
>>> >>
>>> >> public String parseCapabilitiesXML(String capXML) {
>>> >>
>>> >> if (!_initialized) {
>>> >>
>>> >> return null;
>>> >>
>>> >> }
>>> >>
>>> >> try {
>>> >>
>>> >> _sp.parse(new InputSource(new StringReader(capXML)), this);
>>> >>
>>> >> return _capXML.toString();
>>> >>
>>> >> } catch (SAXException se) {
>>> >>
>>> >> s_logger.warn(se.getMessage());
>>> >>
>>> >> } catch (IOException ie) {
>>> >>
>>> >> s_logger.error(ie.getMessage());
>>> >>
>>> >> }
>>> >>
>>> >> return null;
>>> >>
>>> >> }
>>> >>
>>> >>
>>> >> The logging I do from this method (not shown above), however, doesn't
>>> seem
>>> >> to end up in agent.log. Not sure why that is.
>>> >>
>>> >> We invoke this method and I log we're in this method as the first
>>> thing I
>>> >> do, but it doesn't show up in agent.log.
>>> >>
>>> >> The last message in agent.log is a line saying we are right before the
>>> >> call to this method.
>>> >>
>>> >>
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/solution/overview/?video=play>
>> *™*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
