You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by "Tutkowski, Mike" <Mi...@netapp.com> on 2016/04/14 01:10:32 UTC
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
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
Hi,
The system VMs are just running on local storage.
Thanks,
Mike
> On Apr 15, 2016, at 12:49 AM, Anshul Gangwar <an...@accelerite.com> wrote:
>
> Mike, what type of storage are you using?
>
>
>> On 15-Apr-2016, at 9:49 AM, Tutkowski, Mike <Mi...@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 <da...@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 <Mi...@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 <Mi...@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.
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
Just an FYI that I no longer see this problem (as was expected).
Thanks!
________________________________________
From: Tutkowski, Mike <Mi...@netapp.com>
Sent: Monday, April 18, 2016 12:05 PM
To: dev@cloudstack.apache.org
Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9
Thanks!
It's no rush from my point of view. Just happy to know it looks like the problem's been fixed. :)
________________________________________
From: Rafael Weingärtner <ra...@gmail.com>
Sent: Monday, April 18, 2016 11:41 AM
To: dev@cloudstack.apache.org
Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9
We found it last Saturday during the factoring of a test case! That was
pure lucky.
The code of the PR is not that good yet. But, we will work to get it ready
to be reviewed and merged.
On Mon, Apr 18, 2016 at 2:37 PM, Tutkowski, Mike <Mi...@netapp.com>
wrote:
> Thanks, Rafael! That very much looks like it could solve the problem.
>
> I've subscribed to the PR for notifications. Once I see it's in the
> codebase, I can re-build my dev environment and see if I still have the
> issue.
> ________________________________________
> From: Rafael Weingärtner <ra...@gmail.com>
> Sent: Monday, April 18, 2016 8:07 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> Basic Zone on 4.9
>
> Would the problem discussed here relate to the one here
> https://github.com/apache/cloudstack/pull/1499?
>
> On Mon, Apr 18, 2016 at 11:04 AM, Tutkowski, Mike <
> Mike.Tutkowski@netapp.com
> > wrote:
>
> > Looks like I already opened a ticket on this in January. :)
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-9224
> >
> > I added info to it.
> > ________________________________________
> > From: Tutkowski, Mike <Mi...@netapp.com>
> > Sent: Saturday, April 16, 2016 9:58 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> > Basic Zone on 4.9
> >
> > Thanks, Adrian!
> >
> > In my case, it's a dev environment, so it's not really hurting anything
> > (it just seems like weird behavior, so I was curious if others were
> seeing
> > it).
> >
> > I can create a ticket in Jira and add your info and mine to it.
> >
> > Thanks again!
> >
> > > On Apr 16, 2016, at 4:43 AM, Adrian Sender <as...@testlabs.com.au>
> > wrote:
> > >
> > > 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 <an...@accelerite.com>
> > > To: "dev@cloudstack.apache.org" <de...@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.Tutkowski@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 <da...@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.Tutkowski@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 <Mi...@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 -------
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
Thanks!
It's no rush from my point of view. Just happy to know it looks like the problem's been fixed. :)
________________________________________
From: Rafael Weingärtner <ra...@gmail.com>
Sent: Monday, April 18, 2016 11:41 AM
To: dev@cloudstack.apache.org
Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9
We found it last Saturday during the factoring of a test case! That was
pure lucky.
The code of the PR is not that good yet. But, we will work to get it ready
to be reviewed and merged.
On Mon, Apr 18, 2016 at 2:37 PM, Tutkowski, Mike <Mi...@netapp.com>
wrote:
> Thanks, Rafael! That very much looks like it could solve the problem.
>
> I've subscribed to the PR for notifications. Once I see it's in the
> codebase, I can re-build my dev environment and see if I still have the
> issue.
> ________________________________________
> From: Rafael Weingärtner <ra...@gmail.com>
> Sent: Monday, April 18, 2016 8:07 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> Basic Zone on 4.9
>
> Would the problem discussed here relate to the one here
> https://github.com/apache/cloudstack/pull/1499?
>
> On Mon, Apr 18, 2016 at 11:04 AM, Tutkowski, Mike <
> Mike.Tutkowski@netapp.com
> > wrote:
>
> > Looks like I already opened a ticket on this in January. :)
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-9224
> >
> > I added info to it.
> > ________________________________________
> > From: Tutkowski, Mike <Mi...@netapp.com>
> > Sent: Saturday, April 16, 2016 9:58 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> > Basic Zone on 4.9
> >
> > Thanks, Adrian!
> >
> > In my case, it's a dev environment, so it's not really hurting anything
> > (it just seems like weird behavior, so I was curious if others were
> seeing
> > it).
> >
> > I can create a ticket in Jira and add your info and mine to it.
> >
> > Thanks again!
> >
> > > On Apr 16, 2016, at 4:43 AM, Adrian Sender <as...@testlabs.com.au>
> > wrote:
> > >
> > > 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 <an...@accelerite.com>
> > > To: "dev@cloudstack.apache.org" <de...@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.Tutkowski@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 <da...@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.Tutkowski@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 <Mi...@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 -------
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by Rafael Weingärtner <ra...@gmail.com>.
We found it last Saturday during the factoring of a test case! That was
pure lucky.
The code of the PR is not that good yet. But, we will work to get it ready
to be reviewed and merged.
On Mon, Apr 18, 2016 at 2:37 PM, Tutkowski, Mike <Mi...@netapp.com>
wrote:
> Thanks, Rafael! That very much looks like it could solve the problem.
>
> I've subscribed to the PR for notifications. Once I see it's in the
> codebase, I can re-build my dev environment and see if I still have the
> issue.
> ________________________________________
> From: Rafael Weingärtner <ra...@gmail.com>
> Sent: Monday, April 18, 2016 8:07 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> Basic Zone on 4.9
>
> Would the problem discussed here relate to the one here
> https://github.com/apache/cloudstack/pull/1499?
>
> On Mon, Apr 18, 2016 at 11:04 AM, Tutkowski, Mike <
> Mike.Tutkowski@netapp.com
> > wrote:
>
> > Looks like I already opened a ticket on this in January. :)
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-9224
> >
> > I added info to it.
> > ________________________________________
> > From: Tutkowski, Mike <Mi...@netapp.com>
> > Sent: Saturday, April 16, 2016 9:58 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> > Basic Zone on 4.9
> >
> > Thanks, Adrian!
> >
> > In my case, it's a dev environment, so it's not really hurting anything
> > (it just seems like weird behavior, so I was curious if others were
> seeing
> > it).
> >
> > I can create a ticket in Jira and add your info and mine to it.
> >
> > Thanks again!
> >
> > > On Apr 16, 2016, at 4:43 AM, Adrian Sender <as...@testlabs.com.au>
> > wrote:
> > >
> > > 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 <an...@accelerite.com>
> > > To: "dev@cloudstack.apache.org" <de...@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.Tutkowski@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 <da...@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.Tutkowski@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 <Mi...@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 -------
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
Thanks, Rafael! That very much looks like it could solve the problem.
I've subscribed to the PR for notifications. Once I see it's in the codebase, I can re-build my dev environment and see if I still have the issue.
________________________________________
From: Rafael Weingärtner <ra...@gmail.com>
Sent: Monday, April 18, 2016 8:07 AM
To: dev@cloudstack.apache.org
Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9
Would the problem discussed here relate to the one here
https://github.com/apache/cloudstack/pull/1499?
On Mon, Apr 18, 2016 at 11:04 AM, Tutkowski, Mike <Mike.Tutkowski@netapp.com
> wrote:
> Looks like I already opened a ticket on this in January. :)
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-9224
>
> I added info to it.
> ________________________________________
> From: Tutkowski, Mike <Mi...@netapp.com>
> Sent: Saturday, April 16, 2016 9:58 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> Basic Zone on 4.9
>
> Thanks, Adrian!
>
> In my case, it's a dev environment, so it's not really hurting anything
> (it just seems like weird behavior, so I was curious if others were seeing
> it).
>
> I can create a ticket in Jira and add your info and mine to it.
>
> Thanks again!
>
> > On Apr 16, 2016, at 4:43 AM, Adrian Sender <as...@testlabs.com.au>
> wrote:
> >
> > 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 <an...@accelerite.com>
> > To: "dev@cloudstack.apache.org" <de...@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 <Mi...@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 <da...@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.Tutkowski@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 <Mi...@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 -------
> >
>
--
Rafael Weingärtner
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by Rafael Weingärtner <ra...@gmail.com>.
Would the problem discussed here relate to the one here
https://github.com/apache/cloudstack/pull/1499?
On Mon, Apr 18, 2016 at 11:04 AM, Tutkowski, Mike <Mike.Tutkowski@netapp.com
> wrote:
> Looks like I already opened a ticket on this in January. :)
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-9224
>
> I added info to it.
> ________________________________________
> From: Tutkowski, Mike <Mi...@netapp.com>
> Sent: Saturday, April 16, 2016 9:58 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> Basic Zone on 4.9
>
> Thanks, Adrian!
>
> In my case, it's a dev environment, so it's not really hurting anything
> (it just seems like weird behavior, so I was curious if others were seeing
> it).
>
> I can create a ticket in Jira and add your info and mine to it.
>
> Thanks again!
>
> > On Apr 16, 2016, at 4:43 AM, Adrian Sender <as...@testlabs.com.au>
> wrote:
> >
> > 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 <an...@accelerite.com>
> > To: "dev@cloudstack.apache.org" <de...@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 <Mi...@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 <da...@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.Tutkowski@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 <Mi...@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 -------
> >
>
--
Rafael Weingärtner
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
Looks like I already opened a ticket on this in January. :)
https://issues.apache.org/jira/browse/CLOUDSTACK-9224
I added info to it.
________________________________________
From: Tutkowski, Mike <Mi...@netapp.com>
Sent: Saturday, April 16, 2016 9:58 AM
To: dev@cloudstack.apache.org
Subject: Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9
Thanks, Adrian!
In my case, it's a dev environment, so it's not really hurting anything (it just seems like weird behavior, so I was curious if others were seeing it).
I can create a ticket in Jira and add your info and mine to it.
Thanks again!
> On Apr 16, 2016, at 4:43 AM, Adrian Sender <as...@testlabs.com.au> wrote:
>
> 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 <an...@accelerite.com>
> To: "dev@cloudstack.apache.org" <de...@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 <Mi...@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 <da...@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 <Mi...@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 <Mi...@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 -------
>
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
Thanks, Adrian!
In my case, it's a dev environment, so it's not really hurting anything (it just seems like weird behavior, so I was curious if others were seeing it).
I can create a ticket in Jira and add your info and mine to it.
Thanks again!
> On Apr 16, 2016, at 4:43 AM, Adrian Sender <as...@testlabs.com.au> wrote:
>
> 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 <an...@accelerite.com>
> To: "dev@cloudstack.apache.org" <de...@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 <Mi...@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 <da...@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 <Mi...@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 <Mi...@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 -------
>
Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9
Posted by Adrian Sender <as...@testlabs.com.au>.
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 <an...@accelerite.com>
To: "dev@cloudstack.apache.org" <de...@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 <Mi...@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 <da...@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 <Mi...@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 <Mi...@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 -------
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by Anshul Gangwar <an...@accelerite.com>.
Mike, what type of storage are you using?
> On 15-Apr-2016, at 9:49 AM, Tutkowski, Mike <Mi...@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 <da...@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 <Mi...@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 <Mi...@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.
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
I'm not sure, Daan.
I plan to keep an eye on this behavior for a while when creating new clouds.
________________________________________
From: Daan Hoogland <da...@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 <Mi...@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 <Mi...@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
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by Daan Hoogland <da...@gmail.com>.
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 <Mi...@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 <Mi...@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
Re: Strange XenServer SR behavior when deploying system VMs in Basic
Zone on 4.9
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
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 <Mi...@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