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>
*™*

Reply via email to