ABIQUO

  • Log In Access more options
    • Online Help
    • GreenHopper Help
    • Agile Answers
    • Use Agile By Default
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Agile Access more options
    • Planning Board
    • Task Board
    • Chart Board
    • Released Board
    • Rapid Board
    • Manage Rapid Boards
    • Getting Started
  • Abiquo
  • ABICLOUD-688

VSM does not unsunscribe more than 1 VM in Hyper-V after undeploying a VApp

  • Rapid Board
  • More Actions
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Invalid
  • Affects Version/s: Abiquo-1.6.0
  • Fix Version/s: Abiquo-1.6.5
  • Component/s: Virtualization
  • Labels:
    None
  • Affect Build:
    3361

Description

Steps to Reproduce
-enter as sysadmin
-go to virtual datacenter
-select a virtual datacenter and virtual appliance with hyper-v hypervisor
-add several image to the Virtual appliance and deploy -> vsm subscribe to changes for every VM
-undeploy

Expected Results
When undeploying, vsm should unsuscribe to every VM

Real Results
VSM only unsuscribe to the first Virtual Machine in virtual appliance. For the others ones, is displayed in log each 10 seconds:
10:58:00.108 WARN c.a.a.vsm.plugin.hyperv.HyperVPoller - Could not get state of Virtual System: ABQ_db224c7e-996f-4ba8-80e6-bcbaa1075141
10:58:05.775 WARN c.a.a.vsm.plugin.hyperv.HyperVPoller - Could not get state of Virtual System: ABQ_db224c7e-996f-4ba8-80e6-bcbaa1075141
10:58:11.451 WARN c.a.a.vsm.plugin.hyperv.HyperVPoller - Could not get state of Virtual System: ABQ_db224c7e-996f-4ba8-80e6-bcbaa1075141

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Transitions
Hide
Permalink
Ignasi Barrera added a comment - 02/Sep/10 2:31 PM
Fixed in revision 3378.
Show
Ignasi Barrera added a comment - 02/Sep/10 2:31 PM Fixed in revision 3378.
Hide
Permalink
Valerie Kalusinski added a comment - 14/Sep/10 5:58 PM
this has been fixed for several VM running in same Virtual Appliance.
But we have the same problem with removed captured VM.

Steps to Reproduce
-enter as sysadmin
-go to infrastructure
-select a datacenter, physical machine hyper-v and capture a VM
-go to hyper-v and remove the captured VM
-go to the Virtual appliance with the removed captured VM
-undeploy

-> vsm does not suscribe to the captured removed VM.

Reopened on build 3412.
Show
Valerie Kalusinski added a comment - 14/Sep/10 5:58 PM this has been fixed for several VM running in same Virtual Appliance. But we have the same problem with removed captured VM. Steps to Reproduce -enter as sysadmin -go to infrastructure -select a datacenter, physical machine hyper-v and capture a VM -go to hyper-v and remove the captured VM -go to the Virtual appliance with the removed captured VM -undeploy -> vsm does not suscribe to the captured removed VM. Reopened on build 3412.
Hide
Permalink
Ignasi Barrera added a comment - 17/Sep/10 11:19 AM
This is a normal behavior:

The HyperV monitor is implemented as a poller that asks for the state of the VM every X seconds.
When a VM is removed directly from the Hypervisor, the Monitor has not enough information to decide if it must be unregistered: It doesn't know if the VM has disappeared, if there is a punctual networking problem that makes it impossible to monitor the VM, etc, so a trace is written in the log to inform about the situation.
Show
Ignasi Barrera added a comment - 17/Sep/10 11:19 AM This is a normal behavior: The HyperV monitor is implemented as a poller that asks for the state of the VM every X seconds. When a VM is removed directly from the Hypervisor, the Monitor has not enough information to decide if it must be unregistered: It doesn't know if the VM has disappeared, if there is a punctual networking problem that makes it impossible to monitor the VM, etc, so a trace is written in the log to inform about the situation.
Hide
Permalink
Valerie Kalusinski added a comment - 17/Sep/10 11:35 AM
Verified.
Show
Valerie Kalusinski added a comment - 17/Sep/10 11:35 AM Verified.

People

  • Assignee:
    Ignasi Barrera
    Reporter:
    Valerie Kalusinski
Vote (0)
Watch (0)

Dates

  • Created:
    30/Aug/10 11:00 AM
    Updated:
    17/Sep/10 11:35 AM
    Resolved:
    17/Sep/10 11:19 AM

Time Tracking

Estimated:
4h
Original Estimate - 4 hours
Remaining:
4h
Remaining Estimate - 4 hours
Logged:
Not Specified
Time Spent - Not Specified
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for abiquo. Try JIRA - bug tracking software for your team.