Looks like it's running, though: mtutkowski@ubuntu:~$ ps -ef | grep jsvc 1000 7097 7013 0 14:32 pts/1 00:00:00 grep --color=auto jsvc
On Mon, Sep 23, 2013 at 2:31 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Hey Marcus, > > Maybe you could give me a better idea of what the "flow" is when adding a > KVM host. > > It looks like we SSH into the potential KVM host and execute a startup > script (giving it necessary info about the cloud and the management server > it should talk to). > > After this, is the Java VM started? > > After a reboot, I assume the JVM is started automatically? > > How do you debug your KVM-side Java code? > > Been looking through the logs and nothing obvious sticks out. I will have > another look. > > Thanks > > > On Mon, Sep 23, 2013 at 2:15 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Hey Marcus, >> >> I've been investigating my issue with not being able to add a KVM host to >> CS. >> >> For what it's worth, this comes back successful: >> >> SSHCmdHelper.sshExecuteCmd(sshConnection, "cloudstack-setup-agent " + >> parameters, 3); >> >> This is what the command looks like: >> >> 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 >> >> The problem is this method in LibvirtServerDiscoverer never finds a >> matching host in the DB: >> >> waitForHostConnect(long dcId, long podId, long clusterId, String guid) >> >> I assume once the KVM host is up and running that it's supposed to call >> into the CS MS so the DB can be updated as such? >> >> If so, the problem must be on the KVM side. >> >> I did run this again (from the KVM host) to see if the connection was in >> place: >> >> mtutkowski@ubuntu:~$ telnet 192.168.233.1 8250 >> >> Trying 192.168.233.1... >> >> Connected to 192.168.233.1. >> >> Escape character is '^]'. >> So that looks good. >> >> I turned on more info in the debug log, but nothing obvious jumps out as >> of yet. >> >> If you have any thoughts on this, please shoot them my way. :) >> >> Thanks! >> >> >> On Sun, Sep 22, 2013 at 12:11 AM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >> >>> First step is for me to get this working for KVM, though. :) >>> >>> Once I do that, I can perhaps make modifications to the storage >>> framework and hypervisor plug-ins to refactor the logic and such. >>> >>> >>> On Sun, Sep 22, 2013 at 12:09 AM, Mike Tutkowski < >>> mike.tutkow...@solidfire.com> wrote: >>> >>>> Same would work for KVM. >>>> >>>> If CreateCommand and DestroyCommand were called at the appropriate >>>> times by the storage framework, I could move my connect and disconnect >>>> logic out of the attach/detach logic. >>>> >>>> >>>> On Sun, Sep 22, 2013 at 12:08 AM, Mike Tutkowski < >>>> mike.tutkow...@solidfire.com> wrote: >>>> >>>>> Conversely, if the storage framework called the DestroyCommand for >>>>> managed storage after the DetachCommand, then I could have had my remove >>>>> SR/datastore logic placed in the DestroyCommand handling rather than in >>>>> the >>>>> DetachCommand handling. >>>>> >>>>> >>>>> On Sun, Sep 22, 2013 at 12:06 AM, Mike Tutkowski < >>>>> mike.tutkow...@solidfire.com> wrote: >>>>> >>>>>> Edison's plug-in calls the CreateCommand. Mine does not. >>>>>> >>>>>> The initial approach that was discussed during 4.2 was for me to >>>>>> modify the attach/detach logic only in the XenServer and VMware >>>>>> hypervisor >>>>>> plug-ins. >>>>>> >>>>>> Now that I think about it more, though, I kind of would have liked to >>>>>> have the storage framework send a CreateCommand to the hypervisor before >>>>>> sending the AttachCommand if the storage in question was managed. >>>>>> >>>>>> Then I could have created my SR/datastore in the CreateCommand and >>>>>> the AttachCommand would have had the SR/datastore that it was always >>>>>> expecting (and I wouldn't have had to create the SR/datastore in the >>>>>> AttachCommand). >>>>>> >>>>>> >>>>>> On Sat, Sep 21, 2013 at 11:56 PM, Marcus Sorensen < >>>>>> shadow...@gmail.com> wrote: >>>>>> >>>>>>> Yeah, I think it probably is as well, but I figured you'd be in a >>>>>>> better position to tell. >>>>>>> >>>>>>> I see that copyAsync is unsupported in your current 4.2 driver, does >>>>>>> that mean that there's no template support? Or is it some other call >>>>>>> that does templating now? I'm still getting up to speed on all of the >>>>>>> 4.2 changes. I was just looking at CreateCommand in >>>>>>> LibvirtComputingResource, since that's the only place >>>>>>> createPhysicalDisk is called, and it occurred to me that >>>>>>> CreateCommand >>>>>>> might be skipped altogether when utilizing storage plugins. >>>>>>> >>>>>>> On Sat, Sep 21, 2013 at 11:38 PM, Mike Tutkowski >>>>>>> <mike.tutkow...@solidfire.com> wrote: >>>>>>> > That's an interesting comment, Marcus. >>>>>>> > >>>>>>> > It was my intent that it should work with any CloudStack "managed" >>>>>>> storage >>>>>>> > that uses an iSCSI target. Even though I'm using CHAP, I wrote the >>>>>>> code so >>>>>>> > CHAP didn't have to be used. >>>>>>> > >>>>>>> > As I'm doing my testing, I can try to think about whether it is >>>>>>> generic >>>>>>> > enough to keep those names or not. >>>>>>> > >>>>>>> > My expectation is that it is generic enough. >>>>>>> > >>>>>>> > >>>>>>> > On Sat, Sep 21, 2013 at 11:32 PM, Marcus Sorensen < >>>>>>> shadow...@gmail.com>wrote: >>>>>>> > >>>>>>> >> I added a comment to your diff. In general I think it looks good, >>>>>>> >> though I obviously can't vouch for whether or not it will work. >>>>>>> One >>>>>>> >> thing I do have reservations about is the adaptor/pool naming. If >>>>>>> you >>>>>>> >> think the code is generic enough that it will work for anyone who >>>>>>> does >>>>>>> >> an iscsi LUN-per-volume plugin, then it's OK, but if there's >>>>>>> anything >>>>>>> >> about it that's specific to YOUR iscsi target or how it likes to >>>>>>> be >>>>>>> >> treated then I'd say that they should be named something less >>>>>>> generic >>>>>>> >> than iScsiAdmStorage. >>>>>>> >> >>>>>>> >> On Sat, Sep 21, 2013 at 7:23 PM, Mike Tutkowski >>>>>>> >> <mike.tutkow...@solidfire.com> wrote: >>>>>>> >> > Great - thanks! >>>>>>> >> > >>>>>>> >> > Just to give you an overview of what my code does (for when you >>>>>>> get a >>>>>>> >> > chance to review it): >>>>>>> >> > >>>>>>> >> > SolidFireHostListener is registered in >>>>>>> SolidfirePrimaryDataStoreProvider. >>>>>>> >> > Its hostConnect method is invoked when a host connects with the >>>>>>> CS MS. If >>>>>>> >> > the host is running KVM, the listener sends a >>>>>>> ModifyStoragePoolCommand to >>>>>>> >> > the host. This logic was based off of DefaultHostListener. >>>>>>> >> > >>>>>>> >> > The handling of ModifyStoragePoolCommand is unchanged. It >>>>>>> invokes >>>>>>> >> > createStoragePool on the KVMStoragePoolManager. The >>>>>>> KVMStoragePoolManager >>>>>>> >> > asks for an adaptor and finds my new one: >>>>>>> iScsiAdmStorageAdaptor (which >>>>>>> >> was >>>>>>> >> > registered in the constructor for KVMStoragePoolManager under >>>>>>> the key of >>>>>>> >> > StoragePoolType.Iscsi.toString()). >>>>>>> >> > >>>>>>> >> > iScsiAdmStorageAdaptor.createStoragePool just makes an instance >>>>>>> of >>>>>>> >> > iScsiAdmStoragePool, adds it to a map, and returns the pointer >>>>>>> to the >>>>>>> >> > iScsiAdmStoragePool object. The key of the map is the UUID of >>>>>>> the storage >>>>>>> >> > pool. >>>>>>> >> > >>>>>>> >> > When a volume is attached, createPhysicalDisk is invoked for >>>>>>> managed >>>>>>> >> > storage rather than getPhysicalDisk. createPhysicalDisk uses >>>>>>> iscsiadm to >>>>>>> >> > establish the iSCSI connection to the volume on the SAN and a >>>>>>> >> > KVMPhysicalDisk is returned to be used in the attach logic that >>>>>>> follows. >>>>>>> >> > >>>>>>> >> > When a volume is detached, getPhysicalDisk is invoked with the >>>>>>> IQN of the >>>>>>> >> > volume if the storage pool in question is managed storage. >>>>>>> Otherwise, the >>>>>>> >> > normal vol.getPath() is used. >>>>>>> iScsiAdmStorageAdaptor.getPhysicalDisk just >>>>>>> >> > returns a new instance of KVMPhysicalDisk to be used in the >>>>>>> detach logic. >>>>>>> >> > >>>>>>> >> > Once the volume has been detached, >>>>>>> iScsiAdmStoragePool.deletePhysicalDisk >>>>>>> >> > is invoked if the storage pool is managed. deletePhysicalDisk >>>>>>> removes the >>>>>>> >> > iSCSI connection to the volume using iscsiadm. >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > On Sat, Sep 21, 2013 at 5:46 PM, Marcus Sorensen < >>>>>>> shadow...@gmail.com >>>>>>> >> >wrote: >>>>>>> >> > >>>>>>> >> >> Its the log4j properties file in /etc/cloudstack/agent change >>>>>>> all INFO >>>>>>> >> to >>>>>>> >> >> DEBUG. I imagine the agent just isn't starting, you can tail >>>>>>> the log >>>>>>> >> when >>>>>>> >> >> you try to start the service, or maybe it will spit something >>>>>>> out into >>>>>>> >> one >>>>>>> >> >> of the other files in /var/log/cloudstack/agent >>>>>>> >> >> On Sep 21, 2013 5:19 PM, "Mike Tutkowski" < >>>>>>> mike.tutkow...@solidfire.com >>>>>>> >> > >>>>>>> >> >> wrote: >>>>>>> >> >> >>>>>>> >> >> > This is how I've been trying to query for the status of the >>>>>>> service (I >>>>>>> >> >> > assume it could be started this way, as well, by changing >>>>>>> "status" to >>>>>>> >> >> > "start" or "restart"?): >>>>>>> >> >> > >>>>>>> >> >> > mtutkowski@ubuntu:/etc/cloudstack/agent$ sudo >>>>>>> /usr/sbin/service >>>>>>> >> >> > cloudstack-agent status >>>>>>> >> >> > >>>>>>> >> >> > I get this back: >>>>>>> >> >> > >>>>>>> >> >> > Failed to execute: * could not access PID file for >>>>>>> cloudstack-agent >>>>>>> >> >> > >>>>>>> >> >> > I've made a bunch of code changes recently, though, so I >>>>>>> think I'm >>>>>>> >> going >>>>>>> >> >> to >>>>>>> >> >> > rebuild and redeploy everything. >>>>>>> >> >> > >>>>>>> >> >> > The debug info sounds helpful. Where can I set enable.debug? >>>>>>> >> >> > >>>>>>> >> >> > Thanks, Marcus! >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> >> >> > On Sat, Sep 21, 2013 at 4:11 PM, Marcus Sorensen < >>>>>>> shadow...@gmail.com >>>>>>> >> >> > >wrote: >>>>>>> >> >> > >>>>>>> >> >> > > OK, will check it out in the next few days. As mentioned, >>>>>>> you can >>>>>>> >> set >>>>>>> >> >> up >>>>>>> >> >> > > your Ubuntu vm as the management server as well if all >>>>>>> else fails. >>>>>>> >> If >>>>>>> >> >> > you >>>>>>> >> >> > > can get to the mgmt server on 8250 from the KVM host, then >>>>>>> you need >>>>>>> >> to >>>>>>> >> >> > > enable.debug on the agent. It won't run without >>>>>>> complaining loudly >>>>>>> >> if >>>>>>> >> >> it >>>>>>> >> >> > > can't get to the mgmt server, and I didn't see that in >>>>>>> your agent >>>>>>> >> log, >>>>>>> >> >> so >>>>>>> >> >> > > perhaps its not running. I assume you know how to >>>>>>> stop/start the >>>>>>> >> agent >>>>>>> >> >> on >>>>>>> >> >> > > KVM via 'service cloud stacks agent'. >>>>>>> >> >> > > On Sep 21, 2013 3:02 PM, "Mike Tutkowski" < >>>>>>> >> >> mike.tutkow...@solidfire.com> >>>>>>> >> >> > > wrote: >>>>>>> >> >> > > >>>>>>> >> >> > > > Hey Marcus, >>>>>>> >> >> > > > >>>>>>> >> >> > > > I haven't yet been able to test my new code, but I >>>>>>> thought you >>>>>>> >> would >>>>>>> >> >> > be a >>>>>>> >> >> > > > good person to ask to review it: >>>>>>> >> >> > > > >>>>>>> >> >> > > > >>>>>>> >> >> > > > >>>>>>> >> >> > > >>>>>>> >> >> > >>>>>>> >> >> >>>>>>> >> >>>>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/ea74b312a8a36801994500407fd54f0cdda55e37 >>>>>>> >> >> > > > >>>>>>> >> >> > > > All it is supposed to do is attach and detach a data >>>>>>> disk (that >>>>>>> >> has >>>>>>> >> >> > > > guaranteed IOPS) with KVM as the hypervisor. The data >>>>>>> disk >>>>>>> >> happens to >>>>>>> >> >> > be >>>>>>> >> >> > > > from SolidFire-backed storage - where we have a 1:1 >>>>>>> mapping >>>>>>> >> between a >>>>>>> >> >> > > > CloudStack volume and a data disk. >>>>>>> >> >> > > > >>>>>>> >> >> > > > There is no support for hypervisor snapshots or stuff >>>>>>> like that >>>>>>> >> >> > (likely a >>>>>>> >> >> > > > future release)...just attaching and detaching a data >>>>>>> disk in 4.3. >>>>>>> >> >> > > > >>>>>>> >> >> > > > Thanks! >>>>>>> >> >> > > > >>>>>>> >> >> > > > >>>>>>> >> >> > > > On Fri, Sep 20, 2013 at 11:05 PM, Mike Tutkowski < >>>>>>> >> >> > > > mike.tutkow...@solidfire.com> wrote: >>>>>>> >> >> > > > >>>>>>> >> >> > > > > When I re-deployed the DEBs, I didn't remove >>>>>>> cloudstack-agent >>>>>>> >> >> first. >>>>>>> >> >> > > > Would >>>>>>> >> >> > > > > that be a problem? I just did a sudo apt-get install >>>>>>> >> >> > cloudstack-agent. >>>>>>> >> >> > > > > >>>>>>> >> >> > > > > >>>>>>> >> >> > > > > On Fri, Sep 20, 2013 at 11:03 PM, Mike Tutkowski < >>>>>>> >> >> > > > > mike.tutkow...@solidfire.com> wrote: >>>>>>> >> >> > > > > >>>>>>> >> >> > > > >> I get the same error running the command manually: >>>>>>> >> >> > > > >> >>>>>>> >> >> > > > >> mtutkowski@ubuntu:/etc/cloudstack/agent$ sudo >>>>>>> >> /usr/sbin/service >>>>>>> >> >> > > > >> cloudstack-agent status >>>>>>> >> >> > > > >> * could not access PID file for cloudstack-agent >>>>>>> >> >> > > > >> >>>>>>> >> >> > > > >> >>>>>>> >> >> > > > >> On Fri, Sep 20, 2013 at 11:00 PM, Mike Tutkowski < >>>>>>> >> >> > > > >> mike.tutkow...@solidfire.com> wrote: >>>>>>> >> >> > > > >> >>>>>>> >> >> > > > >>> agent.log looks OK to me: >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>> 2013-09-20 19:35:39,010 INFO >>>>>>> [cloud.agent.AgentShell] >>>>>>> >> >> (main:null) >>>>>>> >> >> > > > Agent >>>>>>> >> >> > > > >>> started >>>>>>> >> >> > > > >>> 2013-09-20 19:35:39,011 INFO >>>>>>> [cloud.agent.AgentShell] >>>>>>> >> >> (main:null) >>>>>>> >> >> > > > >>> Implementation Version is 4.3.0-SNAPSHOT >>>>>>> >> >> > > > >>> 2013-09-20 19:35:39,015 INFO >>>>>>> [cloud.agent.AgentShell] >>>>>>> >> >> (main:null) >>>>>>> >> >> > > > >>> agent.properties found at >>>>>>> >> /etc/cloudstack/agent/agent.properties >>>>>>> >> >> > > > >>> 2013-09-20 19:35:39,023 INFO >>>>>>> [cloud.agent.AgentShell] >>>>>>> >> >> (main:null) >>>>>>> >> >> > > > >>> Defaulting to using properties file for storage >>>>>>> >> >> > > > >>> 2013-09-20 19:35:39,024 INFO >>>>>>> [cloud.agent.AgentShell] >>>>>>> >> >> (main:null) >>>>>>> >> >> > > > >>> Defaulting to the constant time backoff algorithm >>>>>>> >> >> > > > >>> 2013-09-20 19:35:39,029 INFO [cloud.utils.LogUtils] >>>>>>> >> (main:null) >>>>>>> >> >> > > log4j >>>>>>> >> >> > > > >>> configuration found at >>>>>>> /etc/cloudstack/agent/log4j-cloud.xml >>>>>>> >> >> > > > >>> 2013-09-20 19:35:39,163 INFO [cloud.agent.Agent] >>>>>>> (main:null) >>>>>>> >> id >>>>>>> >> >> > is 3 >>>>>>> >> >> > > > >>> 2013-09-20 19:35:39,197 INFO >>>>>>> >> >> > > > >>> [resource.virtualnetwork.VirtualRoutingResource] >>>>>>> (main:null) >>>>>>> >> >> > > > >>> VirtualRoutingResource _scriptDir to use: >>>>>>> >> >> scripts/network/domr/kvm >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>> However, I wasn't aware that setup.log was >>>>>>> important. This >>>>>>> >> seems >>>>>>> >> >> to >>>>>>> >> >> > > be >>>>>>> >> >> > > > a >>>>>>> >> >> > > > >>> problem, but I'm not sure what it might indicate: >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>> DEBUG:root:execute:sudo /usr/sbin/service >>>>>>> cloudstack-agent >>>>>>> >> status >>>>>>> >> >> > > > >>> DEBUG:root:Failed to execute: * could not access PID >>>>>>> file for >>>>>>> >> >> > > > >>> cloudstack-agent >>>>>>> >> >> > > > >>> DEBUG:root:execute:sudo /usr/sbin/service >>>>>>> cloudstack-agent >>>>>>> >> start >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>> On Fri, Sep 20, 2013 at 10:53 PM, Marcus Sorensen < >>>>>>> >> >> > > shadow...@gmail.com >>>>>>> >> >> > > > >wrote: >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>>> Sorry, I saw that in the log, I thought it was the >>>>>>> agent log >>>>>>> >> for >>>>>>> >> >> > > some >>>>>>> >> >> > > > >>>> reason. Is the agent started? That might be the >>>>>>> place to >>>>>>> >> look. >>>>>>> >> >> > There >>>>>>> >> >> > > > is >>>>>>> >> >> > > > >>>> an >>>>>>> >> >> > > > >>>> agent log for the agent and one for the setup when >>>>>>> it adds >>>>>>> >> the >>>>>>> >> >> > host, >>>>>>> >> >> > > > >>>> both >>>>>>> >> >> > > > >>>> in /var/log >>>>>>> >> >> > > > >>>> On Sep 20, 2013 10:42 PM, "Mike Tutkowski" < >>>>>>> >> >> > > > >>>> mike.tutkow...@solidfire.com> >>>>>>> >> >> > > > >>>> wrote: >>>>>>> >> >> > > > >>>> >>>>>>> >> >> > > > >>>> > Is it saying that the MS is at the IP address or >>>>>>> the KVM >>>>>>> >> host? >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> > The KVM host is at 192.168.233.10. >>>>>>> >> >> > > > >>>> > The MS host is at 192.168.233.1. >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> > I see this for my host Global Settings parameter: >>>>>>> >> >> > > > >>>> > hostThe ip address of management >>>>>>> server192.168.233.1 >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> > /etc/cloudstack/agent/agent.properties has a >>>>>>> >> >> host=192.168.233.1 >>>>>>> >> >> > > > value. >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> > On Fri, Sep 20, 2013 at 10:21 PM, Marcus Sorensen >>>>>>> < >>>>>>> >> >> > > > >>>> shadow...@gmail.com >>>>>>> >> >> > > > >>>> > >wrote: >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> > > The log says your mgmt server is >>>>>>> 192.168.233.10? But you >>>>>>> >> >> tried >>>>>>> >> >> > > to >>>>>>> >> >> > > > >>>> telnet >>>>>>> >> >> > > > >>>> > to >>>>>>> >> >> > > > >>>> > > 192.168.233.1? It might be enough to change >>>>>>> that in >>>>>>> >> >> > > > >>>> > > /etc/cloudstack/agent/agent.properties, but you >>>>>>> may want >>>>>>> >> to >>>>>>> >> >> > edit >>>>>>> >> >> > > > the >>>>>>> >> >> > > > >>>> > config >>>>>>> >> >> > > > >>>> > > as well to tell it the real ms IP. >>>>>>> >> >> > > > >>>> > > On Sep 20, 2013 10:12 PM, "Mike Tutkowski" < >>>>>>> >> >> > > > >>>> mike.tutkow...@solidfire.com >>>>>>> >> >> > > > >>>> > > >>>>>>> >> >> > > > >>>> > > wrote: >>>>>>> >> >> > > > >>>> > > >>>>>>> >> >> > > > >>>> > > > Here's what my /etc/network/interfaces file >>>>>>> looks >>>>>>> >> like, if >>>>>>> >> >> > > that >>>>>>> >> >> > > > >>>> is of >>>>>>> >> >> > > > >>>> > > > interest (the 192.168.233.0 network is the >>>>>>> NAT network >>>>>>> >> >> > VMware >>>>>>> >> >> > > > >>>> Fusion >>>>>>> >> >> > > > >>>> > set >>>>>>> >> >> > > > >>>> > > > up): >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > auto lo >>>>>>> >> >> > > > >>>> > > > iface lo inet loopback >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > auto eth0 >>>>>>> >> >> > > > >>>> > > > iface eth0 inet manual >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > auto cloudbr0 >>>>>>> >> >> > > > >>>> > > > iface cloudbr0 inet static >>>>>>> >> >> > > > >>>> > > > address 192.168.233.10 >>>>>>> >> >> > > > >>>> > > > netmask 255.255.255.0 >>>>>>> >> >> > > > >>>> > > > network 192.168.233.0 >>>>>>> >> >> > > > >>>> > > > broadcast 192.168.233.255 >>>>>>> >> >> > > > >>>> > > > dns-nameservers 8.8.8.8 >>>>>>> >> >> > > > >>>> > > > bridge_ports eth0 >>>>>>> >> >> > > > >>>> > > > bridge_fd 5 >>>>>>> >> >> > > > >>>> > > > bridge_stp off >>>>>>> >> >> > > > >>>> > > > bridge_maxwait 1 >>>>>>> >> >> > > > >>>> > > > post-up route add default gw >>>>>>> 192.168.233.2 metric 1 >>>>>>> >> >> > > > >>>> > > > pre-down route del default gw >>>>>>> 192.168.233.2 >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > On Fri, Sep 20, 2013 at 10:08 PM, Mike >>>>>>> Tutkowski < >>>>>>> >> >> > > > >>>> > > > mike.tutkow...@solidfire.com> wrote: >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > > You appear to be correct. This is from the >>>>>>> MS log >>>>>>> >> >> (below). >>>>>>> >> >> > > > >>>> Discovery >>>>>>> >> >> > > > >>>> > > > timed >>>>>>> >> >> > > > >>>> > > > > out. >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > > I'm not sure why this would be. My network >>>>>>> settings >>>>>>> >> >> > > shouldn't >>>>>>> >> >> > > > >>>> have >>>>>>> >> >> > > > >>>> > > > changed >>>>>>> >> >> > > > >>>> > > > > since the last time I tried this. >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > > I am able to ping the KVM host from the MS >>>>>>> host and >>>>>>> >> vice >>>>>>> >> >> > > > versa. >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > > I'm even able to manually kick off a VM on >>>>>>> the KVM >>>>>>> >> host >>>>>>> >> >> > and >>>>>>> >> >> > > > >>>> ping from >>>>>>> >> >> > > > >>>> > > it >>>>>>> >> >> > > > >>>> > > > > to the MS host. >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > > I am using NAT from my Mac OS X host (also >>>>>>> running >>>>>>> >> the >>>>>>> >> >> CS >>>>>>> >> >> > > MS) >>>>>>> >> >> > > > >>>> to the >>>>>>> >> >> > > > >>>> > VM >>>>>>> >> >> > > > >>>> > > > > running KVM (VMware Fusion). >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > > 2013-09-20 19:40:40,141 DEBUG >>>>>>> >> >> > > > >>>> [c.c.h.k.d.LibvirtServerDiscoverer] >>>>>>> >> >> > > > >>>> > > > > (613487991@qtp-1659933291-3:ctx-6b28dc48) >>>>>>> Timeout, >>>>>>> >> to >>>>>>> >> >> > wait >>>>>>> >> >> > > > for >>>>>>> >> >> > > > >>>> the >>>>>>> >> >> > > > >>>> > > host >>>>>>> >> >> > > > >>>> > > > > connecting to mgt svr, assuming it is failed >>>>>>> >> >> > > > >>>> > > > > 2013-09-20 19:40:40,144 WARN >>>>>>> >> >> [c.c.r.ResourceManagerImpl] >>>>>>> >> >> > > > >>>> > > > > (613487991@qtp-1659933291-3:ctx-6b28dc48) >>>>>>> Unable to >>>>>>> >> >> find >>>>>>> >> >> > > the >>>>>>> >> >> > > > >>>> server >>>>>>> >> >> > > > >>>> > > > > resources at http://192.168.233.10 >>>>>>> >> >> > > > >>>> > > > > 2013-09-20 19:40:40,145 INFO >>>>>>> >> >> > [c.c.u.e.CSExceptionErrorCode] >>>>>>> >> >> > > > >>>> > > > > (613487991@qtp-1659933291-3:ctx-6b28dc48) >>>>>>> Could not >>>>>>> >> >> find >>>>>>> >> >> > > > >>>> exception: >>>>>>> >> >> > > > >>>> > > > > com.cloud.exception.DiscoveryException in >>>>>>> error code >>>>>>> >> >> list >>>>>>> >> >> > > for >>>>>>> >> >> > > > >>>> > > exceptions >>>>>>> >> >> > > > >>>> > > > > 2013-09-20 19:40:40,147 WARN >>>>>>> >> [o.a.c.a.c.a.h.AddHostCmd] >>>>>>> >> >> > > > >>>> > > > > (613487991@qtp-1659933291-3:ctx-6b28dc48) >>>>>>> Exception: >>>>>>> >> >> > > > >>>> > > > > com.cloud.exception.DiscoveryException: >>>>>>> Unable to add >>>>>>> >> >> the >>>>>>> >> >> > > host >>>>>>> >> >> > > > >>>> > > > > at >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> >>>>>>> >> >> > > > >>>>>>> >> >> > > >>>>>>> >> >> > >>>>>>> >> >> >>>>>>> >> >>>>>>> com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:778) >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > > I do seem to be able to telnet in from my >>>>>>> KVM host to >>>>>>> >> >> the >>>>>>> >> >> > MS >>>>>>> >> >> > > > >>>> host's >>>>>>> >> >> > > > >>>> > > 8250 >>>>>>> >> >> > > > >>>> > > > > port: >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > > mtutkowski@ubuntu:~$ telnet 192.168.233.1 >>>>>>> 8250 >>>>>>> >> >> > > > >>>> > > > > Trying 192.168.233.1... >>>>>>> >> >> > > > >>>> > > > > Connected to 192.168.233.1. >>>>>>> >> >> > > > >>>> > > > > Escape character is '^]'. >>>>>>> >> >> > > > >>>> > > > > >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > >>>>>>> >> >> > > > >>>> > > > -- >>>>>>> >> >> > > > >>>> > > > *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> >>>>>>> >> >> > > > >>>> > *™* >>>>>>> >> >> > > > >>>> > >>>>>>> >> >> > > > >>>> >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>> >>>>>>> >> >> > > > >>> -- >>>>>>> >> >> > > > >>> *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> >>>>>>> >> >> > > > >> *™* >>>>>>> >> >> > > > >> >>>>>>> >> >> > > > > >>>>>>> >> >> > > > > >>>>>>> >> >> > > > > >>>>>>> >> >> > > > > -- >>>>>>> >> >> > > > > *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 >>>>>>> > >>>>>>> >> >> > > > *™* >>>>>>> >> >> > > > >>>>>>> >> >> > > >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> >> >> > -- >>>>>>> >> >> > *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> >>>>>>> >> > *™* >>>>>>> >> >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > *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> >>>>>> *™* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *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> >>>> *™* >>>> >>> >>> >>> >>> -- >>> *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> >> *™* >> > > > > -- > *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> *™*
