In the past, prior to the addition to the CentOS init script that I
mentioned, I'd modify the init script to echo out the jsvc command it
was going to run, then I'd run that manually instead of the init. Then
I could see where it died.
On Wed, Sep 25, 2013 at 5:04 PM, Marcus Sorensen <shadow...@gmail.com> wrote:
> 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>
>> *™*
