Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Tutkowski, Mike]

Just an FYI that I no longer see this problem (as was expected).

Thanks!

From: Tutkowski, Mike <mike.tutkow...@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 <rafaelweingart...@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 <mike.tutkow...@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 <rafaelweingart...@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.tutkow...@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 <mike.tutkow...@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 <asen...@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
> > >
> >

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Tutkowski, Mike]

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 <rafaelweingart...@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 <mike.tutkow...@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 <rafaelweingart...@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.tutkow...@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 <mike.tutkow...@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 <asen...@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=
> > >
> > > Now you can delete the disk from xencenter
> > >
> > > Regards,
> > > Adrian Sender
> > >
> > >
> > >
> > > ------ Original Message --

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Rafael Weingärtner]

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 <mike.tutkow...@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 <rafaelweingart...@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.tutkow...@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 <mike.tutkow...@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 <asen...@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=
> > >
> > > 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 +
> > > Subject: Re: Strange XenServer SR behavior when deploying system VMs in
> > Basic
> > > Zone on 4.9
> > &

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Tutkowski, Mike]

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 <rafaelweingart...@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.tutkow...@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 <mike.tutkow...@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 <asen...@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=
> >
> > 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 +
> > 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 rema

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Rafael Weingärtner]

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.tutkow...@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 <mike.tutkow...@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 <asen...@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=
> >
> > 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 +
> > 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

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Tutkowski, Mike]

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 <mike.tutkow...@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 <asen...@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=
>
> 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 +
> 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

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Tutkowski, Mike]

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 <asen...@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=
> 
> 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 +
> 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, 

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Adrian Sender]

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=

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 +
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 ---

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Tutkowski, Mike]

Hi,

The system VMs are just running on local storage.

Thanks,
Mike

> On Apr 15, 2016, at 12:49 AM, Anshul Gangwar <anshul.gang...@accelerite.com> 
> wrote:
> 
> 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.

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Anshul Gangwar]

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.

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Tutkowski, Mike]

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

Re: Strange XenServer SR behavior when deploying system VMs in Basic Zone on 4.9

[Daan Hoogland]

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 
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 
> 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

[Tutkowski, Mike]

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 
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