Hi Mike,
Hi have observed this behavior on CCP 4.3.x mostly and xenserver 6.5 less so
in 4.5.1. I use Fiber Channel LVMoHBA as the primary storage.
Seems like the same issue.
Disk Attached to Dom0 after snapshot or copy from secondary to primary:
In this example we have a disk attached to dom0, we cannot delete the disk
until we detach it.
admin.rc.precise 0 Created by template provisioner 42 GB Control domain on
host cpms1-1.nsp.testlabs.com.au
[root@cpms1-1 ~]# xe vdi-list name-label="admin.rc.precise 0"
uuid ( RO) : 3d79722b-294d-4358-bc57-af92b9e9dda7
name-label ( RW): admin.rc.precise 0
name-description ( RW): Created by template provisioner
sr-uuid ( RO): dce1ec02-cce0-347d-0679-f39c9ea64da1
virtual-size ( RO): 45097156608
sharable ( RO): false
read-only ( RO): false
You will want to list out the VBD (connector object between VM and VDI) based
on the VDI UUID. Here is an example:
[root@cpms1-1 ~]# xe vbd-list vdi-uuid=3d79722b-294d-4358-bc57-af92b9e9dda7
uuid ( RO) : d9e2d89e-a82f-9e6e-c97a-afe0af47468e
vm-uuid ( RO): 0f4cb186-0167-47d6-afb5-89b00102250b
vm-name-label ( RO): Control domain on host: cpms1-1.nsp.nectar.org.au
vdi-uuid ( RO): 3d79722b-294d-4358-bc57-af92b9e9dda7
empty ( RO): false
device ( RO):
Once done, you want to first try to make VBD inactive (it may already be
inactive), "The device is not currently attached"
xe vbd-unplug uuid=d9e2d89e-a82f-9e6e-c97a-afe0af47468e
Once done, you can then break the connection:
xe vbd-destroy uuid=<UUID of VBD>
Now you can delete the disk from xencenter
Regards,
Adrian Sender
---------- Original Message -----------
From: Anshul Gangwar <anshul.gang...@accelerite.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Sent: Fri, 15 Apr 2016 06:48:59 +0000
Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
> Mike, what type of storage are you using?
>
> > On 15-Apr-2016, at 9:49 AM, Tutkowski, Mike <mike.tutkow...@netapp.com>
> > wrote:
> >
> > I'm not sure, Daan.
> >
> > I plan to keep an eye on this behavior for a while when creating new clouds.
> >
> > ________________________________________
> > From: Daan Hoogland <daan.hoogl...@gmail.com>
> > Sent: Thursday, April 14, 2016 2:12 AM
> > To: dev
> > Subject: Re: Strange XenServer SR behavior when deploying system VMs in
Basic Zone on 4.9
> >
> > Mike, did the iso copy process not complete as expected. Sound like they
> > are a remanence of some task ending in an exception. Probably a silently
> > ignored one ;|
> >
> > On Thu, Apr 14, 2016 at 2:49 AM, Tutkowski, Mike <mike.tutkow...@netapp.com>
> > wrote:
> >
> >> Just an FYI, but when I kicked off my first VM in this cloud, the VR
> >> happened to get deployed to XenServer-6.5-3 (which was one of my XenServer
> >> hosts that had an un-expected shared SR pointing at secondary storage
> >> beforehand).
> >>
> >> Once the process of copying the system template down to local storage
> >> completed, the shared SR pointing at secondary storage went away (as you
> >> would expect).
> >>
> >> This leaves me now with one un-expected shared SR pointing at secondary
> >> storage on XenServer-6.5-1.
> >>
> >> ________________________________________
> >> From: Tutkowski, Mike <mike.tutkow...@netapp.com>
> >> Sent: Wednesday, April 13, 2016 5:10 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: Strange XenServer SR behavior when deploying system VMs in Basic
> >> Zone on 4.9
> >>
> >> Hi,
> >>
> >>
> >> Has anyone recently observed the following behavior:
> >>
> >>
> >> http://imgur.com/8ALJmWb
> >>
> >>
> >> As you can see in the image, I have three 6.5 XenServer hosts in a
> >> resource pool.
> >>
> >>
> >> I just used them when creating a basic zone and the system VMs were
> >> deployed just fine. However, there are SRs pointing to secondary storage on
> >> my XenServer-6.5-1 and XenServer-6.5-3 hosts still (there used to be one on
> >> my XenServer-6.5-2 host, but it went away once the system VMs started up on
> >> that host).
> >>
> >>
> >> Thoughts?
> >>
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >
> >
> >
> > --
> > Daan
>
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information
> which is the property of Accelerite, a Persistent Systems business.
> It is intended only for the use of the individual or entity to which
> it is addressed. If you are not the intended recipient, you are not
> authorized to read, retain, copy, print, distribute or use this
> message. If you have received this communication in error, please
> notify the sender and delete all copies of this message. Accelerite,
> a Persistent Systems business does not accept any liability for
> virus infected mails.
------- End of Original Message -------
