[jira] [Commented] (CLOUDSTACK-8886) Limitations is listUsageRecords output - listUsageRecords does not return "domain"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158416#comment-15158416 ] ASF GitHub Bot commented on CLOUDSTACK-8886: Github user kansal commented on the pull request: https://github.com/apache/cloudstack/pull/858#issuecomment-187574951 Can someone else review this as well? Already have unit test cases in the PR. > Limitations is listUsageRecords output - listUsageRecords does not return > "domain" > -- > > Key: CLOUDSTACK-8886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal > > Only domainid is returned by usageReports API call. > In cloudstack documention it mentions "domain" as being in the usage > response. The API should really be returning the domain as account > information has both account and accountid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9293) CloudStack 4.8 on CentOS 6: Unknown API command: addVmwareDc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158388#comment-15158388 ] ilya musayev commented on CLOUDSTACK-9293: -- http://packages.shapeblue.com/cloudstack/upstream/centos/4.8/ http://packages.shapeblue.com/cloudstack/upstream/centos/4.5 Above would be a direct link to 4.8 and 4.5, however, i'd suggest you start off with 4.5 (extensively tested build in internet scale deployments) - and upgrade to 4.8, if you feel there is a specific need.. Regards ilya > CloudStack 4.8 on CentOS 6: Unknown API command: addVmwareDc > > > Key: CLOUDSTACK-9293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9293 > Project: CloudStack > Issue Type: Bug > Components: VMware >Affects Versions: 4.8.0 > Environment: CentOS 6 - Official 4.8 Mirror : > https://cloudstack.apache.org/downloads.html >Reporter: Arash Shams >Assignee: ilya musayev > > Hello > I installed CloudStack 4.8 from official rpm repository on centos 6 in this > url : https://cloudstack.apache.org/downloads.html > in adding zone with vmware datacenter creating error appears : > Unknown API command: addVmwareDc > I searched for this error on jira but cant get a proper answer some of them > compile from source some of them not centos and so on . > CentOS release 6.7 (Final) > vCenter 5.5.0 Server Build 3252642 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9293) CloudStack 4.8 on CentOS 6: Unknown API command: addVmwareDc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ilya musayev resolved CLOUDSTACK-9293. -- Resolution: Won't Fix Please use alternate repository to download cloudstack "noredist" type build. Example: http://www.shapeblue.com/packages/ > CloudStack 4.8 on CentOS 6: Unknown API command: addVmwareDc > > > Key: CLOUDSTACK-9293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9293 > Project: CloudStack > Issue Type: Bug > Components: VMware >Affects Versions: 4.8.0 > Environment: CentOS 6 - Official 4.8 Mirror : > https://cloudstack.apache.org/downloads.html >Reporter: Arash Shams >Assignee: ilya musayev > > Hello > I installed CloudStack 4.8 from official rpm repository on centos 6 in this > url : https://cloudstack.apache.org/downloads.html > in adding zone with vmware datacenter creating error appears : > Unknown API command: addVmwareDc > I searched for this error on jira but cant get a proper answer some of them > compile from source some of them not centos and so on . > CentOS release 6.7 (Final) > vCenter 5.5.0 Server Build 3252642 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9293) CloudStack 4.8 on CentOS 6: Unknown API command: addVmwareDc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158379#comment-15158379 ] ilya musayev commented on CLOUDSTACK-9293: -- This is not an issue. You downloaded cloudstack from Apache hosted site. Apache forbids distribution of proprietary modules, hence what you downloaded contains only 100% open source redistributable packages. VmWare (along with many other vendors), releases its java client library - buts its not "open source", hence apache cannot distribute. You will need to download cloudstack from alternative repo that is not hosted by Apache and can distribute "noredist" type java classes. Here is one repo to try: http://www.shapeblue.com/packages/ Regards ilya > CloudStack 4.8 on CentOS 6: Unknown API command: addVmwareDc > > > Key: CLOUDSTACK-9293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9293 > Project: CloudStack > Issue Type: Bug > Components: VMware >Affects Versions: 4.8.0 > Environment: CentOS 6 - Official 4.8 Mirror : > https://cloudstack.apache.org/downloads.html >Reporter: Arash Shams > > Hello > I installed CloudStack 4.8 from official rpm repository on centos 6 in this > url : https://cloudstack.apache.org/downloads.html > in adding zone with vmware datacenter creating error appears : > Unknown API command: addVmwareDc > I searched for this error on jira but cant get a proper answer some of them > compile from source some of them not centos and so on . > CentOS release 6.7 (Final) > vCenter 5.5.0 Server Build 3252642 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9293) CloudStack 4.8 on CentOS 6: Unknown API command: addVmwareDc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ilya musayev reassigned CLOUDSTACK-9293: Assignee: ilya musayev > CloudStack 4.8 on CentOS 6: Unknown API command: addVmwareDc > > > Key: CLOUDSTACK-9293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9293 > Project: CloudStack > Issue Type: Bug > Components: VMware >Affects Versions: 4.8.0 > Environment: CentOS 6 - Official 4.8 Mirror : > https://cloudstack.apache.org/downloads.html >Reporter: Arash Shams >Assignee: ilya musayev > > Hello > I installed CloudStack 4.8 from official rpm repository on centos 6 in this > url : https://cloudstack.apache.org/downloads.html > in adding zone with vmware datacenter creating error appears : > Unknown API command: addVmwareDc > I searched for this error on jira but cant get a proper answer some of them > compile from source some of them not centos and so on . > CentOS release 6.7 (Final) > vCenter 5.5.0 Server Build 3252642 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9252) Support configurable NFS version for Secondary Storage mounts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157731#comment-15157731
]
ASF GitHub Bot commented on CLOUDSTACK-9252:
Github user nvazquez commented on the pull request:
https://github.com/apache/cloudstack/pull/1361#issuecomment-187396165
Hi @rafaelweingartner @kishankavala I've run test_ssvm.py,
test_secondary_storage.py and test_vm_life_cycle.py
integration tests under real hardware. This are my results:
```
[root@ussarlabcsmgt41 cloudstack]# cat
/tmp/MarvinLogs/test_vm_life_cycle_SFRI8J/results.txt
Test system VM start ... === TestName: test_01_sys_vm_start | Status :
SUCCESS ===
ok
Test system templates are ready ... === TestName:
test_02_sys_template_ready | Status : SUCCESS ===
ok
Test List secondary storage VMs ... === TestName:
test_01_list_sec_storage_vm | Status : SUCCESS ===
ok
Test List console proxy VMs ... === TestName: test_02_list_cpvm_vm | Status
: SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS
===
ok
Test advanced zone virtual router ... === TestName:
test_advZoneVirtualRouter | Status : SUCCESS ===
ok
Tests for basic zone virtual router ... === TestName:
test_basicZoneVirtualRouter | Status : SUCCESS ===
ok
Test Deploy Virtual Machine ... === TestName: test_deploy_vm | Status :
SUCCESS ===
ok
Test Multiple Deploy Virtual Machine ... === TestName:
test_deploy_vm_multiple | Status : SUCCESS ===
ok
Test Stop Virtual Machine ... === TestName: test_01_stop_vm | Status :
SUCCESS ===
ok
Test Start Virtual Machine ... === TestName: test_02_start_vm | Status :
SUCCESS ===
ok
Test Reboot Virtual Machine ... === TestName: test_03_reboot_vm | Status :
SUCCESS ===
ok
Test destroy Virtual Machine ... === TestName: test_06_destroy_vm | Status
: SUCCESS ===
ok
Test recover Virtual Machine ... === TestName: test_07_restore_vm | Status
: SUCCESS ===
ok
Test migrate VM ... === TestName: test_08_migrate_vm | Status : SUCCESS ===
ok
Test destroy(expunge) Virtual Machine ... === TestName: test_09_expunge_vm
| Status : SUCCESS ===
ok
Test for attach and detach ISO to virtual machine ... === TestName:
test_10_attachAndDetach_iso | Status : SUCCESS ===
ok
--
Ran 24 tests in 2128.458s
OK
```
> Support configurable NFS version for Secondary Storage mounts
> -
>
> Key: CLOUDSTACK-9252
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9252
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Reporter: Nicolas Vazquez
>
> After starting secondary storage VM, secondary storage tries to be mounted
> but fails with error: {{Protocol family not supported}}
> It was found out that adding {{-o vers=X}} to mount command it would work,
> where {{X}} is the desired NFS version to use.
> If it is desired to mount a store with a specific NFS version, it has passed
> in {{image_store_details}} table for a store with id {{Y}} as a property:
> ||store_idname||value||
> |Y|nfs.version|X|
> Where X stands for NFS version
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157603#comment-15157603 ] ASF GitHub Bot commented on CLOUDSTACK-9175: Github user resmo commented on the pull request: https://github.com/apache/cloudstack/pull/1248#issuecomment-187360919 @sureshanaparti yes, that would be great > [VMware DRS] Adding new host to DRS cluster does not participate in load > balancing > -- > > Key: CLOUDSTACK-9175 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.5.2 >Reporter: Suresh Kumar Anaparti >Assignee: Suresh Kumar Anaparti > > When a new VMware host is added into a cluster, Cloudstack, by default, > doesn't create all the port groups present in the cluster. And since it > doesn't have all the necessary networking port groups (existing VM's port > groups) it is not eligible to participate in DRS load balancing or HA. > Steps: > 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and > H2 created in the vCenter. > 2. Configure this cluster in Cloudstack and create couple of VMs. > 3. Start stressing the host by running some cpu hogging scripts in each of > the VM. > 4. Enable maintenance mode on one of the host - say H1 from Cloudstack. > 5. Also, quickly enable maintenance mode on host H1 from vCenter. > (This should migrate all the VMs to host H2) Make sure none of the VMs are > present on host H1. > 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well. > 7. At this point, the load is definitely imbalanced. This can be verified > from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS > section, it should show 'Load imbalanced' > Now, as per DRS rules, the load should be balanced across all the available > hosts. > In this case, even after adding new host, the load is imbalanced. > The reason for the load imbalance is VMs (created from Cloudstack) are not > eligible to migrate to new host because networks or the cloud portgroups are > not available on the new host H3 (except for private). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9142) Migrate VM changes xmlDesc in an unsafe way
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157560#comment-15157560
]
ASF GitHub Bot commented on CLOUDSTACK-9142:
Github user davidamorimfaria commented on the pull request:
https://github.com/apache/cloudstack/pull/1348#issuecomment-187342982
LGTM, 4.7.1 with this fix was installed on a live environment with success.
Instances can now be migrated to and from the kvm node that has an IP address
which partially matches one of the ceph monitor nodes.
> Migrate VM changes xmlDesc in an unsafe way
> ---
>
> Key: CLOUDSTACK-9142
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9142
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Management Server
>Affects Versions: 4.6.0, 4.7.0
>Reporter: David Amorim Faria
>Assignee: Daan Hoogland
>Priority: Critical
>
> This issue appears with commit
> https://github.com/apache/cloudstack/commit/a709f34ff93579981afbd4df0f4334b61ada29a8
> where xmlDesc has some content replaced: {code}
> xmlDesc =
> dm.getXMLDesc(xmlFlag).replace(libvirtComputingResource.getPrivateIp(),
> command.getDestinationIp());
> {code}
> This line from LibvirtComputingResource.java was refactored into
> LibvirtMigrateCommandWrapper.java in commit
> https://github.com/apache/cloudstack/commit/28e55462f15bdd8699e97b668c4ffc01735a533d
> Example, node1 is 10.0.0.1, node2 is 10.0.0.2, rbd mon_host is 10.0.0.13.
> VM is running on kvm node1 and this happened when migrating a VM from node1
> to node2, where the kvm nodes and the RBD mon nodes (mon_host) use IP
> addresses in the same range, and the mon_host has an ip address that
> partially matches the ip address (string) of the first kvm node.
> In the process list one can see that the mon_host changes from 10.0.0.13 to
> 10.0.0.23 in the destination host, blocking the migration after a timeout due
> to primary storage not being available.
> {code}
> root 25206 1.8 0.0 440184 17188 ?Sl 13:33 0:00
> /usr/libexec/qemu-kvm -name r-74-VM -S -machine
> pc-i440fx-rhel7.0.0,accel=kvm,usb=off -cpu
> host,+rdtscp,+pdpe1gb,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
> -m 256 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
> 1a32b655-0acf-424b-8722-9e7f507a3070 -smbios type=1,manufacturer=Apache
> Software Foundation,product=CloudStack KVM
> Hypervisor,uuid=1a32b655-0acf-424b-8722-9e7f507a3070 -no-user-config
> -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-r-74-VM/monitor.sock,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
> -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
> virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive
> file=rbd:rbd/15ea00f9-e52e-43cf-9e5e-62188e9da5d2:id=cloudstack:key===:auth_supported=cephx\;none:mon_host=10.0.0.23\:6789,if=none,id=drive-virtio-disk0,format=raw,serial=15ea00f9e52e43cf9e5e,cache=none
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2
> -drive
> file=/usr/share/cloudstack-common/vms/systemvm.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw,cache=none
> -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
> -netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=33 -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=11:11:11:11:11:11,bus=pci.0,addr=0x3,rombar=0,romfile=
> -netdev tap,fd=34,id=hostnet1,vhost=on,vhostfd=35 -device
> virtio-net-pci,netdev=hostnet1,id=net1,mac=22:22:22:22:22:22,bus=pci.0,addr=0x4,rombar=0,romfile=
> -netdev tap,fd=36,id=hostnet2,vhost=on,vhostfd=37 -device
> virtio-net-pci,netdev=hostnet2,id=net2,mac=33:33:33:33:33:33,bus=pci.0,addr=0x5,rombar=0,romfile=
> -chardev pty,id=charserial0 -device
> isa-serial,chardev=charserial0,id=serial0 -chardev
> socket,id=charchannel0,path=/var/lib/libvirt/qemu/r-74-VM.agent,server,nowait
> -device
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=r-74-VM.vport
> -device usb-tablet,id=input0 -vnc 10.0.0.2:4,password -vga cirrus -incoming
> tcp:[::]:49152 -msg timestamp=on
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9295) EGRESS left on ACCEPT on isolated network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nux updated CLOUDSTACK-9295: Description: When allowing 0.0.0.0/0 on EGRESS for "ALL" and then removing that, the rules are not properly cleaned, leaving the chain actually accepting all traffic! Please see http://img.nux.ro/fP3-Selection_123.png was: When allowing 0.0.0.0/0 on EGRESS for "ALL" the rules are not properly cleaned, leaving the chain actually accepting all traffic! Please see http://img.nux.ro/fP3-Selection_123.png > EGRESS left on ACCEPT on isolated network > - > > Key: CLOUDSTACK-9295 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9295 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.8.0 > Environment: CentOS 6 MGMT+HVs >Reporter: Nux > Labels: firewall, virtualrouter, vr > > When allowing 0.0.0.0/0 on EGRESS for "ALL" and then removing that, the rules > are not properly cleaned, leaving the chain actually accepting all traffic! > Please see http://img.nux.ro/fP3-Selection_123.png -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9295) EGRESS left on ACCEPT on isolated network
Nux created CLOUDSTACK-9295: --- Summary: EGRESS left on ACCEPT on isolated network Key: CLOUDSTACK-9295 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9295 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.8.0 Environment: CentOS 6 MGMT+HVs Reporter: Nux When allowing 0.0.0.0/0 on EGRESS for "ALL" the rules are not properly cleaned, leaving the chain actually accepting all traffic! Please see http://img.nux.ro/fP3-Selection_123.png -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9142) Migrate VM changes xmlDesc in an unsafe way
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156881#comment-15156881
]
ASF GitHub Bot commented on CLOUDSTACK-9142:
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1348#issuecomment-187167486
@remibergsma @wido can we merge this?
> Migrate VM changes xmlDesc in an unsafe way
> ---
>
> Key: CLOUDSTACK-9142
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9142
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Management Server
>Affects Versions: 4.6.0, 4.7.0
>Reporter: David Amorim Faria
>Assignee: Daan Hoogland
>Priority: Critical
>
> This issue appears with commit
> https://github.com/apache/cloudstack/commit/a709f34ff93579981afbd4df0f4334b61ada29a8
> where xmlDesc has some content replaced: {code}
> xmlDesc =
> dm.getXMLDesc(xmlFlag).replace(libvirtComputingResource.getPrivateIp(),
> command.getDestinationIp());
> {code}
> This line from LibvirtComputingResource.java was refactored into
> LibvirtMigrateCommandWrapper.java in commit
> https://github.com/apache/cloudstack/commit/28e55462f15bdd8699e97b668c4ffc01735a533d
> Example, node1 is 10.0.0.1, node2 is 10.0.0.2, rbd mon_host is 10.0.0.13.
> VM is running on kvm node1 and this happened when migrating a VM from node1
> to node2, where the kvm nodes and the RBD mon nodes (mon_host) use IP
> addresses in the same range, and the mon_host has an ip address that
> partially matches the ip address (string) of the first kvm node.
> In the process list one can see that the mon_host changes from 10.0.0.13 to
> 10.0.0.23 in the destination host, blocking the migration after a timeout due
> to primary storage not being available.
> {code}
> root 25206 1.8 0.0 440184 17188 ?Sl 13:33 0:00
> /usr/libexec/qemu-kvm -name r-74-VM -S -machine
> pc-i440fx-rhel7.0.0,accel=kvm,usb=off -cpu
> host,+rdtscp,+pdpe1gb,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
> -m 256 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
> 1a32b655-0acf-424b-8722-9e7f507a3070 -smbios type=1,manufacturer=Apache
> Software Foundation,product=CloudStack KVM
> Hypervisor,uuid=1a32b655-0acf-424b-8722-9e7f507a3070 -no-user-config
> -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-r-74-VM/monitor.sock,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
> -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
> virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive
> file=rbd:rbd/15ea00f9-e52e-43cf-9e5e-62188e9da5d2:id=cloudstack:key===:auth_supported=cephx\;none:mon_host=10.0.0.23\:6789,if=none,id=drive-virtio-disk0,format=raw,serial=15ea00f9e52e43cf9e5e,cache=none
> -device
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2
> -drive
> file=/usr/share/cloudstack-common/vms/systemvm.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw,cache=none
> -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
> -netdev tap,fd=32,id=hostnet0,vhost=on,vhostfd=33 -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=11:11:11:11:11:11,bus=pci.0,addr=0x3,rombar=0,romfile=
> -netdev tap,fd=34,id=hostnet1,vhost=on,vhostfd=35 -device
> virtio-net-pci,netdev=hostnet1,id=net1,mac=22:22:22:22:22:22,bus=pci.0,addr=0x4,rombar=0,romfile=
> -netdev tap,fd=36,id=hostnet2,vhost=on,vhostfd=37 -device
> virtio-net-pci,netdev=hostnet2,id=net2,mac=33:33:33:33:33:33,bus=pci.0,addr=0x5,rombar=0,romfile=
> -chardev pty,id=charserial0 -device
> isa-serial,chardev=charserial0,id=serial0 -chardev
> socket,id=charchannel0,path=/var/lib/libvirt/qemu/r-74-VM.agent,server,nowait
> -device
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=r-74-VM.vport
> -device usb-tablet,id=input0 -vnc 10.0.0.2:4,password -vga cirrus -incoming
> tcp:[::]:49152 -msg timestamp=on
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9294) Nuage : VR doesn't get removed from the VSD when destroying a VPC
Nick Livens created CLOUDSTACK-9294: --- Summary: Nuage : VR doesn't get removed from the VSD when destroying a VPC Key: CLOUDSTACK-9294 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9294 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Third-Party Bugs Reporter: Nick Livens Assignee: Nick Livens Fix For: 4.9.0 When destroying a VPC, the VR doesn't get removed from the VSD -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9294) Nuage Plugin : VR doesn't get removed from the VSD when destroying a VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Livens updated CLOUDSTACK-9294: Summary: Nuage Plugin : VR doesn't get removed from the VSD when destroying a VPC (was: Nuage : VR doesn't get removed from the VSD when destroying a VPC) > Nuage Plugin : VR doesn't get removed from the VSD when destroying a VPC > > > Key: CLOUDSTACK-9294 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9294 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Third-Party Bugs >Reporter: Nick Livens >Assignee: Nick Livens > Fix For: 4.9.0 > > > When destroying a VPC, the VR doesn't get removed from the VSD -- This message was sent by Atlassian JIRA (v6.3.4#6332)
