[jira] [Commented] (CLOUDSTACK-9082) Improvements with list public ip addresses
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031489#comment-15031489 ] Wei Zhou commented on CLOUDSTACK-9082: -- (6) improve IP selection for shared network offerings on creation of instances > Improvements with list public ip addresses > -- > > Key: CLOUDSTACK-9082 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9082 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > it will include the following changes: > (1) list ALL/Allocated/Free Ips in shared network > (2) list all available ips when acqure a new public ip address (for isolated > network) > (3) list available ips when acquire secondary ips (for shared network) > (4) list available ips (on shared network) when update vm nic ip. (related to > CLOUDSTACK-9051) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031508#comment-15031508 ] ASF GitHub Bot commented on CLOUDSTACK-9083: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1121#issuecomment-160559759 LGTM based on the code. I don't see any real issues. > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9082) Improvements with list public ip addresses
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou updated CLOUDSTACK-9082: - Issue Type: Improvement (was: Bug) > Improvements with list public ip addresses > -- > > Key: CLOUDSTACK-9082 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9082 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > it will include the following changes: > (1) list ALL/Allocated/Free Ips in shared network > (2) list all available ips when acqure a new public ip address (for isolated > network) > (3) list available ips when acquire secondary ips (for shared network) > (4) list available ips (on shared network) when update vm nic ip. (related to > CLOUDSTACK-9051) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031516#comment-15031516 ] ASF GitHub Bot commented on CLOUDSTACK-4787: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1132#issuecomment-160561489 @sateesh-chodapuneedi this is a real bug for many users as they are not able to use Windows 2012 templates with vmware/CloudStack, which is why we need the fix in 4.5 for 4.5.3 besides this does not involve any db changes but simply add to a list of supported controller types other than ide or scsi. > Allow selection of scsi controller type in vSphere > -- > > Key: CLOUDSTACK-4787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI, VMware >Affects Versions: 4.2.0, 4.3.0 > Environment: vSphere 5.1 >Reporter: Chris Sciarrino >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.3, 4.7.0, 4.6.1 > > Attachments: screenshot-1.png > > > When adding an OVA template for a vSphere environment allow the selection of > the scsi controller type. > Currently the instances are deployed with the the LSI Parallel controller > type. This results in a blue screen on boot when attempting to deploy > templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031554#comment-15031554 ] ASF GitHub Bot commented on CLOUDSTACK-9083: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1121#issuecomment-160574861 Merging now that we're tests performed and 2LGTMs. > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031552#comment-15031552 ] ASF GitHub Bot commented on CLOUDSTACK-4787: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1131#issuecomment-160574800 @sateesh-chodapuneedi as mentioned on the other PR, the issue is that many users are not able to use Windows 2012 templates and we see this as a severe bug that needs to be fixed as Windows 2012 is a fairly common template to be deployed. > Allow selection of scsi controller type in vSphere > -- > > Key: CLOUDSTACK-4787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI, VMware >Affects Versions: 4.2.0, 4.3.0 > Environment: vSphere 5.1 >Reporter: Chris Sciarrino >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.3, 4.7.0, 4.6.1 > > Attachments: screenshot-1.png > > > When adding an OVA template for a vSphere environment allow the selection of > the scsi controller type. > Currently the instances are deployed with the the LSI Parallel controller > type. This results in a blue screen on boot when attempting to deploy > templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031558#comment-15031558 ] ASF subversion and git services commented on CLOUDSTACK-9083: - Commit 7dcc6540e76db06fe51e8f33803260762ffaa826 in cloudstack's branch refs/heads/4.6 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7dcc654 ] Merge pull request #1121 from shapeblue/4.6-cloudstack-9083 [4.6] CLOUDSTACK-9083: Add disk serial to kvm virt xmlAdds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. We currently don't support scsi-blcok devices for which serial is not supported, for this we've added a DeviceType (LUN) which may be used in future and a check to not add the serial to the xml if disk type is LUN. Refer: https://libvirt.org/formatdomain.html#elementsDisks * pr/1121: CLOUDSTACK-9083: Add disk serial to kvm virt xml Signed-off-by: Rohit Yadav > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031555#comment-15031555 ] ASF subversion and git services commented on CLOUDSTACK-9083: - Commit 12c395b56052af36901ab3ed1a366ed8985740eb in cloudstack's branch refs/heads/4.6 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=12c395b ] CLOUDSTACK-9083: Add disk serial to kvm virt xml Adds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. We currently don't support scsi-blcok devices for which serial is not supported, for this we've added a DeviceType (LUN) which may be used in future and a check to not add the serial to the xml if disk type is LUN. Refer: https://libvirt.org/formatdomain.html#elementsDisks Signed-off-by: Rohit Yadav > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031559#comment-15031559 ] ASF GitHub Bot commented on CLOUDSTACK-9083: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1121 > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031557#comment-15031557 ] ASF subversion and git services commented on CLOUDSTACK-9083: - Commit 7dcc6540e76db06fe51e8f33803260762ffaa826 in cloudstack's branch refs/heads/4.6 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7dcc654 ] Merge pull request #1121 from shapeblue/4.6-cloudstack-9083 [4.6] CLOUDSTACK-9083: Add disk serial to kvm virt xmlAdds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. We currently don't support scsi-blcok devices for which serial is not supported, for this we've added a DeviceType (LUN) which may be used in future and a check to not add the serial to the xml if disk type is LUN. Refer: https://libvirt.org/formatdomain.html#elementsDisks * pr/1121: CLOUDSTACK-9083: Add disk serial to kvm virt xml Signed-off-by: Rohit Yadav > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031563#comment-15031563 ] ASF subversion and git services commented on CLOUDSTACK-9083: - Commit cbb9c4acdf8262dd74d75df1309d46fa6c6102df in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cbb9c4a ] CLOUDSTACK-9083: Add disk serial to kvm virt xml Adds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. Signed-off-by: Rohit Yadav > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031564#comment-15031564 ] ASF subversion and git services commented on CLOUDSTACK-9083: - Commit 3f2e259e16f4cc9a1525c470f45495130d7db027 in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3f2e259 ] Merge pull request #1120 from shapeblue/4.5-cloudstack-9083 [4.5] CLOUDSTACK-9083: Add disk serial to kvm virt xmlAdds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. We currently don't support scsi-blcok devices for which serial is not supported, for this we've added a DeviceType (LUN) which may be used in future and a check to not add the serial to the xml if disk type is LUN. Refer: https://libvirt.org/formatdomain.html#elementsDisks JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 * pr/1120: CLOUDSTACK-9083: Add disk serial to kvm virt xml Signed-off-by: Rohit Yadav > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031567#comment-15031567 ] ASF GitHub Bot commented on CLOUDSTACK-9083: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1120 > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7446) Openvswitch plugin has duplicate names
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031568#comment-15031568 ] Keerthiraja commented on CLOUDSTACK-7446: - As per on below link doc PVLAN setup is not working on the CS 4.5.2 https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+for+isolation+within+a+VLAN let this will be updated on upcoming version 4.5.3 and 4.6.1 > Openvswitch plugin has duplicate names > -- > > Key: CLOUDSTACK-7446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.4.0 > Environment: Ubuntu 14.04 LTS >Reporter: Vadim Kim. > Attachments: network_providers.jpg > > > Openvswitch plugin at Network Service Providers has duplicate names - "Ovs" > and "OVS". > 1. Pushing "OVS" does nothing. Management server log does not log anything > 2. Pushing "Ovs" generate error at managment server log: > Api Discovery plugin was unable to find an api by that name or process -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031566#comment-15031566 ] ASF subversion and git services commented on CLOUDSTACK-9083: - Commit 3f2e259e16f4cc9a1525c470f45495130d7db027 in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3f2e259 ] Merge pull request #1120 from shapeblue/4.5-cloudstack-9083 [4.5] CLOUDSTACK-9083: Add disk serial to kvm virt xmlAdds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. We currently don't support scsi-blcok devices for which serial is not supported, for this we've added a DeviceType (LUN) which may be used in future and a check to not add the serial to the xml if disk type is LUN. Refer: https://libvirt.org/formatdomain.html#elementsDisks JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 * pr/1120: CLOUDSTACK-9083: Add disk serial to kvm virt xml Signed-off-by: Rohit Yadav > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031565#comment-15031565 ] ASF subversion and git services commented on CLOUDSTACK-9083: - Commit 3f2e259e16f4cc9a1525c470f45495130d7db027 in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3f2e259 ] Merge pull request #1120 from shapeblue/4.5-cloudstack-9083 [4.5] CLOUDSTACK-9083: Add disk serial to kvm virt xmlAdds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. We currently don't support scsi-blcok devices for which serial is not supported, for this we've added a DeviceType (LUN) which may be used in future and a check to not add the serial to the xml if disk type is LUN. Refer: https://libvirt.org/formatdomain.html#elementsDisks JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 * pr/1120: CLOUDSTACK-9083: Add disk serial to kvm virt xml Signed-off-by: Rohit Yadav > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031577#comment-15031577 ] ASF GitHub Bot commented on CLOUDSTACK-9083: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1121#issuecomment-160576751 great @bhaisaab I'll create the merge forward > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-9083. - Resolution: Fixed > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9077) injectkeys.sh doesn't work on CentOS7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031603#comment-15031603 ] ASF GitHub Bot commented on CLOUDSTACK-9077: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1109#issuecomment-160585862 @wido @remibergsma do we want this on 4.5? > injectkeys.sh doesn't work on CentOS7 > - > > Key: CLOUDSTACK-9077 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9077 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Remi Bergsma >Priority: Critical > > Regression from: > https://github.com/apache/cloudstack/commit/3381154fafb7fa4f0a61d538f7c2550e48247787 > CentOS7 doesn't have /dev/loop0 so it fails. Removing the check makes it work > again. > ``` > 2015-11-20 21:51:16,145 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Executing: /bin/bash > /var/lib/tomcat/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh > /usr/share/tomc > at5/.ssh/id_rsa.pub /usr/share/tomcat5/.ssh/id_rsa > /var/lib/tomcat/webapps/client/WEB-INF/classes/vms/systemvm.iso > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Execution is successful. > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) No loop device found, skipping ssh key insertion > in systemvm.iso > 2015-11-20 21:51:16,162 INFO [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Injected public and private keys into systemvm > iso with result : null > ``` > Pinging [~pdion] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9095) Hypervisor changes to support UserData for Nuage VSP
Nick Livens created CLOUDSTACK-9095: --- Summary: Hypervisor changes to support UserData for Nuage VSP Key: CLOUDSTACK-9095 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9095 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nick Livens Assignee: Nick Livens Hypervisor changes to support UserData for Nuage VSP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9010) Fix packaging for CentOS 7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031611#comment-15031611 ] ASF GitHub Bot commented on CLOUDSTACK-9010: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1008#issuecomment-160588176 @davidamorimfaria @remibergsma should we port this to 4.5? > Fix packaging for CentOS 7 > -- > > Key: CLOUDSTACK-9010 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9010 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: David Amorim Faria >Assignee: David Amorim Faria >Priority: Blocker > Fix For: 4.6.0 > > > The current packaging for CentOS 7 does not work in a newly > installed/upgraded CentOS 7 system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9039) Log folder path Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031618#comment-15031618 ] ASF subversion and git services commented on CLOUDSTACK-9039: - Commit d62335215b2b95cf29599186b97f08efd162c3a8 in cloudstack's branch refs/heads/4.5 from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d623352 ] CLOUDSTACK-9039: Fix paths for logging Ubuntu Management. (cherry picked from commit acd49d801be0cf5675ce2b2130277b85fad213bd) Signed-off-by: Rohit Yadav > Log folder path Ubuntu > -- > > Key: CLOUDSTACK-9039 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9039 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver >Priority: Minor > > Log folder path is incorrect during setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031615#comment-15031615 ] ASF subversion and git services commented on CLOUDSTACK-9058: - Commit 296a5d77528d11ec43fd239698f7314dc977408d in cloudstack's branch refs/heads/4.5 from [~dsclose] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=296a5d7 ] CLOUDSTACK-9058 Respond with "saved_password" if no password is to be issued. (cherry picked from commit 8a7deefe64cab0b3c49ebc510c6524b1fad1f884) Signed-off-by: Rohit Yadav > Password server causes Windows VMs to switch to blank passwords after each > reboot > - > > Key: CLOUDSTACK-9058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose >Priority: Critical > > Previous versions of the systemvm.iso used a shell script to serve passwords. > In response to a "send_my_password" query, if no password was to be served, > the /opt/cloud/bin/serve_password.sh script would issue a response with > "saved_password" in the body. > The new version of the systemvm.iso supercedes serve_password.sh with a > python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour > is different to the original serve_password.sh. In response to a > "send_my_password" query, if no password was to be served, the > /opt/cloud/bin/passwd_server_ip.py script issues an empty response. > Linux guests handle this appropriately. The cloud-set-guest-password init > script uses a case statement to ignore blank responses. I've not been able to > examine the code for the equivalent Windows guest service but it responds > very differently. > If a Windows guest receives a blank response from the password server then it > assumes that the password needs to be blank. The log on the windows guest > reports the following: > [INFO] Need to set new password for this VM. First letter in password : > [INFO] New password has been set for this VM > The windows guest expects a "saved_password" response if a password isn't > being issued. If it receives this response then it logs the following: > [INFO] No need to set password, because http://10.1.1.1:8080/ said so with > response saved_password > Because the password server is queried every time the windows service starts, > this will result in the guest adopting a blank password every time it is > rebooted or the service is restarted. It's probably unrealistic to consider > updating the Windows service in every guest currently running in cloudstack. > As such it looks like the password server's behaviour needs to be adjusted to > match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9045) Wrong mounting directory specified for managment server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031617#comment-15031617 ] ASF subversion and git services commented on CLOUDSTACK-9045: - Commit 865dd46bbed6d4f8dd8731a8efb15ede93cb3425 in cloudstack's branch refs/heads/4.5 from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=865dd46 ] CLOUDSTACK-9045: Corrected mount point for management server DEBIAN. (cherry picked from commit 7bbc5338c50820107dc5a7c4b6c1fbf09e1afd40) Signed-off-by: Rohit Yadav > Wrong mounting directory specified for managment server. > > > Key: CLOUDSTACK-9045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 > Environment: Ubuntu 14.04 >Reporter: Boris Schrijver >Assignee: Boris Schrijver >Priority: Critical > Fix For: 4.6.0 > > > The mounting directory here [0], which we specify for DEB packages here [1] > is incorrect. It should be /var/lib/cloudstack/mnt instead of > /var/lib/cloud/mnt. > [0] > https://github.com/apache/cloudstack/blob/3ded3e90007d08fa98465f2b8c68b7fb075557c0/client/tomcatconf/environment.properties.in#L21 > [1] > https://github.com/apache/cloudstack/blob/3ded3e90007d08fa98465f2b8c68b7fb075557c0/packaging/debian/replace.properties#L46 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9053) CloudStack is dependent upon a vulnerable version of Commons Collections
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031616#comment-15031616 ] ASF subversion and git services commented on CLOUDSTACK-9053: - Commit 75f7c4d085a7387f0121ebb4834cb983ec1f056d in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=75f7c4d ] CLOUDSTACK-9053 security upgrade as per COLLECTIONS-580 Picked from Daan's fix from: https://github.com/apache/cloudstack/pull/1089 Signed-off-by: Rohit Yadav > CloudStack is dependent upon a vulnerable version of Commons Collections > > > Key: CLOUDSTACK-9053 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9053 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: John Kinsella > > COLLECTIONS-580 was brought to our attention today. Current versions of > Apache Commons Collections contain a serialization/unserialization > vulnerability which may result in remote code execution. > CloudStack does not seem to use the specific vulnerable class > InvokerTransformer, so in theory we could recommend pulling that class from > the jars/wars, but still looking to see what else we can do... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9078) Scripts inside folder /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ aren't executable.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031614#comment-15031614 ] ASF subversion and git services commented on CLOUDSTACK-9078: - Commit e1ef2e9ac08193ef515e7817de2936850125035b in cloudstack's branch refs/heads/4.5 from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e1ef2e9 ] CLOUDSTACK-9078: Gave scripts executable permissions. (cherry picked from commit e2fc270480916901b2bfd4f4bab376a6008f9f57) Signed-off-by: Rohit Yadav Conflicts: python/lib/cloudutils/serviceConfigServer.py > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. > - > > Key: CLOUDSTACK-9078 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9078 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.7.0, 4.6.1 > > > Scripts inside folder > /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/ > aren't executable. Therefore, when cloudstack tries to run one, it will get a > permission error and fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9010) Fix packaging for CentOS 7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031623#comment-15031623 ] ASF GitHub Bot commented on CLOUDSTACK-9010: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1008#issuecomment-160589376 @bhaisaab I think it is fine to do so, but centos7 support was still experimental. Not sure if we spring hopes there that are unjust. > Fix packaging for CentOS 7 > -- > > Key: CLOUDSTACK-9010 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9010 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: David Amorim Faria >Assignee: David Amorim Faria >Priority: Blocker > Fix For: 4.6.0 > > > The current packaging for CentOS 7 does not work in a newly > installed/upgraded CentOS 7 system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9010) Fix packaging for CentOS 7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031624#comment-15031624 ] ASF GitHub Bot commented on CLOUDSTACK-9010: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1008#issuecomment-160590038 @DaanHoogland I see, leaving it then. CentOS7 users should use 4.6/4.7 then. > Fix packaging for CentOS 7 > -- > > Key: CLOUDSTACK-9010 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9010 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: David Amorim Faria >Assignee: David Amorim Faria >Priority: Blocker > Fix For: 4.6.0 > > > The current packaging for CentOS 7 does not work in a newly > installed/upgraded CentOS 7 system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9092) G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031631#comment-15031631 ] ASF GitHub Bot commented on CLOUDSTACK-9092: Github user milamberspace commented on the pull request: https://github.com/apache/cloudstack/pull/1139#issuecomment-160591699 Not tested, but code is good. LGTM > G11n: L10n: JA/SC: Some strings are not localized on the "Add LDAP Account" > page > > > Key: CLOUDSTACK-9092 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9092 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Fix For: 4.7.0 > > Attachments: SC.jpg > > > Repro Steps: > 1. Setup basic environments as normal. > 2. Open a browser, go to Web Console. > 3. Choose "Global Settings" on left panel, select "LDAP Configuration", > configure LDAP. > 4. Choose "Account" on left panel, click "Add LDAP Account" button. > 5. Input some characters in LDAP Group input box, check the UI. > Expected Result: > All strings should be localized on the "Add LDAP Account" page. > Actual Result: > Some strings are not localized on the "Add LDAP Account" page. > Language Info > SC -> Fail > JA -> Fail -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9010) Fix packaging for CentOS 7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031635#comment-15031635 ] ASF GitHub Bot commented on CLOUDSTACK-9010: Github user davidamorimfaria commented on the pull request: https://github.com/apache/cloudstack/pull/1008#issuecomment-160594088 @bhaisaab I see no harm in trying to package 4.5 with this spec. It should just work (read, services start) if all the files expected by the spec file are also included in 4.5. > Fix packaging for CentOS 7 > -- > > Key: CLOUDSTACK-9010 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9010 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: David Amorim Faria >Assignee: David Amorim Faria >Priority: Blocker > Fix For: 4.6.0 > > > The current packaging for CentOS 7 does not work in a newly > installed/upgraded CentOS 7 system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9095) Hypervisor changes to support UserData for Nuage VSP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031637#comment-15031637 ] ASF GitHub Bot commented on CLOUDSTACK-9095: GitHub user nlivens opened a pull request: https://github.com/apache/cloudstack/pull/1142 CLOUDSTACK-9095 : Hypervisor changes to support UserData for Nuage VSP You can merge this pull request into a Git repository by running: $ git pull https://github.com/nlivens/cloudstack master_nuage Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1142.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1142 commit 35d5a2b042ebd8437411773e94da5858f7d3fb8c Author: Nick Livens Date: 2015-11-30T10:32:38Z CLOUDSTACK-9095 : Hypervisor changes to support UserData for Nuage VSP > Hypervisor changes to support UserData for Nuage VSP > > > Key: CLOUDSTACK-9095 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9095 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nick Livens >Assignee: Nick Livens > > Hypervisor changes to support UserData for Nuage VSP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9010) Fix packaging for CentOS 7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031666#comment-15031666 ] ASF GitHub Bot commented on CLOUDSTACK-9010: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/1008#issuecomment-160599550 @davidamorimfaria thanks, I personally won't be able to fix/test this soonish so dropping this unless of course you or someone wants this in 4.5 and sends a PR. > Fix packaging for CentOS 7 > -- > > Key: CLOUDSTACK-9010 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9010 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: David Amorim Faria >Assignee: David Amorim Faria >Priority: Blocker > Fix For: 4.6.0 > > > The current packaging for CentOS 7 does not work in a newly > installed/upgraded CentOS 7 system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9080) Able to upload Volume greater than the Resource limit defined for Primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031668#comment-15031668 ] ASF GitHub Bot commented on CLOUDSTACK-9080: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1107#issuecomment-160600074 The fix seems good to me. I can't run the Marvin tests, but it looks good to me > Able to upload Volume greater than the Resource limit defined for Primary > Storage. > -- > > Key: CLOUDSTACK-9080 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9080 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rajani Karuturi > > Steps : > 1. Create a child domain and create a User Account for the Respective child > domain. > 2. Edit the Primary Storage Resource limits for the account added above . > Limit being 200 GB , edit the value as 1Gb. > 3. Try to upload volume greater than 1Gb. (Volume is successfully uploaded. ) > 4. try attaching the volume to a vm. > Result: > attach volume is successful even though the resource limits reached. > Expected: > attach volume should fail with resource limit reached on primary exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031794#comment-15031794 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user nvazquez commented on the pull request: https://github.com/apache/cloudstack/pull/1094#issuecomment-160636372 @miguelaferreira thanks for reviewing! Sure, would be great to discuss them > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 4) API Changes > # Existing API addNiciraNvpDevices will be updated > ## Adding 1 new optional parameter – l2gatewayserviceuuid > ## Adding 1 new response tag – l2gatewayserviceuuid > # Existing API listNiciraNvpDevices will be updated > ## Adding 1 new response tag – l2gatewayserviceuuid > # Existing API listNics will be updated > ## Adding 2 new optional response tag – nsxlogicalswit
[jira] [Commented] (CLOUDSTACK-6276) Affinity Groups within projects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031801#comment-15031801 ] ASF GitHub Bot commented on CLOUDSTACK-6276: Github user pdube commented on the pull request: https://github.com/apache/cloudstack/pull/1134#issuecomment-160638862 @DaanHoogland Ok, I understand what you mean. I do think that we need some clarifications on what the standards are (search vs list, service vs query vs dao, etc.) PS: I was not taking it that way :) > Affinity Groups within projects > --- > > Key: CLOUDSTACK-6276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6276 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Ingo Jochim > > Hello, > I like to have the features "Affinity Group" and "Project" combined. > As far as I know I cannot use Affinity Groups within Projects. > Thanks and regards, > Ingo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031829#comment-15031829
]
ASF GitHub Bot commented on CLOUDSTACK-9074:
Github user nvazquez commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1094#discussion_r46148014
--- Diff:
api/src/com/cloud/network/guru/NetworkGuruAdditionalFunctions.java ---
@@ -0,0 +1,12 @@
+package com.cloud.network.guru;
+
+import java.util.Map;
+
+public interface NetworkGuruAdditionalFunctions {
--- End diff --
I agree. This was the "best" solution I found, maybe for my lack CS
architecture knowledge. This was the problem that I faced:
I needed to call this functions from NetworkOrchestrator. However, from
NetworkOrchestrator I could access NetworkGuru interface, so I decided not to
include this methods in NetworkGuru interface, implementing them blank in every
guru except in NiciraNvpGuestNetworkGuru. I decided to create this interface,
only implemented by NiciraNvpGuestNetworkGuru just to avoid doing that.
In NetworkOrchestrator, line 682 I made a call to one of this functions.
How can I improve this solution?
> Support shared networking in NiciraNVP Plugin
> -
>
> Key: CLOUDSTACK-9074
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.7.0
>Reporter: Nicolas Vazquez
> Fix For: 4.7.0
>
>
> h3. Introduction
> Currently NiciraNVP plugin supports only Isolated networking. In this mode of
> operations networks are assigned to individual Cloudstack accounts and on NSX
> side are completely isolated on the L3 level. Many use cases especially in
> corporate environment call for shared networking mode support. In some
> circumstances there also may be a need to translate shared NSX network over
> to a physical VLAN via L2 NSX gateway.
> Features that will be introduced to support Cloudstack shared networks in two
> modes of NiciraNVP plugin:
> * Shared networks mapped to a physical VLAN with L2 NSX gateway
> * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will
> be supported.
> h3. Features
> h4. 1) Shared networking model support
> # Support native Cloudstack shared network in NiciraNVP plugin.
> # Current code that implements isolated networking mode support will stay
> intact.
> # Designate network service offering by configuring VirtualNetworking
> provider with NiciraNVP.
> # Static/Source NAT is not used and ignored if defined in the network
> offering.
> # Nicira_vvp_router_map table will support non-unique logical routers to
> implement L3 NSX routing domains where multiple Cloudstack networks are
> attached to the same logical router.
> # Shared network with NSX based Virtual networking will go through the
> following states:
> ## Allocated
> ## Implementing
> ## Implemented
> ## Destroy
> h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network
> # Optional L2gatewayserviceuuid parameter for NiciraNVP controller
> # VLAN ID of a Shared network represents VLAN to pass through L2 gateway
> similar to native Cloudstack shared networking
> # NSX workflow for network allocation
> ## Check if l2gatewayservice defined
> ## Create record in networks table
> ### NiciraNvpGuestNetworkGuru as Guru_name
> ### Lswitch as broadcast_doamin
> ### Vlan://vlan_id as broadcast_uri
> ## Create record in VLAN table
> # NSX workflow for network implementation
> ## Check if l2gatewayservice defined and valid
> ## Create logical switch
> ## Map logical switch to L2gateway service assigning shared network VLAN ID
> # NSX workflow for NIC management and/or hypervisor support
> ## No changes from current implementation
> h4. 3) Support NSX L3 multiple routing domains
> # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a
> particular routing domain. We will support UUID style notation for VLAN ID.
> l3gatewayservice option is not used in shared networking
> # It is assumed that if connectivity to the physical networking is required
> then logical router is configured and connected to the physical network in
> advance. NiciraNVP plugin will not perform any task beyond basic connectivity
> to the logical router
> # Support NSX L3 multiple routing domains
> # NSX workflow for network allocation
> ## Create record in networks table
> ### NiciraNvpGuestNetworkGuru as Guru_name
> ### Lswitch as broadcast_domain
> ### NULL as broadcast_uri
> ## Create record in VLAN table
> ## Create record in nicira_nvp_router_map table
> # NSX workflow for network implementation
> ## Check if logical r
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031833#comment-15031833 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user nvazquez commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1094#discussion_r46148337 --- Diff: setup/db/db/schema-460to470.sql --- @@ -18,3 +18,5 @@ --; -- Schema upgrade from 4.6.0 to 4.7.0; --; + +ALTER TABLE `cloud`.`nicira_nvp_router_map` DROP INDEX `logicalrouter_uuid` ; --- End diff -- Right. As many networks can now connect to the same logical router > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 4) API Changes > # Existing API addNiciraNvpDevices will be updated > ## Adding 1 new optional parameter – l2gatewayserviceuuid > ## Adding
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031835#comment-15031835 ] ASF GitHub Bot commented on CLOUDSTACK-9074: Github user nvazquez commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1094#discussion_r46148362 --- Diff: setup/db/db/schema-461to470.sql --- @@ -18,3 +18,5 @@ --; -- Schema upgrade from 4.6.1 to 4.7.0; --; + +ALTER TABLE `cloud`.`nicira_nvp_router_map` DROP INDEX `logicalrouter_uuid` ; --- End diff -- Right. As many networks can now connect to the same logical router > Support shared networking in NiciraNVP Plugin > - > > Key: CLOUDSTACK-9074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Nicolas Vazquez > Fix For: 4.7.0 > > > h3. Introduction > Currently NiciraNVP plugin supports only Isolated networking. In this mode of > operations networks are assigned to individual Cloudstack accounts and on NSX > side are completely isolated on the L3 level. Many use cases especially in > corporate environment call for shared networking mode support. In some > circumstances there also may be a need to translate shared NSX network over > to a physical VLAN via L2 NSX gateway. > Features that will be introduced to support Cloudstack shared networks in two > modes of NiciraNVP plugin: > * Shared networks mapped to a physical VLAN with L2 NSX gateway > * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will > be supported. > h3. Features > h4. 1) Shared networking model support > # Support native Cloudstack shared network in NiciraNVP plugin. > # Current code that implements isolated networking mode support will stay > intact. > # Designate network service offering by configuring VirtualNetworking > provider with NiciraNVP. > # Static/Source NAT is not used and ignored if defined in the network > offering. > # Nicira_vvp_router_map table will support non-unique logical routers to > implement L3 NSX routing domains where multiple Cloudstack networks are > attached to the same logical router. > # Shared network with NSX based Virtual networking will go through the > following states: > ## Allocated > ## Implementing > ## Implemented > ## Destroy > h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network > # Optional L2gatewayserviceuuid parameter for NiciraNVP controller > # VLAN ID of a Shared network represents VLAN to pass through L2 gateway > similar to native Cloudstack shared networking > # NSX workflow for network allocation > ## Check if l2gatewayservice defined > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_doamin > ### Vlan://vlan_id as broadcast_uri > ## Create record in VLAN table > # NSX workflow for network implementation > ## Check if l2gatewayservice defined and valid > ## Create logical switch > ## Map logical switch to L2gateway service assigning shared network VLAN ID > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 3) Support NSX L3 multiple routing domains > # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a > particular routing domain. We will support UUID style notation for VLAN ID. > l3gatewayservice option is not used in shared networking > # It is assumed that if connectivity to the physical networking is required > then logical router is configured and connected to the physical network in > advance. NiciraNVP plugin will not perform any task beyond basic connectivity > to the logical router > # Support NSX L3 multiple routing domains > # NSX workflow for network allocation > ## Create record in networks table > ### NiciraNvpGuestNetworkGuru as Guru_name > ### Lswitch as broadcast_domain > ### NULL as broadcast_uri > ## Create record in VLAN table > ## Create record in nicira_nvp_router_map table > # NSX workflow for network implementation > ## Check if logical router exists on NSX side which UUID matches the one > defined during shared network creation. This mode is activated if VLAN ID > supplied in UUID style notation > ## Create logical switch > ## Attach logical switch to the logical router > ## Assign shared network default gateway to the inside port of the logical > router > # NSX workflow for NIC management and/or hypervisor support > ## No changes from current implementation > h4. 4) API Changes > # Existing API addNiciraNvpDevices will be updated > ## Adding 1 new optional parameter – l2gatewayserviceuuid > ## Adding
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031860#comment-15031860 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/985#issuecomment-160649027 Still working on this one. However, I need to get stuff into libvirt-java upstream. Working on that here: https://github.com/wido/libvirt-java/commits/qemu-guest-command > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8818) Python scripts should depend on mysql.connector instead of MySQLdb
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031859#comment-15031859 ] ASF GitHub Bot commented on CLOUDSTACK-8818: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1054#issuecomment-160648931 @borisroman @DaanHoogland Anybody else? :) > Python scripts should depend on mysql.connector instead of MySQLdb > -- > > Key: CLOUDSTACK-8818 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8818 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wido den Hollander > Labels: mysql, python, python3 > > Our current Python scripts depend on MySQLdb for MySQL connections. > The best way to go is the native mysql.connector which implements the MySQL > protocol in native Python instead of depending on external libraries. > It would be best if we drop MySQLdb and use mysql.connector since that also > supports Python 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031899#comment-15031899 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user NuxRo commented on the pull request: https://github.com/apache/cloudstack/pull/985#issuecomment-160654716 Ok, godspeed. With a bit of luck perhaps we'll see this somewhere in 4.7.x? > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031980#comment-15031980
]
ASF GitHub Bot commented on CLOUDSTACK-9074:
Github user nvazquez commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1094#discussion_r46159749
--- Diff: api/src/com/cloud/network/Networks.java ---
@@ -251,6 +252,10 @@ public static URI fromString(String candidate) {
if
(com.cloud.dc.Vlan.UNTAGGED.equalsIgnoreCase(candidate)) {
return Native.toUri(candidate);
}
+if (UuidUtils.validateUUID(candidate)){
+//Supporting lswitch uuid as vlan id: set
broadcast_uri = null and add row on nicira_nvp_router_map with
logicalrouter_uuid = candidate
+return null;
--- End diff --
The idea is to support creating Shared Networks over NSX Managed Network
Offering, so there will be this two cases (for creation):
* Providing numerical VLAN_ID:
* broadcastdomain_type = Lswitch
* broadcast_uri = "vlan://VLAN_ID"
* Providing logical router UUID as VLAN_ID:
* broadcastdomain_type = Lswitch
* broadcast_uri = NULL
* add entry on nicira_nvp_router_map with network id and logical router's
UUID
For second case, I included the code in the catch block as I asumed that
VLAN_ID provided is not numerical (as long parsing fail).
> Support shared networking in NiciraNVP Plugin
> -
>
> Key: CLOUDSTACK-9074
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.7.0
>Reporter: Nicolas Vazquez
> Fix For: 4.7.0
>
>
> h3. Introduction
> Currently NiciraNVP plugin supports only Isolated networking. In this mode of
> operations networks are assigned to individual Cloudstack accounts and on NSX
> side are completely isolated on the L3 level. Many use cases especially in
> corporate environment call for shared networking mode support. In some
> circumstances there also may be a need to translate shared NSX network over
> to a physical VLAN via L2 NSX gateway.
> Features that will be introduced to support Cloudstack shared networks in two
> modes of NiciraNVP plugin:
> * Shared networks mapped to a physical VLAN with L2 NSX gateway
> * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will
> be supported.
> h3. Features
> h4. 1) Shared networking model support
> # Support native Cloudstack shared network in NiciraNVP plugin.
> # Current code that implements isolated networking mode support will stay
> intact.
> # Designate network service offering by configuring VirtualNetworking
> provider with NiciraNVP.
> # Static/Source NAT is not used and ignored if defined in the network
> offering.
> # Nicira_vvp_router_map table will support non-unique logical routers to
> implement L3 NSX routing domains where multiple Cloudstack networks are
> attached to the same logical router.
> # Shared network with NSX based Virtual networking will go through the
> following states:
> ## Allocated
> ## Implementing
> ## Implemented
> ## Destroy
> h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network
> # Optional L2gatewayserviceuuid parameter for NiciraNVP controller
> # VLAN ID of a Shared network represents VLAN to pass through L2 gateway
> similar to native Cloudstack shared networking
> # NSX workflow for network allocation
> ## Check if l2gatewayservice defined
> ## Create record in networks table
> ### NiciraNvpGuestNetworkGuru as Guru_name
> ### Lswitch as broadcast_doamin
> ### Vlan://vlan_id as broadcast_uri
> ## Create record in VLAN table
> # NSX workflow for network implementation
> ## Check if l2gatewayservice defined and valid
> ## Create logical switch
> ## Map logical switch to L2gateway service assigning shared network VLAN ID
> # NSX workflow for NIC management and/or hypervisor support
> ## No changes from current implementation
> h4. 3) Support NSX L3 multiple routing domains
> # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a
> particular routing domain. We will support UUID style notation for VLAN ID.
> l3gatewayservice option is not used in shared networking
> # It is assumed that if connectivity to the physical networking is required
> then logical router is configured and connected to the physical network in
> advance. NiciraNVP plugin will not perform any task beyond basic connectivity
> to the logical router
> # Support NSX L3 multiple routing domains
> # NSX workflow for network allocation
> ## Create record i
[jira] [Commented] (CLOUDSTACK-8988) CLOUDSTACK-8988
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032157#comment-15032157
]
ASF GitHub Bot commented on CLOUDSTACK-8988:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/943#issuecomment-160704405
there is a merge conflict @rodrigo93 . can you resolve it please?
> CLOUDSTACK-8988
> ---
>
> Key: CLOUDSTACK-8988
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8988
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Projects
>Affects Versions: 4.7.0
> Environment: Windows 10; Eclipse;
>Reporter: Rodrigo Pedro Marques
>Priority: Minor
> Labels: easyfix, github-import
> Fix For: 4.7.0
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Removal of cloud-plugin-storage-allocator-random project that was unused.
> File modified: /cloud-server/test/async-job-component.xml. Removed some
> unused adapters.The reason for this is explained as follows.
> The adapter configuration is the following:
>
> class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator">
> 2
>
>
> 2
>
>
> • class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> The class "com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> does not exist. The only reference for it is found in the following file:
> - /cloud-server/test/async-job-component.xml
> Therefore, we can conclude that there is no need for this line at that file.
> • class="com.cloud.agent.manager.allocator.impl.RandomStoragePoolAllocator"
> Additionally, the class RandomStoragePoolAllocator.java is never used. The
> only reference is found in the following file:
> /cloud-server/test/async-job-component.xml
> We found a project called “cloud-plugin-storage-allocator-random”. This
> project has only one package that contains only one class, which is the
> RandomStoragePoolAllocator.java. Despite the names that are the same, the
> class in “cloud-plugin-storage-allocator-random” project and the class
> referenced in - /cloud-server/test/async-job-component.xml have different
> packages. Therefore, we removed that configuration from
> async-job-component.xml and the project that contains only the
> RandomStoragePoolAllocator class that is never used.
> Consequently, we had to remove the following lines from the
> /cloud-client-ui/pom.xml:
>
> org.apache.cloudstack
> cloud-plugin-storage-allocator-random
> ${project.version}
>
> Those changes leave us with an adapter configuration empty with the following
> key:
> • key="com.cloud.agent.manager.allocator.StorageAllocator"
> Therefore, we removed it.
> Furthermore, after we removed that configuration we noticed that there is no
> such class StorageAllocator.java. However, it appears that exists test for
> it, like the following classes:
> StorageAllocatorTestConfiguration.java
> StorageAllocatorTest.java. We are not sure if these classes are tests for the
> class StorageAllocator.java and for the possible configuration we have just
> removed. If they are, we can remove both classes.
> We also removed the following configuration from /cloudstack-plugins/pom.xml:
> storage-allocators/random
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8988) CLOUDSTACK-8988
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032159#comment-15032159
]
ASF GitHub Bot commented on CLOUDSTACK-8988:
Github user rafaelweingartner commented on the pull request:
https://github.com/apache/cloudstack/pull/943#issuecomment-160705037
@DaanHoogland , where did you see the merge conflict Daan ? I did not find
it.
> CLOUDSTACK-8988
> ---
>
> Key: CLOUDSTACK-8988
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8988
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Projects
>Affects Versions: 4.7.0
> Environment: Windows 10; Eclipse;
>Reporter: Rodrigo Pedro Marques
>Priority: Minor
> Labels: easyfix, github-import
> Fix For: 4.7.0
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Removal of cloud-plugin-storage-allocator-random project that was unused.
> File modified: /cloud-server/test/async-job-component.xml. Removed some
> unused adapters.The reason for this is explained as follows.
> The adapter configuration is the following:
>
> class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator">
> 2
>
>
> 2
>
>
> • class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> The class "com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> does not exist. The only reference for it is found in the following file:
> - /cloud-server/test/async-job-component.xml
> Therefore, we can conclude that there is no need for this line at that file.
> • class="com.cloud.agent.manager.allocator.impl.RandomStoragePoolAllocator"
> Additionally, the class RandomStoragePoolAllocator.java is never used. The
> only reference is found in the following file:
> /cloud-server/test/async-job-component.xml
> We found a project called “cloud-plugin-storage-allocator-random”. This
> project has only one package that contains only one class, which is the
> RandomStoragePoolAllocator.java. Despite the names that are the same, the
> class in “cloud-plugin-storage-allocator-random” project and the class
> referenced in - /cloud-server/test/async-job-component.xml have different
> packages. Therefore, we removed that configuration from
> async-job-component.xml and the project that contains only the
> RandomStoragePoolAllocator class that is never used.
> Consequently, we had to remove the following lines from the
> /cloud-client-ui/pom.xml:
>
> org.apache.cloudstack
> cloud-plugin-storage-allocator-random
> ${project.version}
>
> Those changes leave us with an adapter configuration empty with the following
> key:
> • key="com.cloud.agent.manager.allocator.StorageAllocator"
> Therefore, we removed it.
> Furthermore, after we removed that configuration we noticed that there is no
> such class StorageAllocator.java. However, it appears that exists test for
> it, like the following classes:
> StorageAllocatorTestConfiguration.java
> StorageAllocatorTest.java. We are not sure if these classes are tests for the
> class StorageAllocator.java and for the possible configuration we have just
> removed. If they are, we can remove both classes.
> We also removed the following configuration from /cloudstack-plugins/pom.xml:
> storage-allocators/random
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8988) CLOUDSTACK-8988
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032207#comment-15032207
]
ASF GitHub Bot commented on CLOUDSTACK-8988:
Github user rodrigo93 commented on the pull request:
https://github.com/apache/cloudstack/pull/943#issuecomment-160714102
@DaanHoogland Can you tell us where the conflict is? It seems ok to me.
> CLOUDSTACK-8988
> ---
>
> Key: CLOUDSTACK-8988
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8988
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Projects
>Affects Versions: 4.7.0
> Environment: Windows 10; Eclipse;
>Reporter: Rodrigo Pedro Marques
>Priority: Minor
> Labels: easyfix, github-import
> Fix For: 4.7.0
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Removal of cloud-plugin-storage-allocator-random project that was unused.
> File modified: /cloud-server/test/async-job-component.xml. Removed some
> unused adapters.The reason for this is explained as follows.
> The adapter configuration is the following:
>
> class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator">
> 2
>
>
> 2
>
>
> • class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> The class "com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> does not exist. The only reference for it is found in the following file:
> - /cloud-server/test/async-job-component.xml
> Therefore, we can conclude that there is no need for this line at that file.
> • class="com.cloud.agent.manager.allocator.impl.RandomStoragePoolAllocator"
> Additionally, the class RandomStoragePoolAllocator.java is never used. The
> only reference is found in the following file:
> /cloud-server/test/async-job-component.xml
> We found a project called “cloud-plugin-storage-allocator-random”. This
> project has only one package that contains only one class, which is the
> RandomStoragePoolAllocator.java. Despite the names that are the same, the
> class in “cloud-plugin-storage-allocator-random” project and the class
> referenced in - /cloud-server/test/async-job-component.xml have different
> packages. Therefore, we removed that configuration from
> async-job-component.xml and the project that contains only the
> RandomStoragePoolAllocator class that is never used.
> Consequently, we had to remove the following lines from the
> /cloud-client-ui/pom.xml:
>
> org.apache.cloudstack
> cloud-plugin-storage-allocator-random
> ${project.version}
>
> Those changes leave us with an adapter configuration empty with the following
> key:
> • key="com.cloud.agent.manager.allocator.StorageAllocator"
> Therefore, we removed it.
> Furthermore, after we removed that configuration we noticed that there is no
> such class StorageAllocator.java. However, it appears that exists test for
> it, like the following classes:
> StorageAllocatorTestConfiguration.java
> StorageAllocatorTest.java. We are not sure if these classes are tests for the
> class StorageAllocator.java and for the possible configuration we have just
> removed. If they are, we can remove both classes.
> We also removed the following configuration from /cloudstack-plugins/pom.xml:
> storage-allocators/random
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032324#comment-15032324 ] ASF GitHub Bot commented on CLOUDSTACK-9022: GitHub user ustcweizhou opened a pull request: https://github.com/apache/cloudstack/pull/1144 [4.6.1] CLOUDSTACK-9022: keep Destroyed volumes for sometime for now, the Destroyed volumes will be expunged in Storage cleanup thread, no matter when they are destroyed. In Expunging vm thread, we expunge the Destroyed vms which have been destroyed at least 'expunge.delay' seconds. We add the similar configuration for volumes. same to #1029 , this is for 4.6 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ustcweizhou/cloudstack storage-cleanup-delay-4.6 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1144.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1144 commit 12c395b56052af36901ab3ed1a366ed8985740eb Author: Rohit Yadav Date: 2015-11-25T09:07:40Z CLOUDSTACK-9083: Add disk serial to kvm virt xml Adds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. We currently don't support scsi-blcok devices for which serial is not supported, for this we've added a DeviceType (LUN) which may be used in future and a check to not add the serial to the xml if disk type is LUN. Refer: https://libvirt.org/formatdomain.html#elementsDisks Signed-off-by: Rohit Yadav commit 1e67a5d2c89009daabdcded86e9844824ec7d1ed Author: Syed Date: 2015-11-27T18:48:18Z Fix secondary storage not working with swift commit 6d4722953f859c537aadd2a0b4b5f3553f33dc69 Author: Milamber Date: 2015-11-29T19:01:56Z Update L10N resource files with 4.6 strings from Transifex (20151129) commit 7dcc6540e76db06fe51e8f33803260762ffaa826 Author: Rohit Yadav Date: 2015-11-30T09:40:31Z Merge pull request #1121 from shapeblue/4.6-cloudstack-9083 [4.6] CLOUDSTACK-9083: Add disk serial to kvm virt xmlAdds disk serial ids based on volume uuids to the virt xml. This may be useful for appliances/software that needs some serial ids on the VM disks. This does not impact existing/running VMs, the vm virt xmls will be updates for running VMs the next time they are stopped/started. For testing, disk serial (of debian based systemvm) in the virt xml matched that in /sys/devices/pci:00::00:07.0/virtio4/block/vda/serial. We currently don't support scsi-blcok devices for which serial is not supported, for this we've added a DeviceType (LUN) which may be used in future and a check to not add the serial to the xml if disk type is LUN. Refer: https://libvirt.org/formatdomain.html#elementsDisks * pr/1121: CLOUDSTACK-9083: Add disk serial to kvm virt xml Signed-off-by: Rohit Yadav commit df0797affd0bdec9f42a28fee6af5291d4528698 Author: Remi Bergsma Date: 2015-11-30T18:36:37Z Merge pull request #1133 from syed/4.6 Fix secondary storage not working with swiftOriginal PR and discussion at #1112 * pr/1133: Fix secondary storage not working with swift Signed-off-by: Remi Bergsma commit e675250f6068e76d422618f8a4467aea29c256a6 Author: Remi Bergsma Date: 2015-11-30T18:49:01Z Merge pull request #1138 from milamberspace/L10N-update-4.6-20151129 Update L10N resource files with 4.6 strings from Transifex (20151129)Small update of L10N files before the 4.6.1 release candidate cc @remibergsma * pr/1138: Update L10N resource files with 4.6 strings from Transifex (20151129) Signed-off-by: Remi Bergsma commit 9077c9a5b47224b2d00978ff67e9af6957ec589b Author: Wei Zhou Date: 2015-11-03T16:04:55Z CLOUDSTACK-9022: keep Destroyed volumes for sometime commit 4ed1e0d5f809d1bb2845b6e076d55eeb1ce3f0f4 Author: Wei Zhou Date: 2015-11-04T08:27:32Z CLOUDSTACK-9022: move storage.cleanup related global configurations to StorageManager > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement >
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032342#comment-15032342 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user pdube commented on the pull request: https://github.com/apache/cloudstack/pull/1144#issuecomment-160739865 Hey @ustcweizhou, could you create the PR towards 4.6 please, it is hard to determine exactly what you changed. Thanks > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032325#comment-15032325 ] ASF GitHub Bot commented on CLOUDSTACK-9022: GitHub user ustcweizhou opened a pull request: https://github.com/apache/cloudstack/pull/1145 [4.6.1] CLOUDSTACK-9022: keep Destroyed volumes for sometime for now, the Destroyed volumes will be expunged in Storage cleanup thread, no matter when they are destroyed. In Expunging vm thread, we expunge the Destroyed vms which have been destroyed at least 'expunge.delay' seconds. We add the similar configuration for volumes. same to #1029 , for 4.6 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ustcweizhou/cloudstack storage-cleanup-delay-4.6 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1145.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1145 commit 9077c9a5b47224b2d00978ff67e9af6957ec589b Author: Wei Zhou Date: 2015-11-03T16:04:55Z CLOUDSTACK-9022: keep Destroyed volumes for sometime commit 4ed1e0d5f809d1bb2845b6e076d55eeb1ce3f0f4 Author: Wei Zhou Date: 2015-11-04T08:27:32Z CLOUDSTACK-9022: move storage.cleanup related global configurations to StorageManager > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032430#comment-15032430 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1144#issuecomment-160756847 @ustcweizhou This is a mistake I guess, PR against the wrong branch? > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032436#comment-15032436 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1144#issuecomment-160758013 @pdube @remibergsma I will recreate a new PR. > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9022) We should keep Destroyed volumes for some time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032437#comment-15032437 ] ASF GitHub Bot commented on CLOUDSTACK-9022: Github user ustcweizhou closed the pull request at: https://github.com/apache/cloudstack/pull/1144 > We should keep Destroyed volumes for some time > -- > > Key: CLOUDSTACK-9022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9022 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > for now, the Destroyed volumes will be expunged in Storage cleanup thread, no > matter when they are destroyed. > In Expunging vm, we only clean the Destroyed vms which have been destroyed at > least 'expunge.delay' seconds. > We need to add the similar configuration for volumes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9083) Add disk serial to vm/libvirt xml in case of KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032532#comment-15032532 ] ASF subversion and git services commented on CLOUDSTACK-9083: - Commit 4ecfc29267c7d796aca00826283c04302dafa4e3 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4ecfc29 ] Merge release branch 4.6 to master * 4.6: Use version for RC branch name instead of branch make sure all files are updates with new version Update L10N resource files with 4.6 strings from Transifex (20151129) Fix secondary storage not working with swift CLOUDSTACK-9083: Add disk serial to kvm virt xml > Add disk serial to vm/libvirt xml in case of KVM > > > Key: CLOUDSTACK-9083 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9083 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.3, 4.7.0, 4.6.1 > > > Certain appliances/software fail on KVM as they require disk serials (inside > of the VM). The fix would be to add a disk serial (from volume uuid) in the > generated libvirt xml for all disks except for lun/scsi block type disks > (which we don't support yet, so we can add in a deviceType for now and leave > some comment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-9077) injectkeys.sh doesn't work on CentOS7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion closed CLOUDSTACK-9077. --- Resolution: Fixed Assignee: Remi Bergsma Fix Version/s: 4.6.1 > injectkeys.sh doesn't work on CentOS7 > - > > Key: CLOUDSTACK-9077 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9077 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.6.1 > > > Regression from: > https://github.com/apache/cloudstack/commit/3381154fafb7fa4f0a61d538f7c2550e48247787 > CentOS7 doesn't have /dev/loop0 so it fails. Removing the check makes it work > again. > ``` > 2015-11-20 21:51:16,145 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Executing: /bin/bash > /var/lib/tomcat/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh > /usr/share/tomc > at5/.ssh/id_rsa.pub /usr/share/tomcat5/.ssh/id_rsa > /var/lib/tomcat/webapps/client/WEB-INF/classes/vms/systemvm.iso > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Execution is successful. > 2015-11-20 21:51:16,161 DEBUG [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) No loop device found, skipping ssh key insertion > in systemvm.iso > 2015-11-20 21:51:16,162 INFO [c.c.s.ConfigurationServerImpl] > (localhost-startStop-1:null) Injected public and private keys into systemvm > iso with result : null > ``` > Pinging [~pdion] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9056) Upgrade 4.4.1 to 4.6.0 fails: 4.5.0 KVM SystemVm template not found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033003#comment-15033003 ] Pierre-Luc Dion commented on CLOUDSTACK-9056: - [~nuxro], The Release Notes of 4.6.0 as been updated and upgrading to 4.6.1 does not require to have the template for 4.5. Can we close this issue? > Upgrade 4.4.1 to 4.6.0 fails: 4.5.0 KVM SystemVm template not found > --- > > Key: CLOUDSTACK-9056 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9056 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM, Upgrade >Affects Versions: 4.6.0 > Environment: CentOS 6 HVs and Mgmt >Reporter: Nux >Priority: Minor > Labels: systemvm, upgrade > > Hello, > Trying to upgrade from 4.4.1 to 4.6.0 (round 2) fails with mgmt log > complaining about missing systemvm v4.5! > http://fpaste.org/289162/43685144/raw/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9056) Upgrade 4.4.1 to 4.6.0 fails: 4.5.0 KVM SystemVm template not found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033253#comment-15033253 ] Nux commented on CLOUDSTACK-9056: - Sure, will do > Upgrade 4.4.1 to 4.6.0 fails: 4.5.0 KVM SystemVm template not found > --- > > Key: CLOUDSTACK-9056 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9056 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM, Upgrade >Affects Versions: 4.6.0 > Environment: CentOS 6 HVs and Mgmt >Reporter: Nux >Priority: Minor > Labels: systemvm, upgrade > > Hello, > Trying to upgrade from 4.4.1 to 4.6.0 (round 2) fails with mgmt log > complaining about missing systemvm v4.5! > http://fpaste.org/289162/43685144/raw/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-9056) Upgrade 4.4.1 to 4.6.0 fails: 4.5.0 KVM SystemVm template not found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nux closed CLOUDSTACK-9056. --- Resolution: Fixed > Upgrade 4.4.1 to 4.6.0 fails: 4.5.0 KVM SystemVm template not found > --- > > Key: CLOUDSTACK-9056 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9056 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM, Upgrade >Affects Versions: 4.6.0 > Environment: CentOS 6 HVs and Mgmt >Reporter: Nux >Priority: Minor > Labels: systemvm, upgrade > > Hello, > Trying to upgrade from 4.4.1 to 4.6.0 (round 2) fails with mgmt log > complaining about missing systemvm v4.5! > http://fpaste.org/289162/43685144/raw/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8988) CLOUDSTACK-8988
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033269#comment-15033269
]
ASF GitHub Bot commented on CLOUDSTACK-8988:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/943#issuecomment-160884629
@rafaelweingartner @rodrigo93 my bad I was merging against 4.6, not master.
So far it has 0ne failure. I think it is a false positive so I am rerunning
that test.
> CLOUDSTACK-8988
> ---
>
> Key: CLOUDSTACK-8988
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8988
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Projects
>Affects Versions: 4.7.0
> Environment: Windows 10; Eclipse;
>Reporter: Rodrigo Pedro Marques
>Priority: Minor
> Labels: easyfix, github-import
> Fix For: 4.7.0
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Removal of cloud-plugin-storage-allocator-random project that was unused.
> File modified: /cloud-server/test/async-job-component.xml. Removed some
> unused adapters.The reason for this is explained as follows.
> The adapter configuration is the following:
>
> class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator">
> 2
>
>
> 2
>
>
> • class="com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> The class "com.cloud.agent.manager.allocator.impl.FirstFitStorageAllocator"
> does not exist. The only reference for it is found in the following file:
> - /cloud-server/test/async-job-component.xml
> Therefore, we can conclude that there is no need for this line at that file.
> • class="com.cloud.agent.manager.allocator.impl.RandomStoragePoolAllocator"
> Additionally, the class RandomStoragePoolAllocator.java is never used. The
> only reference is found in the following file:
> /cloud-server/test/async-job-component.xml
> We found a project called “cloud-plugin-storage-allocator-random”. This
> project has only one package that contains only one class, which is the
> RandomStoragePoolAllocator.java. Despite the names that are the same, the
> class in “cloud-plugin-storage-allocator-random” project and the class
> referenced in - /cloud-server/test/async-job-component.xml have different
> packages. Therefore, we removed that configuration from
> async-job-component.xml and the project that contains only the
> RandomStoragePoolAllocator class that is never used.
> Consequently, we had to remove the following lines from the
> /cloud-client-ui/pom.xml:
>
> org.apache.cloudstack
> cloud-plugin-storage-allocator-random
> ${project.version}
>
> Those changes leave us with an adapter configuration empty with the following
> key:
> • key="com.cloud.agent.manager.allocator.StorageAllocator"
> Therefore, we removed it.
> Furthermore, after we removed that configuration we noticed that there is no
> such class StorageAllocator.java. However, it appears that exists test for
> it, like the following classes:
> StorageAllocatorTestConfiguration.java
> StorageAllocatorTest.java. We are not sure if these classes are tests for the
> class StorageAllocator.java and for the possible configuration we have just
> removed. If they are, we can remove both classes.
> We also removed the following configuration from /cloudstack-plugins/pom.xml:
> storage-allocators/random
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8746) VM Snapshotting implementation for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033274#comment-15033274 ] haijiao commented on CLOUDSTACK-8746: - Bring this up again, can we have 2nd LTGM to include it in 4.7 release which is supposed to be frozen by 7.Dec ? > VM Snapshotting implementation for KVM > -- > > Key: CLOUDSTACK-8746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8746 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > Currently it is not supported. > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots -- This message was sent by Atlassian JIRA (v6.3.4#6332)
