[jira] [Assigned] (CLOUDSTACK-235) Network rate can be set in 2 places. Clarify docs on how this works.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair reassigned CLOUDSTACK-235: --- Assignee: Radhika Nair Network rate can be set in 2 places. Clarify docs on how this works. Key: CLOUDSTACK-235 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-235 Project: CloudStack Issue Type: Improvement Components: Doc Affects Versions: 4.0.0 Reporter: Jessica Tomechak Assignee: Radhika Nair Priority: Minor Fix For: 4.1.0 What is the purpose of the two Network Rates. There is one in Compute Offerings and one in Network Offerings. How does each apply in basic advanced networking? (Michael Simos) (Kirk Kosinski:) With vSphere, the actual limits vary depending on: 1. Where they are configured (compute and/or network offering) 2. The network type (shared or isolated) 3. The traffic direction (ingress or egress) I'd assume that a basic zone would work like a shared network in an advanced zone, but if not, add that to the list above. However, it may function differently in XenServer, so hypervisor might also need to be on the list (and even if XenServer and vSphere function the same, KVM doesn't support limits at all). Also, it is probably different in vSphere with Nexus 1000V since (I think) ingress traffic can be limited (a regular dvSwitch can limit ingress/egress, and I think the Nexus 1000V is considered a dvSwitch... but I only tested with regular vSwitches, which can only limit egress)... so...vSwitch type may need to be on that list. Network Rate can be configured on either the Network Offering or Compute Offering, on both of them simultaneously, or on neither of them. The resulting behavior in vSphere is complicated. However, I will try to explain. The Network Rate for a Network Offering used by a particular network in CloudStack will be used for the traffic shaping policy of a port group for that network (i.e. a particular subnet/VLAN on the actual network). Virtual routers for that network will connect to this port group, and by default instances in that network will connect to this port group. However, if an instance is deployed with a Compute Offering with a Network Rate, this rate will be used for the traffic shaping policy of another port group for the network, and instances using the offering will be connected to this port group instead. Traffic shaping on standard port groups in vSphere only applies to egress traffic and the net effect depends on the type of network in CloudStack. For shared networks, ingress traffic is unlimited as far as CloudStack is concerned, and egress traffic is limited to the rate that applies to the port group used by the instance (if any). If the Compute Offering has a Network Rate configured, this rate will apply to egress traffic, otherwise the Network Rate of the Network Offering will apply. For isolated networks, the Network Rate for the Network Offering (if any) will effectively apply to ingress traffic (since it applies to egress traffic from the virtual router to the instance), and egress traffic is limited to the rate that applies to the port group used by the instance (if any), similar to shared networks. So for example: Network Rate of Network Offering = 10 Mb/s Network Rate of Compute Offering = 200 Mb/s In a shared network, ingress traffic will not be limited as far as CloudStack is concerned, while egress traffic will be limited to 200 Mb/s. In an isolated network, ingress traffic will be limited to 10 Mb/s and egress to 200 Mb/s. (Kirk Kosinski) See: http://docs.cloudstack.org/Knowledge_Base/Network_Throttling. We have confirmed the current code behaves as documented here (Murali Reddy) It is different in vSphere with Nexus 1000V since ingress traffic can be limited, as well as egress traffic. (Sateesh Chodapuneedi) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Review Request: Snapshot errors with multiple secondary storage in one zone.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7594/ --- Review request for cloudstack, Nitin Mehta and anthony xu. Description --- Fixed CS-16263 The issue is happening because of the multiple secondary storages, the secondary storage which is used first is getting mounted on the host resulting in failure of other snapshot using different secondary storage as it is not getting mounted on the host. For eg: 1. When first incremental snapshot (eg Ssec1-1) is taken, secondary storage (sec1) is mounted on local path “/var/run/sr-mount/ on the host. 2. Second incremental snapshot (Ssec1-2) is created, to get the parent vhd, the secondary storage is mounted at mount path “/var/run/cloud_mount/dc_id/snapshots”. 3. If other snapshot (for different volume) is created on different secondary storage (sec2), sec2 is not getting mounted on /var/run/cloud_mount/dc_id/snapshots path. The fix is to mount other secondary storages as well on the host. The local mount path in vmopsSnapshot.py is modified, instead of mounting on “/var/run/cloud_mount/dc_id/snapshots”, “/var/run/cloud_mount/dc_id/snapshots/secHostid” mount path is used. This addresses bug CS-16263. Diffs - api/src/com/cloud/agent/api/BackupSnapshotCommand.java 9476d7d plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java d2db85c scripts/vm/hypervisor/xenserver/vmopsSnapshot 80e21f8 server/src/com/cloud/storage/snapshot/SnapshotManagerImpl.java d89a6d9 Diff: https://reviews.apache.org/r/7594/diff/ Testing --- Tested for following cases: 1. Snapshot Creation: Host 1 has a vm i-1, volume ROOT-1 DATA-1, Host 2 has a vm i-2, volume ROOT-2 DATA-2, Taken recurring snapshot for 4 volumes. Verified: multiple secondary storages are getting mounted on host. Snapshots creation successful 2. Template Creation: Verified: templates successfully created from the above snapshots 3. Volume creation: Verified: volumes successfully created from the above snapshots 4. VM Migration Migrate i-1 from Host-1 to Host-2. Verified: Secondary mount point successfully created on Host-2. Thanks, deepti dohare
RE: StaticNAT, Portforwarding and FIrewall implemenation on the SRX
Hi Alena, Please see my comments inline, -Jayapal -Original Message- From: Alena Prokharchyk Sent: Friday, October 12, 2012 10:19 PM To: Jayapal Reddy Uradi; cloudstack-dev@incubator.apache.org Subject: Re: StaticNAT, Portforwarding and FIrewall implemenation on the SRX Jayapal, please see my comments inline. -Alena. On 10/11/12 11:07 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: Alena, Please find my inline comments. Thanks, Jayapal Thanks, Jayapal -Original Message- From: Alena Prokharchyk Sent: Friday, October 12, 2012 5:54 AM To: cloudstack-dev@incubator.apache.org; Jayapal Reddy Uradi Subject: Re: StaticNAT, Portforwarding and FIrewall implemenation on the SRX Jayapal, I reviewed the spec. My comments: If firewall rules per public IP address can't be configured on the SRX, and there is no way to fix it (your spec says so in Limitation section), why do we introduce all this complexity? To me it seems like we are trying to show the user that he is controlling public ports on SRX, while in fact it's not true. It should work just like it used to work before: the Ingress traffic flow from public to guest interfaces should be controlled by PF/StaticNat/LB rule; Ingress traffic to public ip address is allowed always. When there is no PF/LB/StaticNat rule for the Guest network port, the traffic to Guest port is blocked. Once you create PF rule for publicIp + guestIp, the access to the specific port of the Guest network is + opened automatically. The example below (taken from the spec): Example: 1. Acquire IP P1. 2. Create Firewall for port 22 - port 22. 3. Configure the port forwarding for Public IP P1, user VM V1 4. Acquire another IP P2. 5. Enable staticNAT on P2 for VM V1 //Jayapal Let me change the case here and going to update in FS. 6.Add firewall rule for P2 for VM V1 on ports 80 7. Now In SRX, using P2 user can access the VM V1 ports 22 and 80. Still doesn't work like the regular Firewall rule. You enabled Firewall for port 22 on P1, and for port 80 on P2 and it results in being able to access port 22/80 on P2? Firewall rule on one public IP should never affect the behavior of another public IP. That's not how Firewall rule is supposed to work. 7. Now P1 and P2 both can access the VM port 22 - /// you haven't created the Firewall rule for the P2, yet the access from it is enabled implicitly to 22:22 port. It's very confusing. In other words, the firewall rule created for P1 ip should never ever control the access to P2 ip address. We need to fix the original issue - make StaticNat rules on the SRX. For that we have to treat firewall rule as a static nat rule for a particular port by SRX device if the static nat is enabled for this public ip address in the cloudStack. In all other cases Firewall rule should be just ignored. //Jayapal I agree with ignoring firewall for port forwarding. But in VR the PF rule works only after adding Firewall rule for the public ports. It is ok to leave it the old way for the SRX. Your limitation clearly says that you can't control the public IP / ports on the SRX anyway. So lets just fix the Static nat rule; it would also leave less chance for regressing in PF rules functionality. CASE1: * Get Ip1. * Create PF rule for IP1 and port 22 VM1. Now you can access the Vm1. * Create firewall rule for Ip1. SRX should just ignore this request as it will not do anything CASE2: * Get IP2 * Enable static nat on the IP2 and VM1. Nothing is sent to SRX just yet. * Create firewall rule for IP2 and ports 22-23. Send enable static nat for IP2/VM1 and port 22-23 to the SRX device * Repeat last step for each port (port range) you want to enable static nat for. //Jayapal In SRX, below issue can still exist. Case3: In addition to CASE1, CASE2, Create another PF rule for IP1 and port 80 VM1. Now you can access the Vm1 port 80. Now P2 can access the port 80 without Firewall rule on Port 80. Because security policy in SRX is not differentiated for Public IPs. You can never create the PF or LB rule for the ip address that has Static nat rule assigned. [Jayapal] But we can create - PF: P1, VM V1 and ports 22-22 - Static NAT: P2 VM V1, and Firewall port 80 Here P2 can access V1's ports 22, 80. This is specific to SRX. In other words, you have to make the translation of Firewall rule of the cloudStack to ConfigureStaticNat on SRX when the targeted public IP address is Static nat enabled. In all other cases Firewall commands should be just ignored by the SRX device. Let me know what you think, //Jayapal I agree with you. Current port forwarding rule have Public Port range and Private Port range. So port forwarding allows only the Public Ports that we added. Again allowing Ports using Firewall is of no use. Example: Port forwarding rule: public Ports 22 and private
Re: [RFC] QinQ vlans support
This sounds like it can be modeled as multiple physical networks? That is, each outer vlan (400, 401, etc) is a separate physical network in the same zone. That could work, although it is probable that the zone configuration API bits prevent more than 4k VLANs per zone (that can be changed to per physical network). As long as communication between guests on different physical networks happens via the public network, it should be Ok. I'd like to see the patch. Thanks On 10/12/12 1:09 AM, Marcus Sorensen shadow...@gmail.com wrote: Guys, in looking for a free and scalable way to provide private networks for customers I've been running a QinQ setup that has been working quite well. I've sort of laid the groundwork for it already in changing the bridge naming conventions about a month ago for KVM(to names that won't collide if the same vlans is used twice on different phys). Basically the way it works is like this. Linux has two ways of creating tagged networks, the eth#.# and the less used vlan# network devices. I have a tiny patch that causes cloudstack to treat vlan# devs as though they were physical NICs. In this way, you can do something like physical devices eth0,eth1,and vlan400. management traffic on eth0's bridge, storage on eth1.102's bridge, maybe eth1.103 for public/guest, then create say a vlan400 that is tag 400 on eth1. You add a traffic type of guest to it and give it a vlan range, say 10-4000. Then you end up with cloudstack handing out vlan400.10, vlan400.11, etc for guest networks. Works great for network isolation without burning through a bunch of your real vlans. In the unlikely event that you run out, you just create a physical vlan401 and start over with the vlan numbers. In theory all-you-can-eat isolated networks without having to configure hundreds of vlans on your networking equipment. This may require additional config on any upstream switches to pass the double tags around, but in general from what I've seen the inner tags just pass through on anything layer 2, it should only get tricky if you try to tunnel, route or strip tags. This is especially nice with system VM routers and VPC (cloudstack takes care of everything), but admittedly external routers probably will have spotty support for being able to route double tagged stuff. I'm also a bit afraid that if I were to get it merged in that it would just become this undocumented hack thing that few know about and nobody uses. So I'm looking for feedback on whether this sounds useful enough to commit, how it should be documented, and whether it makes sense to hint at this in the GUI somehow.
[jira] [Created] (CLOUDSTACK-346) Cannot add Vmware cluster with class loader conflict exception
Mice Xia created CLOUDSTACK-346: --- Summary: Cannot add Vmware cluster with class loader conflict exception Key: CLOUDSTACK-346 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-346 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: pre-4.0.0 Reporter: Mice Xia Assignee: Rohit Yadav [how to reproduce] 1) run a nonoss env followed with instructions from this link: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building#Building-Packaging 2) ant debug 3) add a vmware cluster 4) exception catched loader constraint violation: when resolving field service the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the referring class, org/apache/axis/client/Stub, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for the field's resolved type, javax/xml/rpc/Service, have different Class objects for that type [analysis] seems a conflict between ./webapps/client/WEB-INF/lib/vmware-lib-jaxrpc.jar and lib/axis-jaxrpc-1.4.jar remove the vmware-lib-jaxrpc.jar, then cluster could be added. Please notice here i'm using vsphere 5.1, but this issue seems unlikely related to vcenter version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-346) Cannot add Vmware cluster with class loader conflict exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476033#comment-13476033 ] Rohit Yadav commented on CLOUDSTACK-346: The issue is this jar was blindly added as we'd removed it and further one of the maven deps got axis-jaxrpc-1.4.jar introduced. Both the artifacts are in fact the same jars, bit by bit and different names. Removing vmware-lib-jaxrpc worked and it's only used by vmware-base and vmware-plugin, it would be safe to remove from the nonoss patch too. Cannot add Vmware cluster with class loader conflict exception -- Key: CLOUDSTACK-346 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-346 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: pre-4.0.0 Reporter: Mice Xia Assignee: Rohit Yadav [how to reproduce] 1) run a nonoss env followed with instructions from this link: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building#Building-Packaging 2) ant debug 3) add a vmware cluster 4) exception catched loader constraint violation: when resolving field service the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the referring class, org/apache/axis/client/Stub, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for the field's resolved type, javax/xml/rpc/Service, have different Class objects for that type [analysis] seems a conflict between ./webapps/client/WEB-INF/lib/vmware-lib-jaxrpc.jar and lib/axis-jaxrpc-1.4.jar remove the vmware-lib-jaxrpc.jar, then cluster could be added. Please notice here i'm using vsphere 5.1, but this issue seems unlikely related to vcenter version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Egress Firewall Rules feature FS
Hi Nilesh, Please fine my inline comments. Thanks, Jayapal From: Nilesh Vishwakarma Sent: Thursday, October 11, 2012 6:37 PM To: Jayapal Reddy Uradi Cc: cloudstack-dev@incubator.apache.org Subject: Egress Firewall Rules feature FS Hey, My review comments on Egress Firewall Rules feature FS: 1. Let me know whether we are using CreateFirewall API or NetworkACL to implement firewall rule - There is a discussion in community about which API to use. I will update the spec once the discussion is closed. 2. How can I block the communication with particular subnet? As in if I want to block communication ONLY with some IP range and allow the rest of the communication, would it be possible? -It is not possible. There are only rules to ALLOW. 3. Can we have BLOCK rule which can block communication with specified IP range? -We can have only ALLOW rules. The egress rules only allowed and remaining traffic is blocked. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Egress+firewall+rules+for+guest+network -Thanks, Nilesh
Re: Review Request: Encode URI during vmware cluster discovery
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7571/#review12436 --- Ship it! Ship It! - Sateesh Chodapuneedi On Oct. 12, 2012, 9:38 p.m., Venkata Siva Vijayendra Bhamidipati wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7571/ --- (Updated Oct. 12, 2012, 9:38 p.m.) Review request for cloudstack and Kelven Yang. Description --- Encoding URI during vmware cluster discovery was missed out in one place, fixing it. This addresses bug CLOUDSTACK-333. Diffs - server/src/com/cloud/storage/StorageManagerImpl.java 7ec50f9 Diff: https://reviews.apache.org/r/7571/diff/ Testing --- Thanks, Venkata Siva Vijayendra Bhamidipati
[jira] [Resolved] (CLOUDSTACK-346) Cannot add Vmware cluster with class loader conflict exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-346. Resolution: Fixed Fixed nonoss patches for 4.0 For master, fixed maven pom.xmls: commit 9b1b145192645633311da5e3727d5f0484f5d037 Author: Rohit Yadav bhais...@apache.org Date: Mon Oct 15 14:28:27 2012 +0530 Cannot add Vmware cluster with class loader conflict exception -- Key: CLOUDSTACK-346 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-346 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: pre-4.0.0 Reporter: Mice Xia Assignee: Rohit Yadav [how to reproduce] 1) run a nonoss env followed with instructions from this link: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building#Building-Packaging 2) ant debug 3) add a vmware cluster 4) exception catched loader constraint violation: when resolving field service the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the referring class, org/apache/axis/client/Stub, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for the field's resolved type, javax/xml/rpc/Service, have different Class objects for that type [analysis] seems a conflict between ./webapps/client/WEB-INF/lib/vmware-lib-jaxrpc.jar and lib/axis-jaxrpc-1.4.jar remove the vmware-lib-jaxrpc.jar, then cluster could be added. Please notice here i'm using vsphere 5.1, but this issue seems unlikely related to vcenter version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: FS on cloudStack createSnapshot synchronization improvement
Hi Alena - Why is it that we prefer hosts on which vm is/was running for creating snapshots - do we see performance benefits in any way or it was a convenient way of choosing the host ? For performance benefits can we not choose a host in the cluster which has the least load (in terms of create snapshot jobs or some better metric) so as to balance the load across the cluster. I guess this would also help in first fit vm deployment algorithms to not overload the host and starve the create snapshot jobs ? Also can we not have different config params for concurrent.snapshots.threshold.perhost since the snapshot creation implementation is drastically different in the hypervisors so one value might not be the best idea here ? Thanks, -Nitin -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Monday, October 15, 2012 9:24 AM To: cloudstack-dev@incubator.apache.org; Anthony Xu Subject: Re: FS on cloudStack createSnapshot synchronization improvement Anthony, I implemented the threshold logic on Api Layer, in SyncQueueJob manager. In other words, before submitting the job for execution, we should know the host the job would go first to - that would be the object we are synchronizing on. For createSnapshot it's always the host where vm is 1) running on (for Running vm) 2) ran the last time on (for Stopped vm). Only when the command fails on the initial host, we retry on other hosts in cluster. So it would work like this: 1) api call is made 2) Before submitting the async job to the queue, we figure out the host id (getHostIdForSnapshotOperation method in SnapshotManagerImpl). Lets say, the id of the host is 1. 3) The job is submitted with object to sync on = host id=1. 4) Once the job is ready to execute, it goes to snapshot manager which sends the command to the host id=1 first. If it fails by some reason, it gets resent to other host in the cluster (if exist). And in this failure scenario we don't do any synchronization. We've decided not to handle this error case because it won't happen in most of the cases. I've checked the code for other commands you've mentioned; the host is always picked up randomly from the list of hosts in cluster. So we can't apply the same logic unless we fix the code to pick up the same host on step 2) and step 4) without making callbacks from SnapshotManager to the SyncQueueManager. I would appreciate any suggestions on how to implement it. Thank you, Alena. From: Anthony Xu xuefei...@citrix.commailto:xuefei...@citrix.com Reply-To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org Subject: RE: FS on cloudStack createSnapshot synchronization improvement There are several commands need this kind of threshold, e.g. Move volume, create template from snapshot, So this is common requirement , not only for createsnapshot. Can we add threshold mechanism in host command queue to resolve this issue? Anthony -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Thursday, October 11, 2012 4:42 PM To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org Subject: RE: FS on cloudStack createSnapshot synchronization improvement I only have one comment: Can we put this snapshot improvement code out of snapshotmanager? -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Tuesday, October 09, 2012 11:51 AM To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org Subject: FS on cloudStack createSnapshot synchronization improvement Hi All, I'm planning to introduce some changes to create snapshot behavior for the future cloudStack release (the changes will go to asf/master branch). The fix is fixing the problem described below: With the current code for snapshots, cloudStack always creates snapshot on the host where vm is Running (for vms in Running state) or on the host where vm used to run the last time (for vms in Stopped state). As the createSnapshot commands are not synchronized on the agent side, the case when multiple commands are send to the backend at the same time can lead to the performance issues on the hypervisor side. At the end there is a high possibility that createSnapshot command might time out on the Xen side. The solution is to synchronize number of concurrent snapshots per host basis. The threshold should be configurable as the customer usually knows how many snapshots at a time the backend can handle. While the concurrent snapshots are being processed by the backend, all subsequent snapshot commands scheduled for execution on the same host, should wait in the queue Here is the feature FS
[nonoss][vmware] update on dependency
Just a heads up for nonoss/vmware developers on master: (there is no issue on 4.0) Mice filed an issue today: https://issues.apache.org/jira/browse/CLOUDSTACK-346 Thanks to him, I found out that vmware-lib-jaxrpc.jar and axis-jaxrpc-1.4.jar are the same files with different filenames. The nonoss patches are updated: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building#Building-NonOSSBuilding Regards.
Review Request: [DOCS]Docbook xml for additional installation options
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7597/ --- Review request for cloudstack, David Nalley and Jessica Tomechak. Description --- Make docbook xml for additional installation options, include usage server installation, db replication and ssl. Diffs - docs/en-US/additional-installation-options.xml PRE-CREATION docs/en-US/cloudstack.xml d9dca66 docs/en-US/database-replication.xml PRE-CREATION docs/en-US/install-usage-server.xml PRE-CREATION docs/en-US/ssl.xml PRE-CREATION Diff: https://reviews.apache.org/r/7597/diff/ Testing --- Passed publican build using config file: publican-all.cfg, verified pdf/html output. The changes won't impact admin guide doc. Thanks, Gavin Lee
[ASFCS40] Reminder about the latest RC for 4.0.0-incubating
Hi all, In case you missed it over the weekend, we cut another release candidate for 4.0.0-incubating on Saturday night and started the second voting round [1]. Please jump in and start testing! Looking forward to seeing your votes on the VOTE thread... -chip [1] http://markmail.org/thread/hk523mkdajslq2vr
Re: Review Request: Snapshot errors with multiple secondary storage in one zone.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7594/#review12438 --- Can you make sure this is a bug on issues.apache.org/jira - bugs.cs.o is deprecated from a pojrect standpoint. - David Nalley On Oct. 15, 2012, 6:48 a.m., deepti dohare wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7594/ --- (Updated Oct. 15, 2012, 6:48 a.m.) Review request for cloudstack, Nitin Mehta and anthony xu. Description --- Fixed CS-16263 The issue is happening because of the multiple secondary storages, the secondary storage which is used first is getting mounted on the host resulting in failure of other snapshot using different secondary storage as it is not getting mounted on the host. For eg: 1. When first incremental snapshot (eg Ssec1-1) is taken, secondary storage (sec1) is mounted on local path “/var/run/sr-mount/ on the host. 2. Second incremental snapshot (Ssec1-2) is created, to get the parent vhd, the secondary storage is mounted at mount path “/var/run/cloud_mount/dc_id/snapshots”. 3. If other snapshot (for different volume) is created on different secondary storage (sec2), sec2 is not getting mounted on /var/run/cloud_mount/dc_id/snapshots path. The fix is to mount other secondary storages as well on the host. The local mount path in vmopsSnapshot.py is modified, instead of mounting on “/var/run/cloud_mount/dc_id/snapshots”, “/var/run/cloud_mount/dc_id/snapshots/secHostid” mount path is used. This addresses bug CS-16263. Diffs - api/src/com/cloud/agent/api/BackupSnapshotCommand.java 9476d7d plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java d2db85c scripts/vm/hypervisor/xenserver/vmopsSnapshot 80e21f8 server/src/com/cloud/storage/snapshot/SnapshotManagerImpl.java d89a6d9 Diff: https://reviews.apache.org/r/7594/diff/ Testing --- Tested for following cases: 1. Snapshot Creation: Host 1 has a vm i-1, volume ROOT-1 DATA-1, Host 2 has a vm i-2, volume ROOT-2 DATA-2, Taken recurring snapshot for 4 volumes. Verified: multiple secondary storages are getting mounted on host. Snapshots creation successful 2. Template Creation: Verified: templates successfully created from the above snapshots 3. Volume creation: Verified: volumes successfully created from the above snapshots 4. VM Migration Migrate i-1 from Host-1 to Host-2. Verified: Secondary mount point successfully created on Host-2. Thanks, deepti dohare
Re: Integrating autoscale branch to master?
On Fri, Oct 12, 2012 at 11:54 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Ok I will keep changes ready, and will merge once 4.0's news is declared. -Vijay V. Vijay, I haven't kept up with this recently so a couple of questions/assumptions: 1. Autoscale code will require NetScaler libraries right? 2. Is autoscale functionality modular enough that we can turn building it on/off at will? 3. Has there been any change to the netscaler java library licensing? I know there was work underway, but I never heard about a conclusion. --David
[jira] [Updated] (CLOUDSTACK-346) Cannot add Vmware cluster with class loader conflict exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-346: --- Affects Version/s: (was: pre-4.0.0) 4.1.0 Cannot add Vmware cluster with class loader conflict exception -- Key: CLOUDSTACK-346 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-346 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.1.0 Reporter: Mice Xia Assignee: Rohit Yadav Fix For: 4.1.0 [how to reproduce] 1) run a nonoss env followed with instructions from this link: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building#Building-Packaging 2) ant debug 3) add a vmware cluster 4) exception catched loader constraint violation: when resolving field service the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the referring class, org/apache/axis/client/Stub, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for the field's resolved type, javax/xml/rpc/Service, have different Class objects for that type [analysis] seems a conflict between ./webapps/client/WEB-INF/lib/vmware-lib-jaxrpc.jar and lib/axis-jaxrpc-1.4.jar remove the vmware-lib-jaxrpc.jar, then cluster could be added. Please notice here i'm using vsphere 5.1, but this issue seems unlikely related to vcenter version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-346) Cannot add Vmware cluster with class loader conflict exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-346: --- Fix Version/s: 4.1.0 Cannot add Vmware cluster with class loader conflict exception -- Key: CLOUDSTACK-346 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-346 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.1.0 Reporter: Mice Xia Assignee: Rohit Yadav Fix For: 4.1.0 [how to reproduce] 1) run a nonoss env followed with instructions from this link: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building#Building-Packaging 2) ant debug 3) add a vmware cluster 4) exception catched loader constraint violation: when resolving field service the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the referring class, org/apache/axis/client/Stub, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for the field's resolved type, javax/xml/rpc/Service, have different Class objects for that type [analysis] seems a conflict between ./webapps/client/WEB-INF/lib/vmware-lib-jaxrpc.jar and lib/axis-jaxrpc-1.4.jar remove the vmware-lib-jaxrpc.jar, then cluster could be added. Please notice here i'm using vsphere 5.1, but this issue seems unlikely related to vcenter version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
CloudStack 4.x API Docs
Hi Folks, Where would CS 4.0 API documentation reside? Thanks ilya
Re: CloudStack 4.x API Docs
http://incubator.apache.org/cloudstack/docs/api On Mon, Oct 15, 2012 at 10:35 AM, Musayev, Ilya imusa...@webmd.net wrote: Hi Folks, Where would CS 4.0 API documentation reside? Thanks ilya
RE: review comment for Reset ssh key functional spec
Hi, Which version would have this feature? Thanks ilya -Original Message- From: Srinivas Vejalla [mailto:srinivas.veja...@citrix.com] Sent: Thursday, October 11, 2012 5:08 AM To: Harikrishna Patnala; Shweta Agarwal; cloudstack-dev@incubator.apache.org; #Cloud - QA Team Subject: RE: review comment for Reset ssh key functional spec We should be able to reset single or multiple VM ssh keys. Srini// From: Harikrishna Patnala Sent: Thursday, October 11, 2012 2:36 PM To: Shweta Agarwal; cloudstack-dev@incubator.apache.org; #Cloud - QA Team Subject: RE: review comment for Reset ssh key functional spec With the current plan, it is targeted to reset ssh for a single VM provided in the api call. If we want to support the scenario for multiple VMs at a time, we can try out by putting a list of VMs in the api call on which resetting can be done. From: Shweta Agarwal Sent: 11 October 2012 13:38 To: Harikrishna Patnala; cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org; #Cloud - QA Team Subject: RE: review comment for Reset ssh key functional spec What about my scenario where in I want to update ssh key of my 100VMs having same ssh key pair at one go . Can we achieve it with current Api implementation . From: Harikrishna Patnala Sent: Thursday, October 11, 2012 12:30 PM To: Shweta Agarwal; cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org; #Cloud - QA Team Subject: RE: review comment for Reset ssh key functional spec * The required parameters are listed In the FS and there are no optional parameters. * The password that it will return as a plain text in the response. * If the User VM is in running state, it is rebooted as part of the ssh key reset to update the new ssh public key in VM (cloud-set-guest-sshkey script runs as a init service in VM to get the new ssh public key from virtual router). If the VM is in stopped state, then reset SSH api action won't reboot the VM. * But rebooting the VM as part of reset SSH key may lead to the loss of VM session. So an optional parameter forcereboot can be put in the API call with the value true/false. If the VM is in running state and forcereboot is true then VM is rebooted after the reset of SSH key. If the VM is in running state and forcereboot is false then an error message is prompted saying VM needs to be stopped. Please review and comment on this. Thanks Harikrishna From: Shweta Agarwal Sent: 11 October 2012 10:42 To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org; #Cloud - QA Team; Harikrishna Patnala Subject: review comment for Reset ssh key functional spec My review comment for ResetSSHkey Functional spec * In the API parameters Please mention which all parameters are required and which all are optional. * The password which it will return in the response to resetSSHKeyForVirtualMachine api will it be encrypted password or in plain text . * What will happen to the current session of the VM which user has login with the old password when you will change the password * More over a design consideration * When i have several VM with same SSH keypair and my private key is compromised .I would like to change Keypair of all my VMs having old keypair . So is there a way to do the same with the current API design . I definitely don't want to iterate the entire process Per VM ;if I have let say 100 VMs. For example If i give my oldkeypair name and new keypair name then it should change the keypair of all the VMs having old keypair of my account. Thanks Shweta
Re: CloudStack 4.x API Docs
Thank you. On Oct 15, 2012, at 10:37 AM, David Nalley da...@gnsa.us wrote: http://incubator.apache.org/cloudstack/docs/api On Mon, Oct 15, 2012 at 10:35 AM, Musayev, Ilya imusa...@webmd.net wrote: Hi Folks, Where would CS 4.0 API documentation reside? Thanks ilya
Re: [RFC] QinQ vlans support
That's a far more elegant way then I tried, which was creating tagged interfaces within guests. Sent from my iPhone On Oct 15, 2012, at 12:54 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: This sounds like it can be modeled as multiple physical networks? That is, each outer vlan (400, 401, etc) is a separate physical network in the same zone. That could work, although it is probable that the zone configuration API bits prevent more than 4k VLANs per zone (that can be changed to per physical network). As long as communication between guests on different physical networks happens via the public network, it should be Ok. I'd like to see the patch. Thanks On 10/12/12 1:09 AM, Marcus Sorensen shadow...@gmail.com wrote: Guys, in looking for a free and scalable way to provide private networks for customers I've been running a QinQ setup that has been working quite well. I've sort of laid the groundwork for it already in changing the bridge naming conventions about a month ago for KVM(to names that won't collide if the same vlans is used twice on different phys). Basically the way it works is like this. Linux has two ways of creating tagged networks, the eth#.# and the less used vlan# network devices. I have a tiny patch that causes cloudstack to treat vlan# devs as though they were physical NICs. In this way, you can do something like physical devices eth0,eth1,and vlan400. management traffic on eth0's bridge, storage on eth1.102's bridge, maybe eth1.103 for public/guest, then create say a vlan400 that is tag 400 on eth1. You add a traffic type of guest to it and give it a vlan range, say 10-4000. Then you end up with cloudstack handing out vlan400.10, vlan400.11, etc for guest networks. Works great for network isolation without burning through a bunch of your real vlans. In the unlikely event that you run out, you just create a physical vlan401 and start over with the vlan numbers. In theory all-you-can-eat isolated networks without having to configure hundreds of vlans on your networking equipment. This may require additional config on any upstream switches to pass the double tags around, but in general from what I've seen the inner tags just pass through on anything layer 2, it should only get tricky if you try to tunnel, route or strip tags. This is especially nice with system VM routers and VPC (cloudstack takes care of everything), but admittedly external routers probably will have spotty support for being able to route double tagged stuff. I'm also a bit afraid that if I were to get it merged in that it would just become this undocumented hack thing that few know about and nobody uses. So I'm looking for feedback on whether this sounds useful enough to commit, how it should be documented, and whether it makes sense to hint at this in the GUI somehow.
Re: [RFC] QinQ vlans support
On 10/15/12 8:35 AM, Kelceydamage@bbits kel...@bbits.ca wrote: That's a far more elegant way then I tried, which was creating tagged interfaces within guests. Sent from my iPhone On Oct 15, 2012, at 12:54 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: This sounds like it can be modeled as multiple physical networks? That is, each outer vlan (400, 401, etc) is a separate physical network in the same zone. That could work, although it is probable that the zone configuration API bits prevent more than 4k VLANs per zone (that can be changed to per physical network). As long as communication between guests on different physical networks happens via the public network, it should be Ok. I'd like to see the patch. Thanks On 10/12/12 1:09 AM, Marcus Sorensen shadow...@gmail.com wrote: Guys, in looking for a free and scalable way to provide private networks for customers I've been running a QinQ setup that has been working quite well. I've sort of laid the groundwork for it already in changing the bridge naming conventions about a month ago for KVM(to names that won't collide if the same vlans is used twice on different phys). Basically the way it works is like this. Linux has two ways of creating tagged networks, the eth#.# and the less used vlan# network devices. I have a tiny patch that causes cloudstack to treat vlan# devs as though they were physical NICs. In this way, you can do something like physical devices eth0,eth1,and vlan400. management traffic on eth0's bridge, storage on eth1.102's bridge, maybe eth1.103 for public/guest, then create say a vlan400 that is tag 400 on eth1. You add a traffic type of guest to it and give it a vlan range, say 10-4000. Then you end up with cloudstack handing out vlan400.10, vlan400.11, etc for guest networks. Works great for network isolation without burning through a bunch of your real vlans. In the unlikely event that you run out, you just create a physical vlan401 and start over with the vlan numbers. In theory all-you-can-eat isolated networks without having to configure hundreds of vlans on your networking equipment. This may require additional config on any upstream switches to pass the double tags around, but in general from what I've seen the inner tags just pass through on anything layer 2, it should only get tricky if you try to tunnel, route or strip tags. This is especially nice with system VM routers and VPC (cloudstack takes care of everything), but admittedly external routers probably will have spotty support for being able to route double tagged stuff. I'm also a bit afraid that if I were to get it merged in that it would just become this undocumented hack thing that few know about and nobody uses. So I'm looking for feedback on whether this sounds useful enough to commit, how it should be documented, and whether it makes sense to hint at this in the GUI somehow. +1 This actually sounds amazing Marcus. I'd love to see and use this implementation. -- Æ
Re: StaticNAT, Portforwarding and FIrewall implemenation on the SRX
From: Jayapal Reddy Uradi jayapalreddy.ur...@citrix.commailto:jayapalreddy.ur...@citrix.com To: Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@citrix.com, cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org Subject: RE: StaticNAT, Portforwarding and FIrewall implemenation on the SRX Hi Alena, Please see my comments inline, -Jayapal -Original Message- From: Alena Prokharchyk Sent: Friday, October 12, 2012 10:19 PM To: Jayapal Reddy Uradi; cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org Subject: Re: StaticNAT, Portforwarding and FIrewall implemenation on the SRX Jayapal, please see my comments inline. -Alena. On 10/11/12 11:07 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.commailto:jayapalreddy.ur...@citrix.com wrote: Alena, Please find my inline comments. Thanks, Jayapal Thanks, Jayapal -Original Message- From: Alena Prokharchyk Sent: Friday, October 12, 2012 5:54 AM To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org; Jayapal Reddy Uradi Subject: Re: StaticNAT, Portforwarding and FIrewall implemenation on the SRX Jayapal, I reviewed the spec. My comments: If firewall rules per public IP address can't be configured on the SRX, and there is no way to fix it (your spec says so in Limitation section), why do we introduce all this complexity? To me it seems like we are trying to show the user that he is controlling public ports on SRX, while in fact it's not true. It should work just like it used to work before: the Ingress traffic flow from public to guest interfaces should be controlled by PF/StaticNat/LB rule; Ingress traffic to public ip address is allowed always. When there is no PF/LB/StaticNat rule for the Guest network port, the traffic to Guest port is blocked. Once you create PF rule for publicIp + guestIp, the access to the specific port of the Guest network is + opened automatically. The example below (taken from the spec): Example: 1. Acquire IP P1. 2. Create Firewall for port 22 - port 22. 3. Configure the port forwarding for Public IP P1, user VM V1 4. Acquire another IP P2. 5. Enable staticNAT on P2 for VM V1 //Jayapal Let me change the case here and going to update in FS. 6.Add firewall rule for P2 for VM V1 on ports 80 7. Now In SRX, using P2 user can access the VM V1 ports 22 and 80. Still doesn't work like the regular Firewall rule. You enabled Firewall for port 22 on P1, and for port 80 on P2 and it results in being able to access port 22/80 on P2? Firewall rule on one public IP should never affect the behavior of another public IP. That's not how Firewall rule is supposed to work. 7. Now P1 and P2 both can access the VM port 22 - /// you haven't created the Firewall rule for the P2, yet the access from it is enabled implicitly to 22:22 port. It's very confusing. In other words, the firewall rule created for P1 ip should never ever control the access to P2 ip address. We need to fix the original issue - make StaticNat rules on the SRX. For that we have to treat firewall rule as a static nat rule for a particular port by SRX device if the static nat is enabled for this public ip address in the cloudStack. In all other cases Firewall rule should be just ignored. //Jayapal I agree with ignoring firewall for port forwarding. But in VR the PF rule works only after adding Firewall rule for the public ports. It is ok to leave it the old way for the SRX. Your limitation clearly says that you can't control the public IP / ports on the SRX anyway. So lets just fix the Static nat rule; it would also leave less chance for regressing in PF rules functionality. CASE1: * Get Ip1. * Create PF rule for IP1 and port 22 VM1. Now you can access the Vm1. * Create firewall rule for Ip1. SRX should just ignore this request as it will not do anything CASE2: * Get IP2 * Enable static nat on the IP2 and VM1. Nothing is sent to SRX just yet. * Create firewall rule for IP2 and ports 22-23. Send enable static nat for IP2/VM1 and port 22-23 to the SRX device * Repeat last step for each port (port range) you want to enable static nat for. //Jayapal In SRX, below issue can still exist. Case3: In addition to CASE1, CASE2, Create another PF rule for IP1 and port 80 VM1. Now you can access the Vm1 port 80. Now P2 can access the port 80 without Firewall rule on Port 80. Because security policy in SRX is not differentiated for Public IPs. You can never create the PF or LB rule for the ip address that has Static nat rule assigned. [Jayapal] But we can create - PF: P1, VM V1 and ports 22-22 - Static NAT: P2 VM V1, and Firewall port 80 Here P2 can access V1's ports 22, 80. This is specific to SRX. If it was always the case for SRX, then we just have to document it. I believe even with the initial design you've proposed, it would have been the case. You can't control public
Re: FS on cloudStack createSnapshot synchronization improvement
On 10/15/12 4:27 AM, Nitin Mehta nitin.me...@citrix.com wrote: Hi Alena - Why is it that we prefer hosts on which vm is/was running for creating snapshots - do we see performance benefits in any way or it was a convenient way of choosing the host ? Anthony is the best person to answer this question; this logic was in place before I put in my changes. As far as I know, in VmWare case (according to Kelven), there are less chances for the createSnapshot command to fail when it's executed on the host where the vm resides on. For performance benefits can we not choose a host in the cluster which has the least load (in terms of create snapshot jobs or some better metric) so as to balance the load across the cluster. Agree with you on that. But it would be much bigger of a change, we can implement it later. I guess this would also help in first fit vm deployment algorithms to not overload the host and starve the create snapshot jobs ? Also can we not have different config params for concurrent.snapshots.threshold.perhost since the snapshot creation implementation is drastically different in the hypervisors so one value might not be the best idea here ? Yes, you can file an enhancement for this. Thanks, -Nitin -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Monday, October 15, 2012 9:24 AM To: cloudstack-dev@incubator.apache.org; Anthony Xu Subject: Re: FS on cloudStack createSnapshot synchronization improvement Anthony, I implemented the threshold logic on Api Layer, in SyncQueueJob manager. In other words, before submitting the job for execution, we should know the host the job would go first to - that would be the object we are synchronizing on. For createSnapshot it's always the host where vm is 1) running on (for Running vm) 2) ran the last time on (for Stopped vm). Only when the command fails on the initial host, we retry on other hosts in cluster. So it would work like this: 1) api call is made 2) Before submitting the async job to the queue, we figure out the host id (getHostIdForSnapshotOperation method in SnapshotManagerImpl). Lets say, the id of the host is 1. 3) The job is submitted with object to sync on = host id=1. 4) Once the job is ready to execute, it goes to snapshot manager which sends the command to the host id=1 first. If it fails by some reason, it gets resent to other host in the cluster (if exist). And in this failure scenario we don't do any synchronization. We've decided not to handle this error case because it won't happen in most of the cases. I've checked the code for other commands you've mentioned; the host is always picked up randomly from the list of hosts in cluster. So we can't apply the same logic unless we fix the code to pick up the same host on step 2) and step 4) without making callbacks from SnapshotManager to the SyncQueueManager. I would appreciate any suggestions on how to implement it. Thank you, Alena. From: Anthony Xu xuefei...@citrix.commailto:xuefei...@citrix.com Reply-To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apach e.org cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apach e.org To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apach e.org cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apach e.org Subject: RE: FS on cloudStack createSnapshot synchronization improvement There are several commands need this kind of threshold, e.g. Move volume, create template from snapshot, So this is common requirement , not only for createsnapshot. Can we add threshold mechanism in host command queue to resolve this issue? Anthony -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Thursday, October 11, 2012 4:42 PM To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache .org Subject: RE: FS on cloudStack createSnapshot synchronization improvement I only have one comment: Can we put this snapshot improvement code out of snapshotmanager? -Original Message- From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] Sent: Tuesday, October 09, 2012 11:51 AM To: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache .org Subject: FS on cloudStack createSnapshot synchronization improvement Hi All, I'm planning to introduce some changes to create snapshot behavior for the future cloudStack release (the changes will go to asf/master branch). The fix is fixing the problem described below: With the current code for snapshots, cloudStack always creates snapshot on the host where vm is Running (for vms in Running state) or on the host where vm used to run the last time (for vms in Stopped state). As the createSnapshot commands are not synchronized on the agent side, the case when multiple commands are send to the backend at the same time can lead to the performance issues on the hypervisor side. At the end there is a high possibility that
[jira] [Created] (CLOUDSTACK-347) listNetworks API: return vlan information only when the caller is ROOT admin
Alena Prokharchyk created CLOUDSTACK-347: Summary: listNetworks API: return vlan information only when the caller is ROOT admin Key: CLOUDSTACK-347 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-347 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.0.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.1.0 As only ROOT admin should know physical network configuration, we shouldn't return Vlan information to the regular user / domain admin, as a part of listNetworks call -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-348) deleteNetwork does not clean up network resource count correctly
Will Stevens created CLOUDSTACK-348: --- Summary: deleteNetwork does not clean up network resource count correctly Key: CLOUDSTACK-348 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-348 Project: CloudStack Issue Type: Bug Reporter: Will Stevens Priority: Critical When deleting a network the resource count does not get updated correctly, so you will get to the point where you can have no networks and you will not be able to create more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-348) deleteNetwork does not clean up network resource count correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476291#comment-13476291 ] David Nalley commented on CLOUDSTACK-348: - what version is this on? deleteNetwork does not clean up network resource count correctly Key: CLOUDSTACK-348 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-348 Project: CloudStack Issue Type: Bug Reporter: Will Stevens Priority: Critical When deleting a network the resource count does not get updated correctly, so you will get to the point where you can have no networks and you will not be able to create more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-316) KVM Agent setup fails due to cloudbr0 set as public network interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama closed CLOUDSTACK-316. --- Successfully added a Ubuntu 12.04 KVM Host to the CloudStack Setup. The Host has the following bridge structure. root@Rack3Host17:~# brctl show bridge name bridge id STP enabled interfaces asfbr0 8000.bc305bd41c36 no eth0 asfbr1 8000.bc305bd41c37 no eth1 cloud0 8000. no virbr0 8000. yes root@Rack3Host17:~# root@Rack3Host17:~# ifconfig asfbr0Link encap:Ethernet HWaddr bc:30:5b:d4:1c:36 inet addr:10.223.59.2 Bcast:10.223.59.63 Mask:255.255.255.192 inet6 addr: fe80::be30:5bff:fed4:1c36/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:935551 errors:0 dropped:0 overruns:0 frame:0 TX packets:58913 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:199281936 (199.2 MB) TX bytes:4484904 (4.4 MB) asfbr1Link encap:Ethernet HWaddr bc:30:5b:d4:1c:37 UP BROADCAST 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) cloud0Link encap:Ethernet HWaddr fa:f5:3f:b1:11:38 inet addr:169.254.0.1 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::f8f5:3fff:feb1:1138/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:812 (812.0 B) eth0 Link encap:Ethernet HWaddr bc:30:5b:d4:1c:36 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3724402 errors:0 dropped:5207 overruns:0 frame:0 TX packets:58920 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2410731394 (2.4 GB) TX bytes:4740058 (4.7 MB) Interrupt:16 Memory:da00-da012800 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:2776 errors:0 dropped:0 overruns:0 frame:0 TX packets:2776 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:269616 (269.6 KB) TX bytes:269616 (269.6 KB) virbr0Link encap:Ethernet HWaddr 02:a3:5b:b0:58:b0 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 UP BROADCAST 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) root@Rack3Host17:~# root@Rack3Host17:~# ip route default via 10.223.59.1 dev asfbr0 metric 100 10.223.59.0/26 dev asfbr0 proto kernel scope link src 10.223.59.2 169.254.0.0/16 dev cloud0 proto kernel scope link src 169.254.0.1 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 root@Rack3Host17:~# Verified on Build with the following Info: This is the version information for the manifests in the JAR files. Implementation_Version: 2.2.20121012230921 KVM Agent setup fails due to cloudbr0 set as public network interface - Key: CLOUDSTACK-316 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-316 Project: CloudStack Issue Type: Bug Components: KVM, Management Server Affects Versions: 4.0.0 Environment: Ubuntu 12.04 CloudStack 4.0.0-incubator Reporter: Wido den Hollander Assignee: Wido den Hollander Fix For: 4.0.0 I just set up a fresh CloudStack 4.0 platform and tried to add a host via the wizard. My Basic network settings: - guest: vlanbr672 - private: vlanbr670 During the wizard there is never a prompt for the public network, you can only set the storage label, but I didn't do that. I kept waiting for the hypervisor to come online, but the agent wouldn't start. The log showed: 2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase] (main:null) Retrieving network interface: cloudbr0 2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase] (main:null) Unable to get network interface for cloudbr0 2012-10-11 14:55:46,835
[jira] [Commented] (CLOUDSTACK-348) deleteNetwork does not clean up network resource count correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476299#comment-13476299 ] Will Stevens commented on CLOUDSTACK-348: - This was produced on Burbank. I had Alena confirm that this is a bug and she said to assign this to her as a Critical bug for Byron, but I did not have enough privileges to do that. I am not sure which number versions are associated to the named versions, so I didn't assign it to a version. deleteNetwork does not clean up network resource count correctly Key: CLOUDSTACK-348 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-348 Project: CloudStack Issue Type: Bug Reporter: Will Stevens Priority: Critical When deleting a network the resource count does not get updated correctly, so you will get to the point where you can have no networks and you will not be able to create more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-348) deleteNetwork does not clean up network resource count correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley reassigned CLOUDSTACK-348: --- Assignee: Alena Prokharchyk deleteNetwork does not clean up network resource count correctly Key: CLOUDSTACK-348 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-348 Project: CloudStack Issue Type: Bug Reporter: Will Stevens Assignee: Alena Prokharchyk Priority: Critical When deleting a network the resource count does not get updated correctly, so you will get to the point where you can have no networks and you will not be able to create more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-347) listNetworks API: return vlan information only when the caller is ROOT admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-347. -- Resolution: Fixed Fixed with 1d458c7a2d0db3ad80721a4dfcbca4c6e991065d listNetworks API: return vlan information only when the caller is ROOT admin Key: CLOUDSTACK-347 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-347 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.0.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.1.0 As only ROOT admin should know physical network configuration, we shouldn't return Vlan information to the regular user / domain admin, as a part of listNetworks call -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-349) Russian l10n not properly displaying
David Nalley created CLOUDSTACK-349: --- Summary: Russian l10n not properly displaying Key: CLOUDSTACK-349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-349 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: pre-4.0.0 Reporter: David Nalley Assignee: Brian Federle Switching locale to Russian leaves one filled with a screen of question marks. I know you answered a question and posted some code to fix this, but it doesn't look like that code currently solves the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-349) Russian l10n not properly displaying
[ https://issues.apache.org/jira/browse/CLOUDSTACK-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley updated CLOUDSTACK-349: Attachment: snapshot6.png Russian l10n not properly displaying Key: CLOUDSTACK-349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-349 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: pre-4.0.0 Reporter: David Nalley Assignee: Brian Federle Attachments: snapshot6.png Switching locale to Russian leaves one filled with a screen of question marks. I know you answered a question and posted some code to fix this, but it doesn't look like that code currently solves the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RFC] QinQ vlans support
Ok, I'll pull out the changes and let people see them. Cloudstack seems to let me put the same vlan ranges on multiple physicals, though I haven't done much actual testing with large numbers of vlans. I imagine there would be other bottlenecks if they all needed to be up on the same host at once. Luckily we only create bridges for the actual VMs on the box so it should scale reasonably. The only caveat I've run into so far is that you either need to be running jumbo frames on your switches, or turn down the MTU on the guests a bit to accommodate the space taken by extra tag. If you wanted to run jumbo fames on the guests as well, you'd run into the same situation and have to use slightly less than the 9000 (although the virtual router would require a patch too for the new size). On Mon, Oct 15, 2012 at 9:56 AM, Ahmad Emneina ahmad.emne...@citrix.com wrote: On 10/15/12 8:35 AM, Kelceydamage@bbits kel...@bbits.ca wrote: That's a far more elegant way then I tried, which was creating tagged interfaces within guests. Sent from my iPhone On Oct 15, 2012, at 12:54 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: This sounds like it can be modeled as multiple physical networks? That is, each outer vlan (400, 401, etc) is a separate physical network in the same zone. That could work, although it is probable that the zone configuration API bits prevent more than 4k VLANs per zone (that can be changed to per physical network). As long as communication between guests on different physical networks happens via the public network, it should be Ok. I'd like to see the patch. Thanks On 10/12/12 1:09 AM, Marcus Sorensen shadow...@gmail.com wrote: Guys, in looking for a free and scalable way to provide private networks for customers I've been running a QinQ setup that has been working quite well. I've sort of laid the groundwork for it already in changing the bridge naming conventions about a month ago for KVM(to names that won't collide if the same vlans is used twice on different phys). Basically the way it works is like this. Linux has two ways of creating tagged networks, the eth#.# and the less used vlan# network devices. I have a tiny patch that causes cloudstack to treat vlan# devs as though they were physical NICs. In this way, you can do something like physical devices eth0,eth1,and vlan400. management traffic on eth0's bridge, storage on eth1.102's bridge, maybe eth1.103 for public/guest, then create say a vlan400 that is tag 400 on eth1. You add a traffic type of guest to it and give it a vlan range, say 10-4000. Then you end up with cloudstack handing out vlan400.10, vlan400.11, etc for guest networks. Works great for network isolation without burning through a bunch of your real vlans. In the unlikely event that you run out, you just create a physical vlan401 and start over with the vlan numbers. In theory all-you-can-eat isolated networks without having to configure hundreds of vlans on your networking equipment. This may require additional config on any upstream switches to pass the double tags around, but in general from what I've seen the inner tags just pass through on anything layer 2, it should only get tricky if you try to tunnel, route or strip tags. This is especially nice with system VM routers and VPC (cloudstack takes care of everything), but admittedly external routers probably will have spotty support for being able to route double tagged stuff. I'm also a bit afraid that if I were to get it merged in that it would just become this undocumented hack thing that few know about and nobody uses. So I'm looking for feedback on whether this sounds useful enough to commit, how it should be documented, and whether it makes sense to hint at this in the GUI somehow. +1 This actually sounds amazing Marcus. I'd love to see and use this implementation. -- Æ
[jira] [Created] (CLOUDSTACK-350) Storage stats in admin dashboard are not pragmatic
David Nalley created CLOUDSTACK-350: --- Summary: Storage stats in admin dashboard are not pragmatic Key: CLOUDSTACK-350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-350 Project: CloudStack Issue Type: Bug Reporter: David Nalley Priority: Minor UI reports storage seemingly at the byte level, with numbers like this: 105689374720 Why aren't there units, and if you must use really low level units like bytes, at least add commas to make it a bit more easily parseable. That said bytes is a really non-practical unit of measure for a cloud - MB, or even GB - and in some cases TB would be far more useful. I'll attach a screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-350) Storage stats in admin dashboard are not pragmatic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley updated CLOUDSTACK-350: Attachment: snapshot7.png Exactly how much capacity does it claim to be showing me? Storage stats in admin dashboard are not pragmatic -- Key: CLOUDSTACK-350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-350 Project: CloudStack Issue Type: Bug Reporter: David Nalley Priority: Minor Attachments: snapshot7.png UI reports storage seemingly at the byte level, with numbers like this: 105689374720 Why aren't there units, and if you must use really low level units like bytes, at least add commas to make it a bit more easily parseable. That said bytes is a really non-practical unit of measure for a cloud - MB, or even GB - and in some cases TB would be far more useful. I'll attach a screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-350) Storage stats in admin dashboard are not pragmatic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476380#comment-13476380 ] Chip Childers commented on CLOUDSTACK-350: -- The conversion should figure out what the meaningful *summary level* unit should be. For example, I would like to see the number in PBs when it's greater than 1,024 TBs. Storage stats in admin dashboard are not pragmatic -- Key: CLOUDSTACK-350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-350 Project: CloudStack Issue Type: Bug Reporter: David Nalley Priority: Minor Attachments: snapshot7.png UI reports storage seemingly at the byte level, with numbers like this: 105689374720 Why aren't there units, and if you must use really low level units like bytes, at least add commas to make it a bit more easily parseable. That said bytes is a really non-practical unit of measure for a cloud - MB, or even GB - and in some cases TB would be far more useful. I'll attach a screenshot -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-351) cloud-set-guest-password.in - include double quotes for variable check when using -n in bash
ilya musayev created CLOUDSTACK-351: --- Summary: cloud-set-guest-password.in - include double quotes for variable check when using -n in bash Key: CLOUDSTACK-351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-351 Project: CloudStack Issue Type: Bug Components: Usage Affects Versions: 4.0.0 Environment: RHEL/CENTOS 5.x/6.x and CS 3.x+/4.x+ Reporter: ilya musayev Priority: Minor Fix For: 4.0.0 include double quotes for variable check when using -n in bash - fixes one of issue when variable is present but not seen by bash -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-351) cloud-set-guest-password.in - include double quotes for variable check when using -n in bash
[
https://issues.apache.org/jira/browse/CLOUDSTACK-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ilya musayev resolved CLOUDSTACK-351.
-
Resolution: Fixed
diff --git a/setup/bindir/cloud-set-guest-password.in
b/setup/bindir/cloud-set-guest-password.in
index 97e6e3d..69be175 100755
--- a/setup/bindir/cloud-set-guest-password.in
+++ b/setup/bindir/cloud-set-guest-password.in
@@ -39,7 +39,7 @@ do
file_count=$((file_count+1))
PASSWORD_SERVER_IP=$(grep dhcp-server-identifier $DHCP_FILE |
tail -1 | awk '{print $NF}' | tr -d '\;')
- if [ -n $PASSWORD_SERVER_IP ]
+ if [ -n $PASSWORD_SERVER_IP ]
then
logger -t cloud Found password server IP
$PASSWORD_SERVER_IP in $DHCP_FILE
logger -t cloud Sending request to password server
at $PASSWORD_SERVER_IP
--
1.7.1
cloud-set-guest-password.in - include double quotes for variable check when
using -n in bash
Key: CLOUDSTACK-351
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-351
Project: CloudStack
Issue Type: Bug
Components: Usage
Affects Versions: 4.0.0
Environment: RHEL/CENTOS 5.x/6.x and CS 3.x+/4.x+
Reporter: ilya musayev
Priority: Minor
Labels: patch
Fix For: 4.0.0
Original Estimate: 10m
Remaining Estimate: 10m
include double quotes for variable check when using -n in bash - fixes one of
issue when variable is present but not seen by bash
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-351) cloud-set-guest-password.in - include double quotes for variable check when using -n in bash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476405#comment-13476405 ] David Nalley commented on CLOUDSTACK-351: - Ilya: Has someone committed this code into the repo? cloud-set-guest-password.in - include double quotes for variable check when using -n in bash Key: CLOUDSTACK-351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-351 Project: CloudStack Issue Type: Bug Components: Usage Affects Versions: 4.0.0 Environment: RHEL/CENTOS 5.x/6.x and CS 3.x+/4.x+ Reporter: ilya musayev Priority: Minor Labels: patch Fix For: 4.0.0 Original Estimate: 10m Remaining Estimate: 10m include double quotes for variable check when using -n in bash - fixes one of issue when variable is present but not seen by bash -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-349) Russian l10n not properly displaying
[ https://issues.apache.org/jira/browse/CLOUDSTACK-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476423#comment-13476423 ] Brian Federle commented on CLOUDSTACK-349: -- This doesn't look like an issue specific to the code, but rather the way the content was translated into ASCII. I noticed the message file uses escaped ASCII to render the characters, which may not be supported with Tomcat, but not entirely sure. Possibly this property file should just include the unicode Russian characters directly, which is how Japanese/Chinese files are handled. Russian l10n not properly displaying Key: CLOUDSTACK-349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-349 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: pre-4.0.0 Reporter: David Nalley Assignee: Brian Federle Attachments: snapshot6.png Switching locale to Russian leaves one filled with a screen of question marks. I know you answered a question and posted some code to fix this, but it doesn't look like that code currently solves the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-352) Dashboard View shows incorrect VM counts for Domain Admin
Min Chen created CLOUDSTACK-352: --- Summary: Dashboard View shows incorrect VM counts for Domain Admin Key: CLOUDSTACK-352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-352 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: 4.1.0 Reporter: Min Chen In Dashboard view, our UI only shows count of VMs owned by domain admin, but in Instance view, we are showing all the VMs that domain admin can view, which is IMHO a bit inconsistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-352) Dashboard View shows incorrect VM counts for Domain Admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-352: Attachment: domain_admin_instance_view.png domain_admin_view.png Dashboard View shows incorrect VM counts for Domain Admin - Key: CLOUDSTACK-352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-352 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: 4.1.0 Reporter: Min Chen Attachments: domain_admin_instance_view.png, domain_admin_view.png In Dashboard view, our UI only shows count of VMs owned by domain admin, but in Instance view, we are showing all the VMs that domain admin can view, which is IMHO a bit inconsistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-352) Dashboard View shows incorrect VM counts for Domain Admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-352: Description: In Dashboard view, our UI only shows count of VMs owned by domain admin, but in Instance view, we are showing all the VMs that domain admin can view, which is IMHO a bit inconsistent. See screenshots for details. (was: In Dashboard view, our UI only shows count of VMs owned by domain admin, but in Instance view, we are showing all the VMs that domain admin can view, which is IMHO a bit inconsistent.) Dashboard View shows incorrect VM counts for Domain Admin - Key: CLOUDSTACK-352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-352 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: 4.1.0 Reporter: Min Chen Attachments: domain_admin_instance_view.png, domain_admin_view.png In Dashboard view, our UI only shows count of VMs owned by domain admin, but in Instance view, we are showing all the VMs that domain admin can view, which is IMHO a bit inconsistent. See screenshots for details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-352) Dashboard View shows incorrect VM counts for Domain Admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sonny Chhen reassigned CLOUDSTACK-352: -- Assignee: Brian Federle Dashboard View shows incorrect VM counts for Domain Admin - Key: CLOUDSTACK-352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-352 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: 4.1.0 Reporter: Min Chen Assignee: Brian Federle Attachments: domain_admin_instance_view.png, domain_admin_view.png In Dashboard view, our UI only shows count of VMs owned by domain admin, but in Instance view, we are showing all the VMs that domain admin can view, which is IMHO a bit inconsistent. See screenshots for details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-352) Dashboard View shows incorrect VM counts for Domain Admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-352. -- Resolution: Fixed commit f72434261cdef69766bccadd886939cbf9c31467 (HEAD, refs/heads/master) Author: Brian Federle brian.fede...@citrix.com Date: Mon Oct 15 14:23:42 2012 -0700 CLOUDSTACK-352: Fix user dashboard VM count Pass listAll=true to user dashboard API call, so domain admin can see totals for all user VMs. Dashboard View shows incorrect VM counts for Domain Admin - Key: CLOUDSTACK-352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-352 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: 4.1.0 Reporter: Min Chen Assignee: Brian Federle Attachments: domain_admin_instance_view.png, domain_admin_view.png In Dashboard view, our UI only shows count of VMs owned by domain admin, but in Instance view, we are showing all the VMs that domain admin can view, which is IMHO a bit inconsistent. See screenshots for details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CLOUDSTACK-352) Dashboard View shows incorrect VM counts for Domain Admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476473#comment-13476473 ] Brian Federle edited comment on CLOUDSTACK-352 at 10/15/12 9:25 PM: commit f72434261cdef69766bccadd886939cbf9c31467 (HEAD, refs/heads/master) commit 4c85bf384d6c97846d0ed67a05f26007782e84ff (HEAD, refs/remotes/cloud/3.0.x, refs/heads/3.0.x) Author: Brian Federle brian.fede...@citrix.com Date: Mon Oct 15 14:23:42 2012 -0700 CLOUDSTACK-352: Fix user dashboard VM count Pass listAll=true to user dashboard API call, so domain admin can see totals for all user VMs. was (Author: bfederle): commit f72434261cdef69766bccadd886939cbf9c31467 (HEAD, refs/heads/master) Author: Brian Federle brian.fede...@citrix.com Date: Mon Oct 15 14:23:42 2012 -0700 CLOUDSTACK-352: Fix user dashboard VM count Pass listAll=true to user dashboard API call, so domain admin can see totals for all user VMs. Dashboard View shows incorrect VM counts for Domain Admin - Key: CLOUDSTACK-352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-352 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: 4.1.0 Reporter: Min Chen Assignee: Brian Federle Attachments: domain_admin_instance_view.png, domain_admin_view.png In Dashboard view, our UI only shows count of VMs owned by domain admin, but in Instance view, we are showing all the VMs that domain admin can view, which is IMHO a bit inconsistent. See screenshots for details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [jira] [Commented] (CLOUDSTACK-351) cloud-set-guest-password.in - include double quotes for variable check when using -n in bash
I don’t think anyone committed it - I posted it an hour ago. -Original Message- From: David Nalley (JIRA) [mailto:j...@apache.org] Sent: Monday, October 15, 2012 4:29 PM To: cloudstack-dev@incubator.apache.org Subject: [jira] [Commented] (CLOUDSTACK-351) cloud-set-guest-password.in - include double quotes for variable check when using -n in bash [ https://issues.apache.org/jira/browse/CLOUDSTACK-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476405#comment-13476405 ] David Nalley commented on CLOUDSTACK-351: - Ilya: Has someone committed this code into the repo? cloud-set-guest-password.in - include double quotes for variable check when using -n in bash -- -- Key: CLOUDSTACK-351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-351 Project: CloudStack Issue Type: Bug Components: Usage Affects Versions: 4.0.0 Environment: RHEL/CENTOS 5.x/6.x and CS 3.x+/4.x+ Reporter: ilya musayev Priority: Minor Labels: patch Fix For: 4.0.0 Original Estimate: 10m Remaining Estimate: 10m include double quotes for variable check when using -n in bash - fixes one of issue when variable is present but not seen by bash -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-351) cloud-set-guest-password.in - include double quotes for variable check when using -n in bash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476480#comment-13476480 ] Musayev, Ilya commented on CLOUDSTACK-351: -- I don’t think anyone committed it - I posted it an hour ago. cloud-set-guest-password.in - include double quotes for variable check when using -n in bash Key: CLOUDSTACK-351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-351 Project: CloudStack Issue Type: Bug Components: Usage Affects Versions: 4.0.0 Environment: RHEL/CENTOS 5.x/6.x and CS 3.x+/4.x+ Reporter: ilya musayev Priority: Minor Labels: patch Fix For: 4.0.0 Original Estimate: 10m Remaining Estimate: 10m include double quotes for variable check when using -n in bash - fixes one of issue when variable is present but not seen by bash -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-351) cloud-set-guest-password.in - include double quotes for variable check when using -n in bash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley reopened CLOUDSTACK-351: - OK, lets leave it open til someone does get it committed - otherwise it disappears off folks radars. Thanks for the patch btw. --David cloud-set-guest-password.in - include double quotes for variable check when using -n in bash Key: CLOUDSTACK-351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-351 Project: CloudStack Issue Type: Bug Components: Usage Affects Versions: 4.0.0 Environment: RHEL/CENTOS 5.x/6.x and CS 3.x+/4.x+ Reporter: ilya musayev Priority: Minor Labels: patch Fix For: 4.0.0 Original Estimate: 10m Remaining Estimate: 10m include double quotes for variable check when using -n in bash - fixes one of issue when variable is present but not seen by bash -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Display Name vs. Host Name in Instance View
Thanks Kelven for clear clarifications. Based on your comments: In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name The UI screenshot attached previously is wrong, right? Those are user VMs, host name are shown as the same as display name. -min From: Kelven Yang Sent: Monday, October 15, 2012 2:38 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View There are 3 types of names in CloudStack system. Display Name: as its name suggests Host name: a name will be used by guest VM to identify itself on network. If guest OS is linux, you can see it at your login prompt. If guest OS is windows, it is supposed to become its NetBIOS name (computer name). Host name can be used to form fully qualified Domain Name, but itself won't show as that. In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name Instance name: name like I-xx-xx, r-xx-xx, these are name used internally by CloudStack to match a VM object in CloudStack DB with the VM at hypervisor side through naming match rules. It's name convention is used by CloudStack VM-Sync process (not supposed to be exposed to end user) Kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:25 PM To: Kelven Yang kelven.y...@citrix.commailto:kelven.y...@citrix.com, #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Subject: RE: Display Name vs. Host Name in Instance View Then which code generated this hostname? Is it always the same as display name? During provisioning vm instance, I only provided display name through UI. Your explanation makes sense to me, feel that hostname should be something like full-qualified domain name. But see my screenshot, it does not show that way though. Thanks -min From: Kelven Yang Sent: Monday, October 15, 2012 2:21 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View Display name, as its name suggests, it is used for display purpose only. Can be of any arbitrate string Host Name is used to identify the machine on the network. Its name should follow rules from underlying network, for example, on a windows network, following NetBIOS naming convention. Kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:14 PM To: #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Subject: Display Name vs. Host Name in Instance View Hi there, Can somebody explain to me what is the difference between DisplayName and HostName column in VM instance view? See below screen shot: Here they shows same name for my provisioned instance. Host Name to me is a bit confusing term, since it may refer to the host where VM is provisioned. [cid:image001.png@01CDAAE3.80309CA0] Thanks -min
RE: Display Name vs. Host Name in Instance View
This is a recent UI regression. The column circled in red should be labeled as Name instead of Host Name. The regression was made by a check-in 17 days ago (2012-09-28 12:18:59) I'll notify the committer to revert or modify his check-in. [cid:image002.png@01CDAAE4.25B58190] From: Min Chen Sent: Monday, October 15, 2012 2:44 PM To: Kelven Yang; #Cloud - Engineering Cc: cloudstack-dev@incubator.apache.org Subject: RE: Display Name vs. Host Name in Instance View Thanks Kelven for clear clarifications. Based on your comments: In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name The UI screenshot attached previously is wrong, right? Those are user VMs, host name are shown as the same as display name. -min From: Kelven Yang Sent: Monday, October 15, 2012 2:38 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View There are 3 types of names in CloudStack system. Display Name: as its name suggests Host name: a name will be used by guest VM to identify itself on network. If guest OS is linux, you can see it at your login prompt. If guest OS is windows, it is supposed to become its NetBIOS name (computer name). Host name can be used to form fully qualified Domain Name, but itself won't show as that. In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name Instance name: name like I-xx-xx, r-xx-xx, these are name used internally by CloudStack to match a VM object in CloudStack DB with the VM at hypervisor side through naming match rules. It's name convention is used by CloudStack VM-Sync process (not supposed to be exposed to end user) Kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:25 PM To: Kelven Yang kelven.y...@citrix.commailto:kelven.y...@citrix.com, #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Subject: RE: Display Name vs. Host Name in Instance View Then which code generated this hostname? Is it always the same as display name? During provisioning vm instance, I only provided display name through UI. Your explanation makes sense to me, feel that hostname should be something like full-qualified domain name. But see my screenshot, it does not show that way though. Thanks -min From: Kelven Yang Sent: Monday, October 15, 2012 2:21 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View Display name, as its name suggests, it is used for display purpose only. Can be of any arbitrate string Host Name is used to identify the machine on the network. Its name should follow rules from underlying network, for example, on a windows network, following NetBIOS naming convention. Kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:14 PM To: #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Subject: Display Name vs. Host Name in Instance View Hi there, Can somebody explain to me what is the difference between DisplayName and HostName column in VM instance view? See below screen shot: Here they shows same name for my provisioned instance. Host Name to me is a bit confusing term, since it may refer to the host where VM is provisioned. [cid:image003.png@01CDAAE4.25B58190] Thanks -min
RE: Display Name vs. Host Name in Instance View
Thanks Jessica. Besides column header, I think that column value are also populated wrong. -min From: Jessica Wang Sent: Monday, October 15, 2012 2:50 PM To: Min Chen; Kelven Yang; #Cloud - Engineering Cc: cloudstack-dev@incubator.apache.org Subject: RE: Display Name vs. Host Name in Instance View This is a recent UI regression. The column circled in red should be labeled as Name instead of Host Name. The regression was made by a check-in 17 days ago (2012-09-28 12:18:59) I'll notify the committer to revert or modify his check-in. [cid:image001.png@01CDAAE4.A9271A70] From: Min Chen Sent: Monday, October 15, 2012 2:44 PM To: Kelven Yang; #Cloud - Engineering Cc: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org Subject: RE: Display Name vs. Host Name in Instance View Thanks Kelven for clear clarifications. Based on your comments: In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name The UI screenshot attached previously is wrong, right? Those are user VMs, host name are shown as the same as display name. -min From: Kelven Yang Sent: Monday, October 15, 2012 2:38 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View There are 3 types of names in CloudStack system. Display Name: as its name suggests Host name: a name will be used by guest VM to identify itself on network. If guest OS is linux, you can see it at your login prompt. If guest OS is windows, it is supposed to become its NetBIOS name (computer name). Host name can be used to form fully qualified Domain Name, but itself won't show as that. In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name Instance name: name like I-xx-xx, r-xx-xx, these are name used internally by CloudStack to match a VM object in CloudStack DB with the VM at hypervisor side through naming match rules. It's name convention is used by CloudStack VM-Sync process (not supposed to be exposed to end user) Kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:25 PM To: Kelven Yang kelven.y...@citrix.commailto:kelven.y...@citrix.com, #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Subject: RE: Display Name vs. Host Name in Instance View Then which code generated this hostname? Is it always the same as display name? During provisioning vm instance, I only provided display name through UI. Your explanation makes sense to me, feel that hostname should be something like full-qualified domain name. But see my screenshot, it does not show that way though. Thanks -min From: Kelven Yang Sent: Monday, October 15, 2012 2:21 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View Display name, as its name suggests, it is used for display purpose only. Can be of any arbitrate string Host Name is used to identify the machine on the network. Its name should follow rules from underlying network, for example, on a windows network, following NetBIOS naming convention. Kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:14 PM To: #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Subject: Display Name vs. Host Name in Instance View Hi there, Can somebody explain to me what is the difference between DisplayName and HostName column in VM instance view? See below screen shot: Here they shows same name for my provisioned instance. Host Name to me is a bit confusing term, since it may refer to the host where VM is provisioned. [cid:image002.png@01CDAAE4.A9271A70] Thanks -min
Stop instance is destroying my VM
Hi there, What did we internally invoke when user is stopping VM instance from CloudStack UI? It seems that it did more than shutdown VM from XenCenter. After this operation, my VM disappeared from XenCenter console. If I manually do shutdown from XenCenter UI, I can see that my VM is still there with stopped status. Thanks -min
Re: Display Name vs. Host Name in Instance View
I didn't follow recent changes related to these 3 types of names. I don't know that we introduced a new flag to control that. It makes sense to me for user to explicitly control VM's display name, however, for host name and instance name, it would become a burden for user to pick up a name explicitly that won't run into conflicts and is qualified name on the network, if we do allow user to pick names for that, we need to help maintain the semantic of having unique and qualified names for VM to be running smoothly on the network at run time. And especially for instance name, since its name convention is assumed by VM Sync logic in CloudStack, any change to it without updating VMSync logic may break hypervisor view and CloudStack view apart. kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:43 PM To: Kelven Yang kelven.y...@citrix.commailto:kelven.y...@citrix.com, #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Cc: cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org cloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org Subject: RE: Display Name vs. Host Name in Instance View Thanks Kelven for clear clarifications. Based on your comments: In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name The UI screenshot attached previously is wrong, right? Those are user VMs, host name are shown as the same as display name. -min From: Kelven Yang Sent: Monday, October 15, 2012 2:38 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View There are 3 types of names in CloudStack system. Display Name: as its name suggests Host name: a name will be used by guest VM to identify itself on network. If guest OS is linux, you can see it at your login prompt. If guest OS is windows, it is supposed to become its NetBIOS name (computer name). Host name can be used to form fully qualified Domain Name, but itself won't show as that. In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name Instance name: name like I-xx-xx, r-xx-xx, these are name used internally by CloudStack to match a VM object in CloudStack DB with the VM at hypervisor side through naming match rules. It's name convention is used by CloudStack VM-Sync process (not supposed to be exposed to end user) Kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:25 PM To: Kelven Yang kelven.y...@citrix.commailto:kelven.y...@citrix.com, #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Subject: RE: Display Name vs. Host Name in Instance View Then which code generated this hostname? Is it always the same as display name? During provisioning vm instance, I only provided display name through UI. Your explanation makes sense to me, feel that hostname should be something like full-qualified domain name. But see my screenshot, it does not show that way though. Thanks -min From: Kelven Yang Sent: Monday, October 15, 2012 2:21 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View Display name, as its name suggests, it is used for display purpose only. Can be of any arbitrate string Host Name is used to identify the machine on the network. Its name should follow rules from underlying network, for example, on a windows network, following NetBIOS naming convention. Kelven From: Min Chen min.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:14 PM To: #Cloud - Engineering engineer...@cloud.commailto:engineer...@cloud.com Subject: Display Name vs. Host Name in Instance View Hi there, Can somebody explain to me what is the difference between DisplayName and HostName column in VM instance view? See below screen shot: Here they shows same name for my provisioned instance. Host Name to me is a bit confusing term, since it may refer to the host where VM is provisioned. [cid:image001.png@01CDAAE3.80309CA0] Thanks -min
RE: UI: CloudStack UI Concept 2
I'm more inclined to the method that Marcus is suggesting as we had the paint method in the 2.2 ui and the implementation made it seem more like a bug than a feature. Thanks You and Best Regards, Sonny H. Chhen Manager of User Interface User Experience | Citrix Systems - CloudPlatform 4988 Great America Parkway, Santa Clara, CA 95054, USA -Original Message- From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Friday, October 12, 2012 11:24 AM To: cloudstack-dev@incubator.apache.org Subject: Re: UI: CloudStack UI Concept 2 Sort of like the shift+click to select multiple items, or a click+drag in Excel/Calc? On Fri, Oct 12, 2012 at 11:59 AM, Sebastien Goasguen run...@gmail.com wrote: Hi Sonny, Not quite, I was just thinking about painting over the VMs that you want to select before selecting the action. Say you have to select 1000 VMs, even though using the APIs is most likely going to be used, being able to quickly paint over to select them would be much easier than checking 1000 boxes. You probably know about 3tera (http://www.ca.com/us/cloud-platform.aspx), they had/have some crazy drag and drop on canvas GUI to manage VMs, it might be worth a look. -sebastien On Oct 12, 2012, at 7:48 PM, Sonny Chhen sonny.ch...@citrix.com wrote: Thanks Kelcey. Sebastian, Do you mean drag the selected vm's over the action icons? If so, this is and idea we can investigate. We also had a concept in the early days of CloudStack where one could group a bunch of vm's to apply actions to them or organize them. I'll post some samples if I find them. Thanks for the feedback. Thanks You and Best Regards, Sonny From: Kelcey Damage (BBITS) [kel...@bbits.ca] Sent: Friday, October 12, 2012 10:26 AM To: cloudstack-dev@incubator.apache.org Subject: RE: UI: CloudStack UI Concept 2 If drag and drop is permissible, considering the workload, I would think that might lead to a more intuitive interaction. KELCEY DAMAGE Infrastructure Systems Architect www.backbonetechnology.com - kel...@bbits.ca address: 55 East 7th Ave, Vancouver, BC, V5T 1M4 tel: +1 604 713 8560 ext:114 fax: +1 604 605 0964 skype: kelcey.damage -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: Friday, October 12, 2012 10:24 AM To: cloudstack-dev@incubator.apache.org Subject: Re: UI: CloudStack UI Concept 2 Hi Sonny, Couldn't we drag over the VMs we want to select, instead (or in addition) of the checkboxes ? -sebastien On Oct 12, 2012, at 7:18 PM, Sonny Chhen sonny.ch...@citrix.com wrote: Hello All, Below is a link to another ui concept as well as an idea for multi-vm select actions. As always, feedback is appreciated. https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+UI +concept+2 Thank You and Best Regards, Sonny H. Chhen Manager of User Interface User Experience | Citrix Systems - CloudPlatform 4988 Great America Parkway, Santa Clara, CA 95054, USA
RE: [DOCS] Proposed technique for making tooltips from doc XML files
Hello All, I have updated the functional spec on this feature at the link below. https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+-+Dynamic+Tooltip Please let me know if you have any questions or concerns. Thanks You and Best Regards, Sonny H. Chhen Manager of User Interface User Experience | Citrix Systems - CloudPlatform 4988 Great America Parkway, Santa Clara, CA 95054, USA -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Tuesday, October 09, 2012 6:51 PM To: cloudstack-dev@incubator.apache.org Subject: Re: [DOCS] Proposed technique for making tooltips from doc XML files On Tue, Oct 9, 2012 at 3:48 AM, Jessica Tomechak jessica.tomec...@gmail.com wrote: -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, September 28, 2012 6:43 PM To: cloudstack-dev@incubator.apache.org Cc: cloudstack-dev@incubator.apache.org Subject: Re: [DOCS] Proposed technique for making tooltips from doc XML files Sorry for top posting. Where is this roadmap you speak of? Functional spec? Link to the discussion about the feature? (or is this the initial discussion?) Link to demo? Does phraseid or any other tags you will use break anything in publican builds? Is this a connection over the network to get access to the content or are you bundling docs in the -client package? I understand what you are trying to do, but don't understand the mechanics of how you are planning to deliver the content. --David On Sep 28, 2012, at 1:44 PM, Jessica Tomechak jessica.tomec...@gmail.com wrote: There is an upcoming feature on the roadmap called context-sensitive help. We want to add help links and tool tips (1-sentence rollover popups) to the CloudStack UI. I've been working with the CloudStack UI guys on a way to pull tooltip strings right from the doc source files. This way, we don't have a separate resource file with out-of-sync texts. We can simply tag phrases in the XML source with unique identifiers, then the code can feed those strings into the UI by mapping our text identifiers to the UI element identifiers. We did a little demo of this and it works really well. Before I set about tagging everything in the doc repo with these tooltip identifiers, I wanted to see if we have any comments on the following: (1) Is context sensitive UI help high priority for Apache CloudStack? (2) Is the technique we came up with optimal? For our demo, we added human-readable IDs to the descriptions of some dialog box input fields, like so: section id=creating-network-offerings titleCreating a New Network Offering/title paraTo create a network offering:/para ... listitemparaClick Add Network Offering./para/listitem listitemparaIn the dialog, make the following choices:/para itemizedlist listitemparaName. phrase id=helpNetworkOfferingNameAny desired name for the network offering/phrase/para/listitem listitemparaDescription. phrase id=helpNetworkOfferingDescriptionA short description of the offering that can be displayed to users/phrase/para/listitem Jessica T. CloudStack Tech Pubs To answer David's Qs: No, this doesn't break the publican build. Publican takes no notice of the phrase tags at all. Link to discussion about the tooltip feature? Looking through cloudstack-dev archives, it looks like context-sensitive UI help links and tooltips have not been discussed as an Apache CloudStack feature. So maybe we should start that discussion! Functional spec? Don't think there is one. But I can ask the developer I worked with on the demo to write one up. Is it a connection over a network? No, not for tooltips. The phrases are pulled out of the /doc directory during the build, they are put into an intermediate JSON resource file, and then placed in the UI. You wouldn't need to hit the /doc directory live at runtime to get the popups. I don't know whether you have to ship the JSON file along with the build. Where you *would* need a network connection is for any Help links that go to larger topics. This is the sort of Help link you typically find in the upper-right corners of UI elements like forms, panels, tabs, and pages. We have envisioned making those go to URLs on the CloudStack documentation site -- most help links these days go out to the product information portal, rather than bundling a big help file with the software. This depends on the assumption that CS users have access to the Internet. If that assumption isn't good, we should re-think. Where is the roadmap? The roadmap link on the main cwiki.apache.org page points to the non-ASF page http://www.cloudstack.org/software/roadmap.html, which in turn points to the non-ASF pagehttp://wiki.cloudstack.org/display/PM/Campo. The actual feature we're talking about is tracked in bug
[jira] [Commented] (CLOUDSTACK-134) Document procedure to install vhd-util
[ https://issues.apache.org/jira/browse/CLOUDSTACK-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476538#comment-13476538 ] Jessica Tomechak commented on CLOUDSTACK-134: - So for now, installation is covered in INSTALL.md and also on the wiki at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+CloudStack+Development+Environment. Neither of these includes the vhd-util steps yet. If someone can reply to the question above, at what point in the installation steps would you install vhd-util, then I'd be happy to add the steps to one or both of these locations. Document procedure to install vhd-util -- Key: CLOUDSTACK-134 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-134 Project: CloudStack Issue Type: Task Components: Doc Affects Versions: pre-4.0.0 Reporter: edison su Assignee: Jessica Tomechak Priority: Blocker Fix For: 4.1.0 Due to license issue reported in CLOUDSTACK-30, vhd-util is removed from source code and packages. Need to document the procedure to download and install vhd-util during the mgt server installation. The current url is http://download.cloud.com.s3.amazonaws.com/tools/vhd-util If mgt server is rhel/centos, need to download from this url, then copy vhd-util into /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/ If mgt server is ubuntu, then put vhd-util into /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util (Chandan adds:) We should also document the requirement of setting the following permissions to the downloaded vhd-util tool: Chmod 755 vhd-util -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-134) Document procedure to install vhd-util
[ https://issues.apache.org/jira/browse/CLOUDSTACK-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476542#comment-13476542 ] edison su commented on CLOUDSTACK-134: -- Don't get the stuff too complicated... We just document that installing the vhd-util is a must, no matter which release/distribution you are using, if you want to use xen hypervisor: Due to license issue reported in CLOUDSTACK-30, vhd-util is removed from source code and packages. Need to document the procedure to download and install vhd-util during the mgt server installation. The current url is http://download.cloud.com.s3.amazonaws.com/tools/vhd-util If mgt server is rhel/centos, need to download from this url, then copy vhd-util into /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/ If mgt server is ubuntu, then put vhd-util into /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util (Chandan adds:) We should also document the requirement of setting the following permissions to the downloaded vhd-util tool: Chmod 755 vhd-util Document procedure to install vhd-util -- Key: CLOUDSTACK-134 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-134 Project: CloudStack Issue Type: Task Components: Doc Affects Versions: pre-4.0.0 Reporter: edison su Assignee: Jessica Tomechak Priority: Blocker Fix For: 4.1.0 Due to license issue reported in CLOUDSTACK-30, vhd-util is removed from source code and packages. Need to document the procedure to download and install vhd-util during the mgt server installation. The current url is http://download.cloud.com.s3.amazonaws.com/tools/vhd-util If mgt server is rhel/centos, need to download from this url, then copy vhd-util into /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/ If mgt server is ubuntu, then put vhd-util into /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util (Chandan adds:) We should also document the requirement of setting the following permissions to the downloaded vhd-util tool: Chmod 755 vhd-util -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-134) Document procedure to install vhd-util
[ https://issues.apache.org/jira/browse/CLOUDSTACK-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476546#comment-13476546 ] David Nalley commented on CLOUDSTACK-134: - Rohit: So two comments: 1. The wiki can't be our official documentation. (we allow anyone to participate there, we would have to restrict that to folks who are committers if we want our wiki to be our official project documentation) 2. The project is only distributing source builds. Wido is distributing his own binaries - which make no use of install.sh - and jenkins.cloudstack.org is producing builds with install.sh that aren't for general public consumption (the builds of the commit that is the current 4.0.0 are long since gone). So if the install documentation doesn't document installing - what are we doing shipping it? Or are you advocating for ditching the guides? --David Document procedure to install vhd-util -- Key: CLOUDSTACK-134 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-134 Project: CloudStack Issue Type: Task Components: Doc Affects Versions: pre-4.0.0 Reporter: edison su Assignee: Jessica Tomechak Priority: Blocker Fix For: 4.1.0 Due to license issue reported in CLOUDSTACK-30, vhd-util is removed from source code and packages. Need to document the procedure to download and install vhd-util during the mgt server installation. The current url is http://download.cloud.com.s3.amazonaws.com/tools/vhd-util If mgt server is rhel/centos, need to download from this url, then copy vhd-util into /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/ If mgt server is ubuntu, then put vhd-util into /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util (Chandan adds:) We should also document the requirement of setting the following permissions to the downloaded vhd-util tool: Chmod 755 vhd-util -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-353) Add support for virt-sysprep for template creation (and possibly VM deployment) on KVM
Kirk Kosinski created CLOUDSTACK-353: Summary: Add support for virt-sysprep for template creation (and possibly VM deployment) on KVM Key: CLOUDSTACK-353 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-353 Project: CloudStack Issue Type: Improvement Components: Hypervisor Controller, KVM, Template Affects Versions: pre-4.0.0 Reporter: Kirk Kosinski Priority: Minor On KVM, the virt-sysprep utility can be used to generalize a Linux VM disk image. In RHEL and Ubuntu, this tool is included in the libguestfs-tools package and the man page is here: http://libguestfs.org/virt-sysprep.1.html It would be useful if CloudStack could run virt-sysprep during the process of creating a template from a KVM VM. Such an option could be added to the createTemplate API and as a checkbox in the UI, and the person creating the template would not need to manually perform the tasks handled by virt-sysprep. Additionally, it might also be useful to have the option of running this tool on a VM immediately prior to booting it for the first time after deploying it, since someone might want or need to use existing templates that have not have been properly generalized. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-354) Display of storage statistics is wrong.
David Nalley created CLOUDSTACK-354: --- Summary: Display of storage statistics is wrong. Key: CLOUDSTACK-354 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-354 Project: CloudStack Issue Type: Bug Components: KVM, Storage Controller, UI Affects Versions: pre-4.0.0 Environment: 4.0.0 - second release vote, CentOS 6.3 - KVM Reporter: David Nalley Priority: Critical UI Statistics seem inversely calculated UI is reporting local storage as having 100660162560 of 105689374720 bytes consumed. KVM node 1 has the following stats: /dev/mapper/vg_supv-lv_root 50G 3.3G 44G 8% / which is really 3436224 45548476 in megabytes KVM node2 has the following stats: /dev/mapper/vg_kvm2-lv_root 50G 1.5G 46G 4% / which is really 1486956 47497744 Combining the two available MB figures comes up with 93046220 available, or rather 94% free - rather than 95% consumed Here is what virsh shows for one fo the local storage pools: virsh # pool-info 11d434ae-d61a-44a3-8bb9-8eba8ac8b015 Name: 11d434ae-d61a-44a3-8bb9-8eba8ac8b015 UUID: 11d434ae-d61a-44a3-8bb9-8eba8ac8b015 State: running Persistent: yes Autostart: no Capacity: 49.22 GB Allocation: 1.42 GB Available: 47.80 GB And here is the response to a listStoragePools - which likewise shows almost zero usage for the local storage pools ?xml version=1.0 encoding=UTF-8? liststoragepoolsresponse cloud-stack-version=4.0.0.20121014100600 count3/count storagepool idd2f59dd8-2b28-42f0-bd3b-d7e3f4413f47/id zoneidd06193b2-7980-4ad1-b5d8-7b2f2eda63c3/zoneid zonenameSanJose/zonename podid885d2dc4-8bc8-4f91-b1dd-78b19a2a9fc8/podid podnamePOD1/podname namesupv.cloudstack.org/name ipaddress10.208.38.2/ipaddress path/var/lib/libvirt/images//path created2012-10-14T20:57:36-0400/created typeFilesystem/type clusteridcc6d5a86-c57b-43d0-b927-ee60556c38a1/clusterid clusternamecluster1/clustername disksizetotal52844687360/disksizetotal disksizeallocated0/disksizeallocated disksizeused3524911104/disksizeused tags/tags stateUp/state /storagepool storagepool idb55460a5-00f9-3eae-9d41-a95100c328d0/id zoneidd06193b2-7980-4ad1-b5d8-7b2f2eda63c3/zoneid zonenameSanJose/zonenamepodid885d2dc4-8bc8-4f91-b1dd-78b19a2a9fc8/podid podnamePOD1/podname namenfs1/name ipaddress10.208.38.2/ipaddress path/home/primary/path created2012-10-14T21:25:08-0400/created typeNetworkFilesystem/type clusteridcc6d5a86-c57b-43d0-b927-ee60556c38a1/clusterid clusternamecluster1/clustername disksizetotal174001750016/disksizetotal disksizeallocated725950464/disksizeallocated disksizeused4471128064/disksizeused tags/tags stateUp/state /storagepool storagepool id11d434ae-d61a-44a3-8bb9-8eba8ac8b015/id zoneidd06193b2-7980-4ad1-b5d8-7b2f2eda63c3/zoneid zonenameSanJose/zonenamepodid885d2dc4-8bc8-4f91-b1dd-78b19a2a9fc8/podid podnamePOD1/podname namekvm2.cloudstack.org/name ipaddress10.208.38.3/ipaddress path/var/lib/libvirt/images//path created2012-10-15T01:31:53-0400/created typeFilesystem/type clusteridcc6d5a86-c57b-43d0-b927-ee60556c38a1/clusterid clusternamecluster1/clustername disksizetotal52844687360/disksizetotal disksizeallocated0/disksizeallocated disksizeused1522647040/disksizeused tags/tags stateUp/state /storagepool /liststoragepoolsresponse -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Display Name vs. Host Name in Instance View
If it all helps, I can contribute a script that inspects Linux DisplayName(or what's displayed in CS UI) and makes it part of cloud service script that runs once when OS starts for the firs time. On start, it will do API call to a router VM and check if current hostname matches the CS UI name, if not - it will set the hostname accordingly. On Oct 15, 2012, at 6:15 PM, Kelven Yang kelven.y...@citrix.commailto:kelven.y...@citrix.com wrote: I didn't follow recent changes related to these 3 types of names. I don't know that we introduced a new flag to control that. It makes sense to me for user to explicitly control VM's display name, however, for host name and instance name, it would become a burden for user to pick up a name explicitly that won't run into conflicts and is qualified name on the network, if we do allow user to pick names for that, we need to help maintain the semantic of having unique and qualified names for VM to be running smoothly on the network at run time. And especially for instance name, since its name convention is assumed by VM Sync logic in CloudStack, any change to it without updating VMSync logic may break hypervisor view and CloudStack view apart. kelven From: Min Chen mailto:min.c...@citrix.commin.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:43 PM To: Kelven Yang mailto:kelven.y...@citrix.comkelven.y...@citrix.commailto:kelven.y...@citrix.com, #Cloud - Engineering mailto:engineer...@cloud.comengineer...@cloud.commailto:engineer...@cloud.com Cc: mailto:cloudstack-dev@incubator.apache.orgcloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org mailto:cloudstack-dev@incubator.apache.orgcloudstack-dev@incubator.apache.orgmailto:cloudstack-dev@incubator.apache.org Subject: RE: Display Name vs. Host Name in Instance View Thanks Kelven for clear clarifications. Based on your comments: In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name The UI screenshot attached previously is wrong, right? Those are user VMs, host name are shown as the same as display name. -min From: Kelven Yang Sent: Monday, October 15, 2012 2:38 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View There are 3 types of names in CloudStack system. Display Name: as its name suggests Host name: a name will be used by guest VM to identify itself on network. If guest OS is linux, you can see it at your login prompt. If guest OS is windows, it is supposed to become its NetBIOS name (computer name). Host name can be used to form fully qualified Domain Name, but itself won't show as that. In 3.0.x, host name is given by default as UUID name for user Vms, for system Vms, host name is given the same as its instance name Instance name: name like I-xx-xx, r-xx-xx, these are name used internally by CloudStack to match a VM object in CloudStack DB with the VM at hypervisor side through naming match rules. It's name convention is used by CloudStack VM-Sync process (not supposed to be exposed to end user) Kelven From: Min Chen mailto:min.c...@citrix.commin.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:25 PM To: Kelven Yang mailto:kelven.y...@citrix.comkelven.y...@citrix.commailto:kelven.y...@citrix.com, #Cloud - Engineering mailto:engineer...@cloud.comengineer...@cloud.commailto:engineer...@cloud.com Subject: RE: Display Name vs. Host Name in Instance View Then which code generated this hostname? Is it always the same as display name? During provisioning vm instance, I only provided display name through UI. Your explanation makes sense to me, feel that hostname should be something like full-qualified domain name. But see my screenshot, it does not show that way though. Thanks -min From: Kelven Yang Sent: Monday, October 15, 2012 2:21 PM To: Min Chen; #Cloud - Engineering Subject: Re: Display Name vs. Host Name in Instance View Display name, as its name suggests, it is used for display purpose only. Can be of any arbitrate string Host Name is used to identify the machine on the network. Its name should follow rules from underlying network, for example, on a windows network, following NetBIOS naming convention. Kelven From: Min Chen mailto:min.c...@citrix.commin.c...@citrix.commailto:min.c...@citrix.com Date: Monday, October 15, 2012 2:14 PM To: #Cloud - Engineering mailto:engineer...@cloud.comengineer...@cloud.commailto:engineer...@cloud.com Subject: Display Name vs. Host Name in Instance View Hi there, Can somebody explain to me what is the difference between DisplayName and HostName column in VM instance view? See below screen shot: Here they shows same name for my provisioned instance. Host Name to me is a bit confusing term, since it may refer to the host where VM is provisioned. [cid:image001.png@01CDAAE3.80309CA0] Thanks
RE: Display Name vs. Host Name in Instance View
David Are you referring to this cloud init? https://code.launchpad.net/~lcosmin/cloud-init/cloudstack Thanks ilya -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Monday, October 15, 2012 8:00 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Display Name vs. Host Name in Instance View On Mon, Oct 15, 2012 at 7:53 PM, Musayev, Ilya imusa...@webmd.net wrote: If it all helps, I can contribute a script that inspects Linux DisplayName(or what's displayed in CS UI) and makes it part of cloud service script that runs once when OS starts for the firs time. On start, it will do API call to a router VM and check if current hostname matches the CS UI name, if not - it will set the hostname accordingly. DHCP should handle this sanely in most cases. Where it doesn't, we should use tools like cloud-init, IMO --David
Patch for CS3.x
I made a patch to address LDAP access issue on CS3.0 branch, I was curious if it's still being maintained, if so, I will can submit a patch, I'm bit uncertain on the process though for 3.0x. Regards ilya
[jira] [Commented] (CLOUDSTACK-332) count property in list* API response should be equal to how many entries in database, not how many objects in API response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476630#comment-13476630 ] Alena Prokharchyk commented on CLOUDSTACK-332: -- commit 3f5733cea741420381d5767fba84224388096525 fixes apis: listVlanIpRanges listOsCategories listOsTypes listSystemVms listPhysicalNetworks listCounters listConditions listAutoScalePolicies listAutoScaleVmProfiles listAutoScaleVmGroups listConfigurations listStoragePools listClusters listPods listInstanceGroups listSSHKeyPairs listHypervisorCapabilities listNetworkServiceProviders listVpnCustomerGateways listVpnGateways listVpnConnections listProjects listProjectAccounts listProjectInvitations listTrafficTypes count property in list* API response should be equal to how many entries in database, not how many objects in API response Key: CLOUDSTACK-332 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-332 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.0.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.1.0 e.g. If there are 8500 entries in database satisfying the search criteria (parameters in list api call), list* API returns 500 objects in API response, count property in API response should be 8500 instead of 500. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-332) count property in list* API response should be equal to how many entries in database, not how many objects in API response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476629#comment-13476629 ] Alena Prokharchyk commented on CLOUDSTACK-332: -- Commit 8f2d9a09e546e42a01b1cb7dceb2a7f129811a0d fixes APIs below: = listVolumes listVirtualMachines listSnapshots listRouters listFirewallRules listPortForwardingRules listLoadBalancerRules listIpForwardingRules listAccounts listUsers listDomains listDomainChildren listPublicIpAddresses listAlerts listAsyncJobs listRemoteAccessVpns listVpnUsers listTags listPrivateGateways listNetworkACLs listStaticRoutes count property in list* API response should be equal to how many entries in database, not how many objects in API response Key: CLOUDSTACK-332 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-332 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.0.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.1.0 e.g. If there are 8500 entries in database satisfying the search criteria (parameters in list api call), list* API returns 500 objects in API response, count property in API response should be 8500 instead of 500. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-332) count property in list* API response should be equal to how many entries in database, not how many objects in API response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476634#comment-13476634 ] Alena Prokharchyk commented on CLOUDSTACK-332: -- For qa - all commands mentioned in 2 prev comments have to be tested. Also test that the count is right in JSON and XML response. The rest of the commands will be fixed in the next release - as a part of refactoring Min Chen is doing for Search. The reasons why it wasn't fixed with the current commits: * for some commands multiple DB queries are done to get the result set + the result set is being modified later on. So with the current logic it's hard to figure out what is the actual number of objects in the DB matching the search criteria passed in API request. Only when Min puts her fixes for Search Engine, it would be possible to resolve the rest of the API commands. count property in list* API response should be equal to how many entries in database, not how many objects in API response Key: CLOUDSTACK-332 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-332 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.0.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.1.0 e.g. If there are 8500 entries in database satisfying the search criteria (parameters in list api call), list* API returns 500 objects in API response, count property in API response should be 8500 instead of 500. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-332) count property in list* API response should be equal to how many entries in database, not how many objects in API response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-332. -- Resolution: Fixed count property in list* API response should be equal to how many entries in database, not how many objects in API response Key: CLOUDSTACK-332 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-332 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.0.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.1.0 e.g. If there are 8500 entries in database satisfying the search criteria (parameters in list api call), list* API returns 500 objects in API response, count property in API response should be 8500 instead of 500. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-355) Fix count in a bunch of API commands
Alena Prokharchyk created CLOUDSTACK-355: Summary: Fix count in a bunch of API commands Key: CLOUDSTACK-355 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-355 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.1.0 Reporter: Alena Prokharchyk Assignee: Min Chen Fix For: 4.1.0 Count should be fixed for following list commands (as a part of Search Engine refactoring) listResourceLimits listIsos listTemplates listLoadBalancerRuleInstances listCapacity listHosts listSecurityGroups listNetworks listVPCs listTemplatePermissions listIsoPermissions listServiceOfferings listDiskOfferings listNetworkDevice listVPCOfferings listTrafficTypeImplementors listSnapshotPolicies listLBStickinessPolicies listCapabilities listZones listEventTypes listSwifts listHypervisors listNetworkOfferings listSupportedNetworkServices listStorageNetworkIpRange listEvents -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-348) deleteNetwork does not clean up network resource count correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476640#comment-13476640 ] Alena Prokharchyk commented on CLOUDSTACK-348: -- Dave, the bug exists in 4.0 release. deleteNetwork does not clean up network resource count correctly Key: CLOUDSTACK-348 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-348 Project: CloudStack Issue Type: Bug Affects Versions: 4.0.0 Reporter: Will Stevens Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.1.0 When deleting a network the resource count does not get updated correctly, so you will get to the point where you can have no networks and you will not be able to create more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Review Request: kvm agent NIC unplug will always fail
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7612/ --- Review request for cloudstack. Description --- On kvm computing host, vifdriver.unplug will always fails (throws LibvirtException) and network cleanup will not be called. This was because the code first undefine the computing domain, and then tries to query the destroyed machine definition to fetch NIC information. IMHO, kvm plugin code rounds LibvirtException too much. Diffs - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 1bc70fa Diff: https://reviews.apache.org/r/7612/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Stop instance is destroying my VM
It's by design, when you stop a VM (advanceStop() in VirtualMachineManagerImpl) in CloudStack UI, it will delete all the vm metadata info from xenserver database, it will reconstruct the vm profile to xenserver db when you start again (advanceStart() in VirtualMachineManagerImpl). It's easy to keep vm profile consistency since the only reference is cloudstack database. On Tue, Oct 16, 2012 at 6:12 AM, Min Chen min.c...@citrix.com wrote: Hi there, What did we internally invoke when user is stopping VM instance from CloudStack UI? It seems that it did more than shutdown VM from XenCenter. After this operation, my VM disappeared from XenCenter console. If I manually do shutdown from XenCenter UI, I can see that my VM is still there with stopped status. Thanks -min -- Gavin
[jira] [Resolved] (CLOUDSTACK-349) Russian l10n not properly displaying
[ https://issues.apache.org/jira/browse/CLOUDSTACK-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley resolved CLOUDSTACK-349. - Resolution: Fixed Brian - this was character encoding - ironically it displayed properly in transifex's web console, but not in the text file. coverting character set seems to have resolved it Russian l10n not properly displaying Key: CLOUDSTACK-349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-349 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: pre-4.0.0 Reporter: David Nalley Assignee: Jessica Wang Attachments: snapshot6.png Switching locale to Russian leaves one filled with a screen of question marks. I know you answered a question and posted some code to fix this, but it doesn't look like that code currently solves the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-134) Document procedure to install vhd-util
[ https://issues.apache.org/jira/browse/CLOUDSTACK-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476713#comment-13476713 ] Radhika Nair commented on CLOUDSTACK-134: - David, I am still unclear about the exact upgrade steps. Currently, i have updated it and pointed to the Wiki link. Please correct it. Document procedure to install vhd-util -- Key: CLOUDSTACK-134 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-134 Project: CloudStack Issue Type: Task Components: Doc Affects Versions: pre-4.0.0 Reporter: edison su Assignee: Jessica Tomechak Priority: Blocker Fix For: 4.1.0 Due to license issue reported in CLOUDSTACK-30, vhd-util is removed from source code and packages. Need to document the procedure to download and install vhd-util during the mgt server installation. The current url is http://download.cloud.com.s3.amazonaws.com/tools/vhd-util If mgt server is rhel/centos, need to download from this url, then copy vhd-util into /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/ If mgt server is ubuntu, then put vhd-util into /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util (Chandan adds:) We should also document the requirement of setting the following permissions to the downloaded vhd-util tool: Chmod 755 vhd-util -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-303) Upgrade instructions in the 4.0 release notes are wrong.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476716#comment-13476716 ] Radhika Nair commented on CLOUDSTACK-303: - David, I am still unclear about the exact upgrade steps. Currently, i have updated it and pointed to the Wiki link. Please correct it. Upgrade instructions in the 4.0 release notes are wrong. Key: CLOUDSTACK-303 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-303 Project: CloudStack Issue Type: Bug Components: Doc Affects Versions: pre-4.0.0 Reporter: Chip Childers Assignee: Radhika Nair Fix For: 4.0.0 The upgrade instructions are inaccurate. We are not distributing binary files as a project, although we have a community member providing package distributions. Neither of these distro types include the install.sh script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-303) Upgrade instructions in the 4.0 release notes are wrong.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair reopened CLOUDSTACK-303: - correcting the workflow as per David's suggestions Upgrade instructions in the 4.0 release notes are wrong. Key: CLOUDSTACK-303 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-303 Project: CloudStack Issue Type: Bug Components: Doc Affects Versions: pre-4.0.0 Reporter: Chip Childers Assignee: Radhika Nair Fix For: 4.0.0 The upgrade instructions are inaccurate. We are not distributing binary files as a project, although we have a community member providing package distributions. Neither of these distro types include the install.sh script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CLOUDSTACK-303) Upgrade instructions in the 4.0 release notes are wrong.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476716#comment-13476716 ] Radhika Nair edited comment on CLOUDSTACK-303 at 10/16/12 4:17 AM: --- David, Still unclear about the exact upgrade steps if install.sh is not used. Currently, i have updated it and pointed to the Wiki link. Please help correcting it. was (Author: radhikap): David, I am still unclear about the exact upgrade steps. Currently, i have updated it and pointed to the Wiki link. Please correct it. Upgrade instructions in the 4.0 release notes are wrong. Key: CLOUDSTACK-303 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-303 Project: CloudStack Issue Type: Bug Components: Doc Affects Versions: pre-4.0.0 Reporter: Chip Childers Assignee: Radhika Nair Fix For: 4.0.0 The upgrade instructions are inaccurate. We are not distributing binary files as a project, although we have a community member providing package distributions. Neither of these distro types include the install.sh script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CLOUDSTACK-134) Document procedure to install vhd-util
[ https://issues.apache.org/jira/browse/CLOUDSTACK-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476713#comment-13476713 ] Radhika Nair edited comment on CLOUDSTACK-134 at 10/16/12 4:17 AM: --- David, Still unclear about the exact upgrade steps if install.sh is not used. Currently, i have updated it and pointed to the Wiki link. Please help correcting it. was (Author: radhikap): David, I am still unclear about the exact upgrade steps. Currently, i have updated it and pointed to the Wiki link. Please correct it. Document procedure to install vhd-util -- Key: CLOUDSTACK-134 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-134 Project: CloudStack Issue Type: Task Components: Doc Affects Versions: pre-4.0.0 Reporter: edison su Assignee: Jessica Tomechak Priority: Blocker Fix For: 4.1.0 Due to license issue reported in CLOUDSTACK-30, vhd-util is removed from source code and packages. Need to document the procedure to download and install vhd-util during the mgt server installation. The current url is http://download.cloud.com.s3.amazonaws.com/tools/vhd-util If mgt server is rhel/centos, need to download from this url, then copy vhd-util into /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/ If mgt server is ubuntu, then put vhd-util into /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util (Chandan adds:) We should also document the requirement of setting the following permissions to the downloaded vhd-util tool: Chmod 755 vhd-util -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CLOUDSTACK-303) Upgrade instructions in the 4.0 release notes are wrong.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476716#comment-13476716 ] Radhika Nair edited comment on CLOUDSTACK-303 at 10/16/12 4:21 AM: --- David, Still unclear about the exact upgrade steps if install.sh is not used. Currently, i have updated to point to the Wiki link. Please help correcting it. was (Author: radhikap): David, Still unclear about the exact upgrade steps if install.sh is not used. Currently, i have updated it and pointed to the Wiki link. Please help correcting it. Upgrade instructions in the 4.0 release notes are wrong. Key: CLOUDSTACK-303 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-303 Project: CloudStack Issue Type: Bug Components: Doc Affects Versions: pre-4.0.0 Reporter: Chip Childers Assignee: Radhika Nair Fix For: 4.0.0 The upgrade instructions are inaccurate. We are not distributing binary files as a project, although we have a community member providing package distributions. Neither of these distro types include the install.sh script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-351) cloud-set-guest-password.in - include double quotes for variable check when using -n in bash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476761#comment-13476761 ] Rohit Yadav commented on CLOUDSTACK-351: Thanks for the patch Musayev, Ilya cloud-set-guest-password.in - include double quotes for variable check when using -n in bash Key: CLOUDSTACK-351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-351 Project: CloudStack Issue Type: Bug Components: Usage Affects Versions: 4.0.0 Environment: RHEL/CENTOS 5.x/6.x and CS 3.x+/4.x+ Reporter: ilya musayev Assignee: Rohit Yadav Priority: Minor Labels: patch Fix For: 4.0.0 Original Estimate: 10m Remaining Estimate: 10m include double quotes for variable check when using -n in bash - fixes one of issue when variable is present but not seen by bash -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-356) snapshot errors with multiple secondary storage in one zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] deepti dohare reassigned CLOUDSTACK-356: Assignee: deepti dohare snapshot errors with multiple secondary storage in one zone --- Key: CLOUDSTACK-356 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-356 Project: CloudStack Issue Type: Bug Components: Snapshot Affects Versions: pre-4.0.0 Reporter: deepti dohare Assignee: deepti dohare Fix For: 4.1.0 BRIEF SYNOPSIS: Snapshots are failing inder some cases where the host has already mounted other secondary storage and snapshot command has been issued to it ENVIRONMENT CS 2.2.14 + XEN server DETAILED DESCRIPTION 1) Noticcing following error for some snapshots 2012-07-23 02:16:38,120 WARN [xen.resource.CitrixResourceBase] (DirectAgent-281:null) Task failed! Task record: uuid: f0642eda-6e40-8bca-1ffb-bbf52a0e307e status: FAILURE errorInfo: [XENAPI_PLUGIN_FAILURE, backupSnapshot, SROSError, Error reporting error, unknown key File /var/run/cloud_mount/1/snapshots/35/2521/a05404cd-e2c7-41cf-9972-aa019ab79494.vhd does not exist.] 2) Cluster has investigated the issue and they found that mount points are not identical for the xenservers to the secondary storages across a cluster (df) : * host 1 : 10.16.36.64:/RAID10-DATA01/secsatxen002/snapshots 2147483648 240044032 1907439616 12% /var/run/cloud_mount/1/snapshots * Host 2 : 10.16.36.64:/RAID10-DATA01/secsatxen001/snapshots 2147483648 569533440 1577950208 27% /var/run/cloud_mount/1/snapshots Therefore, the contents are not identical in the 2 secondary storages (this is right to my understanding, because multiple secondary storage permit to scale horizontally) : * Host 1 : * -rw-r--r--+ 1 nobody nobody 307M 2012-07-23 16:11 07ba46c7-0908-4402-b20a-5ddd29a65d17.vhd * -rw-r--r--+ 1 nobody nobody 301M 2012-07-18 02:18 1c378e6a-0eba-48d9-8545-ab9fa09b9ba0.vhd * -rw-r--r--+ 1 nobody nobody 59M 2012-07-19 02:18 3b7e8c19-ba9c-433e-ac18-f52d4ad42be9.vhd * -rw-r--r--+ 1 nobody nobody 97M 2012-07-20 02:19 4644362a-764d-4c66-a038-168127007a5f.vhd * -rw-r--r--+ 1 nobody nobody 47M 2012-07-23 02:18 72e54c85-8245-4b84-b4b5-5a1ef2b44e52.vhd * -rw-r--r--+ 1 nobody nobody 69M 2012-07-21 02:18 76301f19-fcc0-43ac-adab-cde2cf23bd87.vhd * -rw-r--r--+ 1 nobody nobody 57M 2012-07-22 02:18 a05404cd-e2c7-41cf-9972-aa019ab79494.vhd * Host 2 : empty A simple workaround is to migrate the corresponding instance to the host with the right mount. After further checking, this behavior is encountered on all clusters, only rarely because only applying to instances that : * Have a scheduled snapshot retention policy * Have either migrated, been restarted on a different host than previous run Though workaround is feasible but it is difficult to predict when the user seems this probelm. please check if there is any problem in cloudstack logic to ensure right mount secondary mount point is available and create it if it doesnt exist If this behaviour confirms to be a bug,please file one bug in jira. REPRO STEPS == You can try reproducing the scenario by havign two secondary storages and continuously taking snapshots EXPECTED BEHAVIOR == Cloudstack should create correct mount of secondary storage if it doesnt exist. It should never use other secondary storage mount point. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-356) snapshot errors with multiple secondary storage in one zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476773#comment-13476773 ] deepti dohare commented on CLOUDSTACK-356: -- Submitted a patch on Review Board: https://reviews.apache.org/r/7594/ snapshot errors with multiple secondary storage in one zone --- Key: CLOUDSTACK-356 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-356 Project: CloudStack Issue Type: Bug Components: Snapshot Affects Versions: pre-4.0.0 Reporter: deepti dohare Assignee: deepti dohare Fix For: 4.1.0 BRIEF SYNOPSIS: Snapshots are failing inder some cases where the host has already mounted other secondary storage and snapshot command has been issued to it ENVIRONMENT CS 2.2.14 + XEN server DETAILED DESCRIPTION 1) Noticcing following error for some snapshots 2012-07-23 02:16:38,120 WARN [xen.resource.CitrixResourceBase] (DirectAgent-281:null) Task failed! Task record: uuid: f0642eda-6e40-8bca-1ffb-bbf52a0e307e status: FAILURE errorInfo: [XENAPI_PLUGIN_FAILURE, backupSnapshot, SROSError, Error reporting error, unknown key File /var/run/cloud_mount/1/snapshots/35/2521/a05404cd-e2c7-41cf-9972-aa019ab79494.vhd does not exist.] 2) Cluster has investigated the issue and they found that mount points are not identical for the xenservers to the secondary storages across a cluster (df) : * host 1 : 10.16.36.64:/RAID10-DATA01/secsatxen002/snapshots 2147483648 240044032 1907439616 12% /var/run/cloud_mount/1/snapshots * Host 2 : 10.16.36.64:/RAID10-DATA01/secsatxen001/snapshots 2147483648 569533440 1577950208 27% /var/run/cloud_mount/1/snapshots Therefore, the contents are not identical in the 2 secondary storages (this is right to my understanding, because multiple secondary storage permit to scale horizontally) : * Host 1 : * -rw-r--r--+ 1 nobody nobody 307M 2012-07-23 16:11 07ba46c7-0908-4402-b20a-5ddd29a65d17.vhd * -rw-r--r--+ 1 nobody nobody 301M 2012-07-18 02:18 1c378e6a-0eba-48d9-8545-ab9fa09b9ba0.vhd * -rw-r--r--+ 1 nobody nobody 59M 2012-07-19 02:18 3b7e8c19-ba9c-433e-ac18-f52d4ad42be9.vhd * -rw-r--r--+ 1 nobody nobody 97M 2012-07-20 02:19 4644362a-764d-4c66-a038-168127007a5f.vhd * -rw-r--r--+ 1 nobody nobody 47M 2012-07-23 02:18 72e54c85-8245-4b84-b4b5-5a1ef2b44e52.vhd * -rw-r--r--+ 1 nobody nobody 69M 2012-07-21 02:18 76301f19-fcc0-43ac-adab-cde2cf23bd87.vhd * -rw-r--r--+ 1 nobody nobody 57M 2012-07-22 02:18 a05404cd-e2c7-41cf-9972-aa019ab79494.vhd * Host 2 : empty A simple workaround is to migrate the corresponding instance to the host with the right mount. After further checking, this behavior is encountered on all clusters, only rarely because only applying to instances that : * Have a scheduled snapshot retention policy * Have either migrated, been restarted on a different host than previous run Though workaround is feasible but it is difficult to predict when the user seems this probelm. please check if there is any problem in cloudstack logic to ensure right mount secondary mount point is available and create it if it doesnt exist If this behaviour confirms to be a bug,please file one bug in jira. REPRO STEPS == You can try reproducing the scenario by havign two secondary storages and continuously taking snapshots EXPECTED BEHAVIOR == Cloudstack should create correct mount of secondary storage if it doesnt exist. It should never use other secondary storage mount point. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
