[Add/Remove Network to VM] Multiple NICs on same Guest Network
Hi, Using addNicToVirtualMachine API user can add multiple NICs to a VM I am also able to add multiple NICs to a VM on the same isolated guest network. Is this a valid scenario?? If yes what could be the use case for the same? Thanks, Saksham
Re: Review Request: Fixed typos
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10441/#review19121 --- Ship it! Ship It! - Milamber ASF On April 13, 2013, 12:18 a.m., Pascal Borreli wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/10441/ > --- > > (Updated April 13, 2013, 12:18 a.m.) > > > Review request for cloudstack and Chip Childers. > > > Description > --- > > Fixed typos, some public class name, renamed some files, sensitive stuffs .. > > > Diffs > - > > api/src/com/cloud/vm/DiskProfile.java e34a334 > client/tomcatconf/applicationContext.xml.in 0d13877 > > engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/CommandResult.java > 6b6139b > > engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/ObjectInDataStoreStateMachine.java > 726ce08 > > engine/storage/imagemotion/src/org/apache/cloudstack/storage/image/motion/DefaultImageMotionStrategy.java > c49a521 > > engine/storage/integration-test/test/org/apache/cloudstack/storage/test/MockHypervisorHostEndPointRpcServer.java > PRE-CREATION > > engine/storage/integration-test/test/org/apache/cloudstack/storage/test/MockHypervsiorHostEndPointRpcServer.java > d698576 > engine/storage/integration-test/test/resource/component.xml 0368ad4 > > engine/storage/src/org/apache/cloudstack/storage/HypervisorHostEndPointRpcServer.java > PRE-CREATION > > engine/storage/src/org/apache/cloudstack/storage/HypervsiorHostEndPointRpcServer.java > f441f39 > > engine/storage/src/org/apache/cloudstack/storage/allocator/AbstractStoragePoolAllocator.java > 6334ca7 > > engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java > 7c6c946 > > engine/storage/src/org/apache/cloudstack/storage/datastore/DataObjectManagerImpl.java > 218f901 > > engine/storage/volume/src/org/apache/cloudstack/storage/datastore/driver/DefaultPrimaryDataStoreDriverImpl.java > 6d0c2c6 > > engine/storage/volume/src/org/apache/cloudstack/storage/datastore/provider/DefaultPrimaryDatastoreProviderImpl.java > 46fa738 > > engine/storage/volume/src/org/apache/cloudstack/storage/volume/TemplateInstallStrategyImpl.java > 5f1735c > plugins/network-elements/dns-notifier/resources/components-example.xml > 6493e74 > > plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/provider/CloudStackPrimaryDataStoreProviderImpl.java > 4d46d99 > server/src/com/cloud/network/ExteralIpAddressAllocator.java 2b78712 > server/src/com/cloud/network/ExternalIpAddressAllocator.java PRE-CREATION > server/src/com/cloud/network/IpAddrAllocator.java d79125b > server/src/com/cloud/template/TemplateManagerImpl.java 2892e00 > server/test/resources/network-mgr-component.xml 42d3c2e > utils/src/com/cloud/utils/component/ComponentContext.java 796d4ec > > Diff: https://reviews.apache.org/r/10441/diff/ > > > Testing > --- > > > Thanks, > > Pascal Borreli > >
Re: [Add/Remove Network to VM] Multiple NICs on same Guest Network
I believe it was allowed because one can also create multiple NICs on the same network while deploying a VM. There may be people doing that to get multiple IPS auto-assigned to a VM. On Apr 13, 2013 3:28 AM, "Saksham Srivastava" wrote: > Hi, > > Using addNicToVirtualMachine API user can add multiple NICs to a VM > > I am also able to add multiple NICs to a VM on the same isolated guest > network. > > Is this a valid scenario?? > If yes what could be the use case for the same? > > Thanks, > Saksham > >
Re: Review Request: Fix command for executing injectkeys.sh
This fixes an bug introduced in that commit. I also want to point out that line 669 in ConfigurationServerImpl.java traps exceptions thrown in development mode, hence this bug would not have surfaced when ran in development mode. This 669 line appears to have been committed months ago, removing it now results in not being able to find vms/injectkeys.sh on startup (which seems related to another thread about injectkeys.sh a few days ago). -Phong On Fri, Apr 12, 2013 at 6:50 PM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote: > Does this conflict with > 5cd3608 Remove the chmod solution and replace with an explicit call to > /bin/bash. This way the file will only need read permissions. > > > > On 4/12/13 2:11 PM, "Phong Nguyen" wrote: > > > > >--- > >This is an automatically generated e-mail. To reply, visit: > >https://reviews.apache.org/r/10437/ > >--- > > > >Review request for cloudstack and Hugo Trippaers. > > > > > >Description > >--- > > > >Management server unable to start (from rpm) due to invalid call to > >Script for injectkeys.sh. > > > >2013-04-12 15:02:13,496 WARN [cloud.server.ConfigurationServerImpl] > >(Timer-1:null) Failed to inject generated public key into systemvm iso > >java.io.IOException: Cannot run program "/bin/bash > >/usr/share/cloudstack-common/scripts/vm/systemvm/injectkeys.sh": error=2, > >No such file or directory > > at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) > > at com.cloud.utils.script.Script.execute(Script.java:183) > > > > > >Diffs > >- > > > > server/src/com/cloud/server/ConfigurationServerImpl.java 596387f > > > >Diff: https://reviews.apache.org/r/10437/diff/ > > > > > >Testing > >--- > > > >Rebuilt rpm and tested management server startup -- success > > > > > >Thanks, > > > >Phong Nguyen > > > >
Emergency: Cloud NOT starting
Greetings, I'm have a terrible way to go, nothing I have done will start my cloud. None of my system VM's will start, which in turn do not permit the regular OS VM's to start. I suffered from first a power outage, then I manually rebooted my server. Now, nothing is coming back online. I was previously told, having cloud0 first is the cause of this. Even when doing ifconfig cloud0 down, nothing seems to come back online. I have gone as far as stopping iptables / eatables along with stopping/starting the network and the management console. Checking the system VM's the continue to remain in a 'starting' status. [root@lunder ~]# service iptables status iptables: Firewall is not running. [root@lunder ~]# service ebtables status # Generated by ebtables-save v1.0 on Sat Apr 13 12:21:04 CDT 2013 *nat :PREROUTING ACCEPT :OUTPUT ACCEPT :POSTROUTING ACCEPT [root@lunder ~]# [root@lunder daoenix]# ifconfig cloud0Link encap:Ethernet HWaddr FE:00:A9:FE:00:67 inet addr:169.254.0.1 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:658 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:28068 (27.4 KiB) cloudbr0 Link encap:Ethernet HWaddr C8:0A:A9:9E:2D:7C inet addr:myipaddress Bcast:9myipaddress Mask:255.255.255.224 inet6 addr: fe80::fc2c:bcff:fe00:5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:192832 errors:0 dropped:0 overruns:0 frame:0 TX packets:11251 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11481135 (10.9 MiB) TX bytes:25153331 (23.9 MiB) eth0 Link encap:Ethernet HWaddr C8:0A:A9:9E:2D:7C inet6 addr: fe80::ca0a:a9ff:fe9e:2d7c/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:199794 errors:0 dropped:0 overruns:0 frame:0 TX packets:24157 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14647159 (13.9 MiB) TX bytes:25994485 (24.7 MiB) Memory:df6e-df70 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:7850808 errors:0 dropped:0 overruns:0 frame:0 TX packets:7850808 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1611132695 (1.5 GiB) TX bytes:1611132695 (1.5 GiB) virbr0Link encap:Ethernet HWaddr 52:54:00:D9:D9:9A inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) vnet0 Link encap:Ethernet HWaddr FE:00:A9:FE:00:67 inet6 addr: fe80::fc00:a9ff:fefe:67/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:116 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:5232 (5.1 KiB) vnet1 Link encap:Ethernet HWaddr FE:84:4C:00:00:01 inet6 addr: fe80::fc84:4cff:fe00:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:256 errors:0 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:17849 (17.4 KiB) vnet2 Link encap:Ethernet HWaddr FE:2C:BC:00:00:05 inet6 addr: fe80::fc2c:bcff:fe00:5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:256 errors:0 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:17849 (17.4 KiB) [root@lunder daoenix]#
Re: Emergency: Cloud NOT starting
Well you've got something trying to start, because you have vnet interfaces. You need to look at your agent logs to see why the system VMS refuse to start. If the power went out it could be corruption, the system VMS may be waiting for you to fsck. It sounds like maybe the system was put into production without testing to make sure the host settings were persistent and would survive a reboot? So 1) look at your agent logs. And 2) use vnc to look at whatever system VMS are running and see what state they are in. They will probably continually try to start and then shut down. On Apr 13, 2013 11:24 AM, "Maurice Lawler" wrote: > Greetings, > > I'm have a terrible way to go, nothing I have done will start my cloud. > None of my system VM's will start, which in turn do not permit the regular > OS VM's to start. I suffered from first a power outage, then I manually > rebooted my server. Now, nothing is coming back online. > > I was previously told, having cloud0 first is the cause of this. Even when > doing ifconfig cloud0 down, nothing seems to come back online. > > I have gone as far as stopping iptables / eatables along with > stopping/starting the network and the management console. > > > Checking the system VM's the continue to remain in a 'starting' status. > > [root@lunder ~]# service iptables status > iptables: Firewall is not running. > [root@lunder ~]# service ebtables status > # Generated by ebtables-save v1.0 on Sat Apr 13 12:21:04 CDT 2013 > *nat > :PREROUTING ACCEPT > :OUTPUT ACCEPT > :POSTROUTING ACCEPT > > [root@lunder ~]# > > > [root@lunder daoenix]# ifconfig > cloud0Link encap:Ethernet HWaddr FE:00:A9:FE:00:67 > inet addr:169.254.0.1 Bcast:169.254.255.255 Mask:255.255.0.0 > inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:658 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:28068 (27.4 KiB) > > cloudbr0 Link encap:Ethernet HWaddr C8:0A:A9:9E:2D:7C > inet addr:myipaddress Bcast:9myipaddress Mask:255.255.255.224 > inet6 addr: fe80::fc2c:bcff:fe00:5/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:192832 errors:0 dropped:0 overruns:0 frame:0 > TX packets:11251 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:11481135 (10.9 MiB) TX bytes:25153331 (23.9 MiB) > > eth0 Link encap:Ethernet HWaddr C8:0A:A9:9E:2D:7C > inet6 addr: fe80::ca0a:a9ff:fe9e:2d7c/64 Scope:Link > UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 > RX packets:199794 errors:0 dropped:0 overruns:0 frame:0 > TX packets:24157 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:14647159 (13.9 MiB) TX bytes:25994485 (24.7 MiB) > Memory:df6e-df70 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:7850808 errors:0 dropped:0 overruns:0 frame:0 > TX packets:7850808 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:1611132695 (1.5 GiB) TX bytes:1611132695 (1.5 GiB) > > virbr0Link encap:Ethernet HWaddr 52:54:00:D9:D9:9A > inet addr:192.168.122.1 Bcast:192.168.122.255 > Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > vnet0 Link encap:Ethernet HWaddr FE:00:A9:FE:00:67 > inet6 addr: fe80::fc00:a9ff:fefe:67/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:116 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 b) TX bytes:5232 (5.1 KiB) > > vnet1 Link encap:Ethernet HWaddr FE:84:4C:00:00:01 > inet6 addr: fe80::fc84:4cff:fe00:1/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:256 errors:0 dropped:0 overruns:1 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 b) TX bytes:17849 (17.4 KiB) > > vnet2 Link encap:Ethernet HWaddr FE:2C:BC:00:00:05 > inet6 addr: fe80::fc2c:bcff:fe00:5/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >
Re: Emergency: Cloud NOT starting
Now a new error shows: at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:432) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-04-13 12:29:33,067 WARN [cloud.api.ApiDispatcher] (Job-Executor-1:job-132) class com.cloud.api.ServerApiException : null 2013-04-13 12:29:33,068 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-1:job-132) Complete async job-132, jobStatus: 2, resultCode: 530, result: Error Code: 534 Error text: null 2013-04-13 12:29:34,382 DEBUG [cloud.cluster.ClusterManagerImpl] (Cluster-Heartbeat-1:null) Detected management node left, id:1, nodeIP:myipaddress 2013-04-13 12:29:34,382 INFO [cloud.cluster.ClusterManagerImpl] (Cluster-Heartbeat-1:null) Trying to connect to myipaddress 2013-04-13 12:29:34,382 INFO [cloud.cluster.ClusterManagerImpl] (Cluster-Heartbeat-1:null) Management node 1 is detected inactive by timestamp but is pingable On Apr 13, 2013, at 12:23 PM, Maurice Lawler wrote: > Greetings, > > I'm have a terrible way to go, nothing I have done will start my cloud. None > of my system VM's will start, which in turn do not permit the regular OS VM's > to start. I suffered from first a power outage, then I manually rebooted my > server. Now, nothing is coming back online. > > I was previously told, having cloud0 first is the cause of this. Even when > doing ifconfig cloud0 down, nothing seems to come back online. > > I have gone as far as stopping iptables / eatables along with > stopping/starting the network and the management console. > > > Checking the system VM's the continue to remain in a 'starting' status. > > [root@lunder ~]# service iptables status > iptables: Firewall is not running. > [root@lunder ~]# service ebtables status > # Generated by ebtables-save v1.0 on Sat Apr 13 12:21:04 CDT 2013 > *nat > :PREROUTING ACCEPT > :OUTPUT ACCEPT > :POSTROUTING ACCEPT > > [root@lunder ~]# > > > [root@lunder daoenix]# ifconfig > cloud0Link encap:Ethernet HWaddr FE:00:A9:FE:00:67 > inet addr:169.254.0.1 Bcast:169.254.255.255 Mask:255.255.0.0 > inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:658 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:28068 (27.4 KiB) > > cloudbr0 Link encap:Ethernet HWaddr C8:0A:A9:9E:2D:7C > inet addr:myipaddress Bcast:9myipaddress Mask:255.255.255.224 > inet6 addr: fe80::fc2c:bcff:fe00:5/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:192832 errors:0 dropped:0 overruns:0 frame:0 > TX packets:11251 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:11481135 (10.9 MiB) TX bytes:25153331 (23.9 MiB) > > eth0 Link encap:Ethernet HWaddr C8:0A:A9:9E:2D:7C > inet6 addr: fe80::ca0a:a9ff:fe9e:2d7c/64 Scope:Link > UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 > RX packets:199794 errors:0 dropped:0 overruns:0 frame:0 > TX packets:24157 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:14647159 (13.9 MiB) TX bytes:25994485 (24.7 MiB) > Memory:df6e-df70 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:7850808 errors:0 dropped:0 overruns:0 frame:0 > TX packets:7850808 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:1611132695 (1.5 GiB) TX bytes:1611132695 (1.5 GiB) > > virbr0Link encap:Ethernet HWaddr 52:54:00:D9:D9:9A > inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > vnet0 Link encap:Ethernet HWaddr FE:00:A9:FE:00:67 > inet6 addr: fe80::fc00:a9ff:fefe:67/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:116 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:
Re: Issue launching VM on VMware
looks as though your zone is set to use shared storage, and youre only providing local storage. 1. 2013-04-12 11:35:20,292 DEBUG [storage.allocator. AbstractStoragePoolAllocator] (Job-Executor-11:job-11) Checking if storage pool is suitable, name: devcloud Local Storage ,poolId: 200 2. 2013-04-12 11:35:20,292 DEBUG [storage.allocator. AbstractStoragePoolAllocator] (Job-Executor-11:job-11) Is localStorageAllocationNeeded? false 3. 2013-04-12 11:35:20,292 DEBUG [storage.allocator. AbstractStoragePoolAllocator] (Job-Executor-11:job-11) Is storage pool shared? false 4. 2013-04-12 11:35:20,292 DEBUG [storage.allocator. AbstractStoragePoolAllocator] (Job-Executor-11:job-11) StoragePool is not of correct type, skipping this pool On Fri, Apr 12, 2013 at 10:19 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Hi, > > Thanks for the comments. > > In my case, I am just running a Basic Zone that was originally set up with > DevCloud2. I added a Pod and a Cluster with two ESXi Hosts in the Cluster. > > I am able to create iSCSI-based VMFS Datastores and Primary Storages in CS > from them. > > However, when I try to execute a Compute Offering that is storage tagged to > only use Primary Storage that is based on one of my VMFS Datastores, I get > a failure message. > > I've attached the log here: > > http://paste.cloudstack.org/rst0/ > > Thanks!! > > > On Fri, Apr 12, 2013 at 2:49 PM, Musayev, Ilya wrote: > > > Mike, > > > > I've done many vmware install, I don't believe your issue is with VC > > running on the same hypervisor you are trying to manage - since one of my > > setups is doing just that. > > > > Also, while it maybe stated somewhere that you should dedicate this > > hypervisor to CS, CS does not know anything about other VMs it did not > > create. It maybe a best practice to dedicate your hypervisors, however, > its > > not a must requirement (please correct me if I'm wrong). > > > > Even when you place ESXi into maintenance mode in CS, it does not really > > take hypervisor into maintenance mode, it just evacuvates its VMs to > other > > hypervisors. > > > > Typical reasons for your problem: > > 1) you've changed "Management Network" port group > > 2) you are not using default vswitch0 > > (both of the above can be changed in settings) > > 3) you attempting to use DVS, not yet supported in 4.1, supported in 4.2 > > - I will release my version of ACS of 4.1 with DVS integrated as soon as > > 4.1 goes out. > > > > If none of the above are true, please submit a log through > > paste.cloudstack.org, the exception you've posted show the end result > > error - but not the original cause. > > > > Regards > > ilya > > > > > -Original Message- > > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > > > Sent: Friday, April 12, 2013 3:18 PM > > > To: dev@cloudstack.apache.org > > > Cc: cloudstack-...@incubator.apache.org > > > Subject: Re: Issue launching VM on VMware > > > > > > So, could this be the problem: > > > > > > In the interest of efficiency, I am running a virtual appliance with > > vCenter > > > inside of it on one of the two ESXi hosts I'm using in CloudStack. > > > > > > Technically we're not supposed to have any VMs running that we're not > > > started by CloudStack, right? > > > > > > Could this be what's causing my troubles? > > > > > > > > > On Fri, Apr 12, 2013 at 12:56 PM, Mike Tutkowski < > > > mike.tutkow...@solidfire.com> wrote: > > > > > > > Looks like it might be because no virtual router is running? > > > > > > > > 2013-04-12 12:50:27,994 DEBUG > > > > [network.router.VirtualNetworkApplianceManagerImpl] > > > > (RouterStatusMonitor-1:null) Found 0 routers to update status. > > > > 2013-04-12 12:50:27,995 DEBUG > > > > [network.router.VirtualNetworkApplianceManagerImpl] > > > > (RouterStatusMonitor-1:null) Found 0 networks to update RvR status. > > > > 2013-04-12 12:50:28,026 DEBUG > > > > [network.router.VirtualNetworkApplianceManagerImpl] > > > > (RouterStatusMonitor-1:null) Found 0 routers to update status. > > > > 2013-04-12 12:50:28,027 DEBUG > > > > [network.router.VirtualNetworkApplianceManagerImpl] > > > > (RouterStatusMonitor-1:null) Found 0 networks to update RvR status. > > > > > > > > My SSVM is running, but it looks like no virtual router is. > > > > > > > > > > > > On Fri, Apr 12, 2013 at 12:11 PM, Kelven Yang > > > wrote: > > > > > > > >> Look back from the exception in logs, this exception is the final > > > >> place that throws the failure exception, the actual reason may be > > > >> shown in logs earlier than this point. > > > >> Kelven > > > >> > > > >> On 4/12/13 10:46 AM, "Mike Tutkowski" > > > > >> wrote: > > > >> > > > >> >Same problem when I try to start the VM on the local storage of > > > >> >either of my ESXi hosts. > > > >> > > > > >> > > > > >> >On Fri, Apr 12, 2013 at 11:39 AM, Mike Tutkowski < > > > >> >mike.tutkow...@solidfire.com> wrote: > > > >> > > > > >> >> Hi, > > > >> >> > > > >> >> A
Re: Issue launching VM on VMware
That's weird...I have three local storages (one from DevCloud2 by default, one from one ESXi host, and one from another ESXi host). I also have several shared storages (iSCSI-based datastores that were configured in CS as VMFS-based primary storages). I tagged the shared primary storage I wanted to use, referenced that storage tag from a compute offering, and executed the compute offering. On Sat, Apr 13, 2013 at 12:30 PM, Ahmad Emneina wrote: > looks as though your zone is set to use shared storage, and youre only > providing local storage. > >1. 2013-04-12 11:35:20,292 DEBUG [storage.allocator. >AbstractStoragePoolAllocator] (Job-Executor-11:job-11) Checking if >storage pool is suitable, name: devcloud Local Storage ,poolId: 200 >2. 2013-04-12 11:35:20,292 DEBUG [storage.allocator. >AbstractStoragePoolAllocator] (Job-Executor-11:job-11) Is >localStorageAllocationNeeded? false >3. 2013-04-12 11:35:20,292 DEBUG [storage.allocator. >AbstractStoragePoolAllocator] (Job-Executor-11:job-11) Is storage pool >shared? false >4. 2013-04-12 11:35:20,292 DEBUG [storage.allocator. >AbstractStoragePoolAllocator] (Job-Executor-11:job-11) StoragePool is > not >of correct type, skipping this pool > > > > On Fri, Apr 12, 2013 at 10:19 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > > > Hi, > > > > Thanks for the comments. > > > > In my case, I am just running a Basic Zone that was originally set up > with > > DevCloud2. I added a Pod and a Cluster with two ESXi Hosts in the > Cluster. > > > > I am able to create iSCSI-based VMFS Datastores and Primary Storages in > CS > > from them. > > > > However, when I try to execute a Compute Offering that is storage tagged > to > > only use Primary Storage that is based on one of my VMFS Datastores, I > get > > a failure message. > > > > I've attached the log here: > > > > http://paste.cloudstack.org/rst0/ > > > > Thanks!! > > > > > > On Fri, Apr 12, 2013 at 2:49 PM, Musayev, Ilya > wrote: > > > > > Mike, > > > > > > I've done many vmware install, I don't believe your issue is with VC > > > running on the same hypervisor you are trying to manage - since one of > my > > > setups is doing just that. > > > > > > Also, while it maybe stated somewhere that you should dedicate this > > > hypervisor to CS, CS does not know anything about other VMs it did not > > > create. It maybe a best practice to dedicate your hypervisors, however, > > its > > > not a must requirement (please correct me if I'm wrong). > > > > > > Even when you place ESXi into maintenance mode in CS, it does not > really > > > take hypervisor into maintenance mode, it just evacuvates its VMs to > > other > > > hypervisors. > > > > > > Typical reasons for your problem: > > > 1) you've changed "Management Network" port group > > > 2) you are not using default vswitch0 > > > (both of the above can be changed in settings) > > > 3) you attempting to use DVS, not yet supported in 4.1, supported in > 4.2 > > > - I will release my version of ACS of 4.1 with DVS integrated as soon > as > > > 4.1 goes out. > > > > > > If none of the above are true, please submit a log through > > > paste.cloudstack.org, the exception you've posted show the end result > > > error - but not the original cause. > > > > > > Regards > > > ilya > > > > > > > -Original Message- > > > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > > > > Sent: Friday, April 12, 2013 3:18 PM > > > > To: dev@cloudstack.apache.org > > > > Cc: cloudstack-...@incubator.apache.org > > > > Subject: Re: Issue launching VM on VMware > > > > > > > > So, could this be the problem: > > > > > > > > In the interest of efficiency, I am running a virtual appliance with > > > vCenter > > > > inside of it on one of the two ESXi hosts I'm using in CloudStack. > > > > > > > > Technically we're not supposed to have any VMs running that we're not > > > > started by CloudStack, right? > > > > > > > > Could this be what's causing my troubles? > > > > > > > > > > > > On Fri, Apr 12, 2013 at 12:56 PM, Mike Tutkowski < > > > > mike.tutkow...@solidfire.com> wrote: > > > > > > > > > Looks like it might be because no virtual router is running? > > > > > > > > > > 2013-04-12 12:50:27,994 DEBUG > > > > > [network.router.VirtualNetworkApplianceManagerImpl] > > > > > (RouterStatusMonitor-1:null) Found 0 routers to update status. > > > > > 2013-04-12 12:50:27,995 DEBUG > > > > > [network.router.VirtualNetworkApplianceManagerImpl] > > > > > (RouterStatusMonitor-1:null) Found 0 networks to update RvR status. > > > > > 2013-04-12 12:50:28,026 DEBUG > > > > > [network.router.VirtualNetworkApplianceManagerImpl] > > > > > (RouterStatusMonitor-1:null) Found 0 routers to update status. > > > > > 2013-04-12 12:50:28,027 DEBUG > > > > > [network.router.VirtualNetworkApplianceManagerImpl] > > > > > (RouterStatusMonitor-1:null) Found 0 networks to update RvR status. > > > > > > > > > > My SSVM is running, but it looks like no
Re: [DISCUSS] Granular Global Parameters
Yes Nitin, we need some listener kind of model but for the parameters that are
proposed may not need dynamic update (may be it needed for storage cleanup
interval).
Please correct me if I'm wrong. Can't we proceed normally for the doable
parameters.
-Harikrishna
On 11-Apr-2013, at 12:15 PM, Nitin Mehta wrote:
> Mice - This is a great question and I had been wanting to ask the same as
> well. From the cloud admin perspective having more granular params makes a
> lot of sense in having a much finer control over his cloud, but I somehow
> feel that our global configs need some rework. There is a need to have a
> uniform listener model which can dynamically update these values in the in
> memory cache. Currently we just load these values during MS start time.
> Also for params which are thread based (like storage.cleanup interval) we
> would need to alter the frequency dynamically.
>
> On 11/04/13 10:27 AM, "Mice Xia" wrote:
>
>> If we make config parameters granular to zone/cluster/account.. level, do
>> we have to restart mgmt server to take it effect?
>> And it seems this involves a lot of change in codes, is it possible to
>> take this chance and improve global configs so that we can change global
>> config at runtime ( no need to restart mgmt server)?
>>
>> Regards
>> Mice
>>
>> -Original Message-
>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
>> Sent: Thursday, April 11, 2013 11:37 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] Granular Global Parameters
>>
>>
>>
>> On 10/04/13 6:30 PM, "David Nalley" wrote:
>>
>>> On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala
>>> wrote:
Hi all,
There are many global parameters which are used to set
values/limits/boolean for various operations, but these parameters
effects all zones/clusters/accounts/storage based on the parameter.
Here I would like to discuss on granulising these parameters so that
these parameters can be customised at different levels
(zone/cluster/account/storage).
New APIs are introduced to update these parameters based on the level
listed in the FS below.
During the creation of zone/cluster/account/storage default values
for the granular parameters are set from the normal global parameters
and later these can be updated using the corresponding API.
This proposal for Global granular parameters is detailed in the FS
here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Granular
+Gl
obal+Configuration+Parameters
The JIRA ticket for tracking is
https://issues.apache.org/jira/browse/CLOUDSTACK-741
Please review this and provide me comments/suggestions.
Thanks
Harikrishna
>>>
>>>
>>> Hi Harikrisha:
>>>
>>> First - the title is a bit confusing; granular and global seems
>>> contradictory. Regardless - this is a great move forward.
>>>
>>> I don't understand why we would inject a new API command
>>> (update{storage,cluster,zone,account}levelparamater) instead of just
>>> using updateZone, updateAccount, updateStoragePool, etc. For instance,
>>> I would expect that listZone would tell me the status of the zone-level
>>> options. So why wouldn't updateZone be capable of setting the options
>>
>>
>> Good question. Whether to overload an existing API or create a new one is
>> always debatable.
>> In this case one of the reason is that the existing update APIs were
>> returning a {Zone, Account,..}Response that is not required when you
>> change a granular config param. Moreover, all the existing update APIs
>> are already heavily overloaded, not a strong reason to avoid further
>> overloading though apart from that the response grows in size more you
>> overload.
>>
>> We will also need an API to query the config params at these various
>> granularities, that is not mentioned in the FS.
>>
>> -abhi
>>
>>
>>
>
Re: deployDataCenter.py doesn't work for me on master
Downloaded the vhd-util to my environment and had the same problem. I
Debugged this further by running the copy_vhd_from_secondarystorage.sh on
the XenServer. It looks like the copy_vhd_from_secondarystorage.sh is
looking for vhd-util in /opt/xensource/bin/ rather than /usr/bin/
I looked at this further and looks like what is built in the client/target
directory is not consistent with what is in the ./scripts/vm in my tree.
There are two versions of copy_vhd_from_secondarystorage.sh.
I removed the client/target directory and rebuilt, but had the same files
appear again. I am not sure how they are getting pulled in to the
client/target directory. Any ideas why my build is broken and how to
proceed to fix this?
For now I patched this on my XenServer and was able to get ssvm and
cproxyvm running and brought up my CloudStack zone completely.
-Soheil
Administrators-MacBook-Pro-7:cloudstack seizadi$ find . -name
copy_vhd_from_secondarystorage.sh
./client/target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/h
ypervisor/xenserver/copy_vhd_from_secondarystorage.sh
./client/target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/h
ypervisor/xenserver/xcposs/copy_vhd_from_secondarystorage.sh
./client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xens
erver/copy_vhd_from_secondarystorage.sh
./client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xens
erver/xcposs/copy_vhd_from_secondarystorage.sh
./scripts/vm/hypervisor/xenserver/copy_vhd_from_secondarystorage.sh
./scripts/vm/hypervisor/xenserver/xcposs/copy_vhd_from_secondarystorage.sh
Administrators-MacBook-Pro-7:cloudstack seizadi$ find . -name
copy_vhd_from_secondarystorage.sh -exec diff
./client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xens
erver/copy_vhd_from_secondarystorage.sh {} \;
92c92
< VHDUTIL="/opt/xensource/bin/vhd-util"
---
> VHDUTIL="/usr/bin/vhd-util"
113c113
< if [ $type != "nfs" -a $type != "ext" ]; then
---
> if [ $type != "nfs" -a $type != "ext" -a $type != "file" ]; then
143c143
< desvhd=/var/run/sr-mount/$sruuid/$uuid.vhd
---
> desvhd=/run/sr-mount/$sruuid/$uuid.vhd
160a161,166
> elif [ $type == "file" ]; then
> pbd=`xe sr-param-list uuid=$sruuid |grep PBDs | awk '{print $3}'`
> path=`xe pbd-param-list uuid=$pbd |grep device-config |awk '{print
>$4}'`
> desvhd=$path/$uuid.vhd
> copyvhd $desvhd $vhdfile 0 $type
>
92c92
< VHDUTIL="/opt/xensource/bin/vhd-util"
---
> VHDUTIL="/usr/bin/vhd-util"
113c113
< if [ $type != "nfs" -a $type != "ext" ]; then
---
> if [ $type != "nfs" -a $type != "ext" -a $type != "file" ]; then
143c143
< desvhd=/var/run/sr-mount/$sruuid/$uuid.vhd
---
> desvhd=/run/sr-mount/$sruuid/$uuid.vhd
160a161,166
> elif [ $type == "file" ]; then
> pbd=`xe sr-param-list uuid=$sruuid |grep PBDs | awk '{print $3}'`
> path=`xe pbd-param-list uuid=$pbd |grep device-config |awk '{print
>$4}'`
> desvhd=$path/$uuid.vhd
> copyvhd $desvhd $vhdfile 0 $type
>
Š.
[root@xenserver-devcloud /]# copy_vhd_from_secondarystorage.sh
172.16.197.134:/opt/storage/secondary/template/tmpl/1/1/
7e934fee-96b5-b297-2c25-b20a14139fd9 DEVTEST
/opt/xensource/bin/copy_vhd_from_secondarystorage.sh: line 133:
/opt/xensource/bin/vhd-util: No such file or directory
Error: Failed to parse field 'virtual-size': expecting an integer
(possibly with suffix)
9#can not create vdi in sr 7e934fee-96b5-b297-2c25-b20a14139fd9
[root@xenserver-devcloud /]# cp /usr/sbin/vhd-util
/opt/xensource/bin/vhd-util
[root@xenserver-devcloud /]# copy_vhd_from_secondarystorage.sh
172.16.197.134:/opt/storage/secondary/template/tmpl/1/1/
7e934fee-96b5-b297-2c25-b20a14139fd9 DEVTEST
1001+1 records in
1001+1 records out
2101252608 bytes (2.1 GB) copied, 178.662 seconds, 11.8 MB/s
0#c9cb5877-9434-4f3e-93b7-2f895cc62642
On 4/12/13 5:04 PM, "Chiradeep Vittal" wrote:
>Because of this
>http://s.apache.org/Nsd
>
>On 4/12/13 4:32 PM, "Soheil Eizadi" wrote:
>
>>That patch is about downloading vhd-util to XenServer.
>>
>>The XenServer (6.0.2) I am using already came bundled with vhd-util, I
>>did
>>not have to download it. I have not read the detail of
>>copy_vhd_from_secondarystorage.sh which throws the error to figure out
>>exactly why it is failing in my environment. I have used this same
>>XenServer image with Citrix Cloud Platform 3.0.6 distribution and it
>>worked fine (which is based on CloudStack 4.x as I understand.)
>>-Soheil
>>
>>[root@xenserver-devcloud /]# which vhd-util
>>/usr/sbin/vhd-util
>>
>>
>>[root@xenserver-devcloud /]# vhd-util read -p -n
>>/var/run/sr-mount/c375f445-5314-8c9b-bbc7-f60a84a65c6c/4a386682-6f7c-456a
>>-
>>8
>>76a-d6d07b1dc955.vhd
>>VHD Footer Summary:
>>---
>>Cookie : conectix
>>Features: (0x0002)
>>File format version : Major: 1, Minor: 0
>>Data offset : 512
>>Timestamp : Thu Apr 11 19:06:47 2013
>>Creator Application : 'tap'
>>Creator version : Major: 1, Minor: 3
>>Creator
Re: [DISCUSS] Granular Global Parameters
Hari,
Granularity of params and dynamic updates are two different issues. We
can file a enhance request for the dynamic updates and community can take
its development.
While granularity is what I think that is being considered currently.
On 14/04/13 11:22 AM, "Harikrishna Patnala"
wrote:
>Yes Nitin, we need some listener kind of model but for the parameters
>that are proposed may not need dynamic update (may be it needed for
>storage cleanup interval).
>Please correct me if I'm wrong. Can't we proceed normally for the doable
>parameters.
>
>-Harikrishna
>
>On 11-Apr-2013, at 12:15 PM, Nitin Mehta wrote:
>
>> Mice - This is a great question and I had been wanting to ask the same
>>as
>> well. From the cloud admin perspective having more granular params
>>makes a
>> lot of sense in having a much finer control over his cloud, but I
>>somehow
>> feel that our global configs need some rework. There is a need to have a
>> uniform listener model which can dynamically update these values in the
>>in
>> memory cache. Currently we just load these values during MS start time.
>> Also for params which are thread based (like storage.cleanup interval)
>>we
>> would need to alter the frequency dynamically.
>>
>> On 11/04/13 10:27 AM, "Mice Xia" wrote:
>>
>>> If we make config parameters granular to zone/cluster/account.. level,
>>>do
>>> we have to restart mgmt server to take it effect?
>>> And it seems this involves a lot of change in codes, is it possible to
>>> take this chance and improve global configs so that we can change
>>>global
>>> config at runtime ( no need to restart mgmt server)?
>>>
>>> Regards
>>> Mice
>>>
>>> -Original Message-
>>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
>>> Sent: Thursday, April 11, 2013 11:37 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [DISCUSS] Granular Global Parameters
>>>
>>>
>>>
>>> On 10/04/13 6:30 PM, "David Nalley" wrote:
>>>
On Wed, Apr 10, 2013 at 7:08 AM, Harikrishna Patnala
wrote:
> Hi all,
>
> There are many global parameters which are used to set
> values/limits/boolean for various operations, but these parameters
> effects all zones/clusters/accounts/storage based on the parameter.
> Here I would like to discuss on granulising these parameters so that
> these parameters can be customised at different levels
> (zone/cluster/account/storage).
> New APIs are introduced to update these parameters based on the level
> listed in the FS below.
> During the creation of zone/cluster/account/storage default values
> for the granular parameters are set from the normal global parameters
> and later these can be updated using the corresponding API.
>
>
> This proposal for Global granular parameters is detailed in the FS
> here:
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Granular
> +Gl
> obal+Configuration+Parameters
> The JIRA ticket for tracking is
> https://issues.apache.org/jira/browse/CLOUDSTACK-741
>
> Please review this and provide me comments/suggestions.
>
> Thanks
> Harikrishna
Hi Harikrisha:
First - the title is a bit confusing; granular and global seems
contradictory. Regardless - this is a great move forward.
I don't understand why we would inject a new API command
(update{storage,cluster,zone,account}levelparamater) instead of just
using updateZone, updateAccount, updateStoragePool, etc. For instance,
I would expect that listZone would tell me the status of the
zone-level
options. So why wouldn't updateZone be capable of setting the options
>>>
>>>
>>> Good question. Whether to overload an existing API or create a new one
>>>is
>>> always debatable.
>>> In this case one of the reason is that the existing update APIs were
>>> returning a {Zone, Account,..}Response that is not required when you
>>> change a granular config param. Moreover, all the existing update APIs
>>> are already heavily overloaded, not a strong reason to avoid further
>>> overloading though apart from that the response grows in size more you
>>> overload.
>>>
>>> We will also need an API to query the config params at these various
>>> granularities, that is not mentioned in the FS.
>>>
>>> -abhi
>>>
>>>
>>>
>>
>
