[xs-devel] VM copy between pools

[Iñigo Martinez Lasala]

Hi everybody.

Does anybody know what criteria must accomplish a VM for be copied between
pools (with the VM shutdown)?

We have been working with several Xenserver 6.5 and 7.0 pools and we have
not found when we can use this feature. We have checked if there are
snapshots, if there are vGPU assigned, different OS (Windows 2008, 2012,
Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver versions, but
the true is that some of then can be copied and some not without
identifying any common pattern.

Thanks in advance.

[Tobias Kreidl]

For 7.0, the main issue I can think of would be XenTools.

Post by Iñigo Martinez Lasala
Hi everybody.
Does anybody know what criteria must accomplish a VM for be copied
between pools (with the VM shutdown)?
We have been working with several Xenserver 6.5 and 7.0 pools and we
have not found when we can use this feature. We have checked if there
are snapshots, if there are vGPU assigned, different OS (Windows 2008,
2012, Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver
versions, but the true is that some of then can be copied and some not
without identifying any common pattern.
Thanks in advance.

[Iñigo Martinez Lasala]

Hi Tobias.

But if VM is shut down that should not matter...
We will check on Monday.

Thank you!

Post by Tobias Kreidl
For 7.0, the main issue I can think of would be XenTools.
Hi everybody.
Does anybody know what criteria must accomplish a VM for be copied between
pools (with the VM shutdown)?
We have been working with several Xenserver 6.5 and 7.0 pools and we have
not found when we can use this feature. We have checked if there are
snapshots, if there are vGPU assigned, different OS (Windows 2008, 2012,
Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver versions, but
the true is that some of then can be copied and some not without
identifying any common pattern.
Thanks in advance.

[Tobias Kreidl]

I agree. I do not recall running into this issue under Dundee TP3.

Post by Iñigo Martinez Lasala
Hi Tobias.
But if VM is shut down that should not matter...
We will check on Monday.
Thank you!
For 7.0, the main issue I can think of would be XenTools.

Post by Iñigo Martinez Lasala
Hi everybody.
Does anybody know what criteria must accomplish a VM for be
copied between pools (with the VM shutdown)?
We have been working with several Xenserver 6.5 and 7.0 pools and
we have not found when we can use this feature. We have checked
if there are snapshots, if there are vGPU assigned, different OS
(Windows 2008, 2012, Ubuntu), type of virtualization (HVM, PV or
PVHVM), Xenserver versions, but the true is that some of then can
be copied and some not without identifying any common pattern.
Thanks in advance.

[Andrew Halley]

From engineering :

Do you use XenCenter or CLI? When you say some VMs can not be copied, what actually happens when you try to do so?

For any VM that you couldn't do the copy, could you try to storage migration it (running or halted) to your destination pool? If that works, I can't see why the copy wouldn't. Effectively the copy is just a special mode ("copy" mode) of the storage migration, which will leave the original VM untouched and change a few things on destination VM to distinguish it from the source VM. They shares the similar "assert-can-migrate" judgement.

________________________________

From: Tobias Kreidl <***@nau.edu>
Date: 27 May 2016 at 23:59:12 BST
To: xs-***@lists.xenserver.org <xs-***@lists.xenserver.org>, ***@playgiga.com <***@playgiga.com>
Subject: Re: [xs-devel] VM copy between pools

I agree. I do not recall running into this issue under Dundee TP3.

On 5/27/2016 11:15 AM, I?igo Martinez Lasala wrote:

Hi Tobias.

But if VM is shut down that should not matter...
We will check on Monday.

Thank you!

El 27 may. 2016 16:45, "Tobias Kreidl" <***@nau.edu<mailto:***@nau.edu>> escribi?:
For 7.0, the main issue I can think of would be XenTools.

On 5/27/2016 5:11 AM, I?igo Martinez Lasala wrote:
Hi everybody.

Does anybody know what criteria must accomplish a VM for be copied between pools (with the VM shutdown)?

We have been working with several Xenserver 6.5 and 7.0 pools and we have not found when we can use this feature. We have checked if there are snapshots, if there are vGPU assigned, different OS (Windows 2008, 2012, Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver versions, but the true is that some of then can be copied and some not without identifying any common pattern.

Thanks in advance.

[Iñigo Martinez Lasala]

Hi.

I use Xencenter.

Those machines that can be copied to another pool give you the option when
copying to select your pool or another pool as destination.

Those that cannot directly show the standard window for copy in your pool
(full copy or fast clone) without giving the option for pool selection.

Post by Andrew Halley
Do you use XenCenter or CLI? When you say some VMs can not be copied, what
actually happens when you try to do so?
For any VM that you couldn't do the copy, could you try to storage
migration it (running or halted) to your destination pool? If that works, I
can't see why the copy wouldn't. Effectively the copy is just a special
mode ("copy" mode) of the storage migration, which will leave the original
VM untouched and change a few things on destination VM to distinguish it
from the source VM. They shares the similar "assert-can-migrate" judgement.
------------------------------
*Date:* 27 May 2016 at 23:59:12 BST
*Subject:* Re: [xs-devel] VM copy between pools
I agree. I do not recall running into this issue under Dundee TP3.
Hi Tobias.
But if VM is shut down that should not matter...
We will check on Monday.
Thank you!

Post by Tobias Kreidl
For 7.0, the main issue I can think of would be XenTools.
Hi everybody.
Does anybody know what criteria must accomplish a VM for be copied
between pools (with the VM shutdown)?
We have been working with several Xenserver 6.5 and 7.0 pools and we have
not found when we can use this feature. We have checked if there are
snapshots, if there are vGPU assigned, different OS (Windows 2008, 2012,
Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver versions, but
the true is that some of then can be copied and some not without
identifying any common pattern.
Thanks in advance.

[Andrew Halley]

From Engineering :
----
HI,

I tried to reproduce the issue based on your description. I created various VM configurations, but I couldn't reproduce the situation you described.

The difference is, I always see a "copy VM" entry on the context menu of a halted VM, disregarding what the VM is (even a dummy VM), and the "copy VM" entry always lead me to the selection page with both options ("Within pool" or "Cross-pool"). This does not imply one can always migrate/copy VM of any configuration/state, as the "Cross-pool" option might eventually lead to an empty list of destination pools or a set of pool candidates all grayed out (due to various restrictions). But since I can always reach the selection page at least, this is different from the situation you described.

I couldn't figure out what exactly caused the difference without more detailed information. Here are a few things you could check and experiment with:

* Make sure you are using the latest XenCenter, and make sure the operator has enough privilege in both the source and destination pool
* Tried the suggestion in my previous comment to see if XenCenter allow you to move/migrate the same VM to the destination instead of copy.
* Try to use the corresponding xe CLI directly to see if that fails and why. The CLI is something like "xe vm-migrate vm=XXXX copy=true remote-master=xxx remote-username=xxx remote-password=xxx vif:xxxx=xxxx"
* It would be very useful if you could generate some logs (right after you try the "copy VM" click and can't see the selection page you'd expect) and then send to us. This could be either a complete status-report generated via XenCenter, or at least the following items (XenCenter log, /var/log/xensource.log, and a data dump generated by "xe pool-dump-database").

Cheers,
----

________________________________

From: Iñigo Martinez Lasala <***@playgiga.com>
Date: 28 May 2016 at 09:58:07 BST
To: Andrew Halley <***@citrix.com>
Cc: xs-***@lists.xenserver.org <xs-***@lists.xenserver.org>
Subject: Re: [xs-devel] VM copy between pools


Hi.

I use Xencenter.

Those machines that can be copied to another pool give you the option when copying to select your pool or another pool as destination.

Those that cannot directly show the standard window for copy in your pool (full copy or fast clone) without giving the option for pool selection.

El 28 may. 2016 8:57, "Andrew Halley" <***@citrix.com<mailto:***@citrix.com>> escribió:
From engineering :

Do you use XenCenter or CLI? When you say some VMs can not be copied, what actually happens when you try to do so?

For any VM that you couldn't do the copy, could you try to storage migration it (running or halted) to your destination pool? If that works, I can't see why the copy wouldn't. Effectively the copy is just a special mode ("copy" mode) of the storage migration, which will leave the original VM untouched and change a few things on destination VM to distinguish it from the source VM. They shares the similar "assert-can-migrate" judgement.

________________________________

From: Tobias Kreidl <***@nau.edu<mailto:***@nau.edu>>
Date: 27 May 2016 at 23:59:12 BST
To: xs-***@lists.xenserver.org<mailto:xs-***@lists.xenserver.org> <xs-***@lists.xenserver.org<mailto:xs-***@lists.xenserver.org>>, ***@playgiga.com<mailto:***@playgiga.com> <***@playgiga.com<mailto:***@playgiga.com>>
Subject: Re: [xs-devel] VM copy between pools

I agree. I do not recall running into this issue under Dundee TP3.

On 5/27/2016 11:15 AM, Iñigo Martinez Lasala wrote:

Hi Tobias.

But if VM is shut down that should not matter...
We will check on Monday.

Thank you!

El 27 may. 2016 16:45, "Tobias Kreidl" <***@nau.edu<mailto:***@nau.edu>> escribió:
For 7.0, the main issue I can think of would be XenTools.

On 5/27/2016 5:11 AM, Iñigo Martinez Lasala wrote:
Hi everybody.

Does anybody know what criteria must accomplish a VM for be copied between pools (with the VM shutdown)?

We have been working with several Xenserver 6.5 and 7.0 pools and we have not found when we can use this feature. We have checked if there are snapshots, if there are vGPU assigned, different OS (Windows 2008, 2012, Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver versions, but the true is that some of then can be copied and some not without identifying any common pattern.

Thanks in advance.

[Stephen Turner]

The code that restricts this are the functions CanExecute(VM vm, Host preselectedHost) in these two files (called with preselectedHost==null):

https://github.com/xenserver/xenadmin/blob/master/XenAdmin/Commands/CrossPoolMigrateCommand.cs
https://github.com/xenserver/xenadmin/blob/master/XenAdmin/Commands/CrossPoolCopyVMCommand.cs

I can’t see much obvious in here. You’ve said that the VM is halted, which would otherwise be the most obvious thing. The allowed_operations has to include migrate_send, but presumably it does if it’s succeeding from the command line. If XenServer is 6.5, then WLB prevents migration: could that explain it? The only other thing is that the VM has to be not Locked, but that should be a transient state during another operation.
--
Stephen



From: xs-devel-***@lists.xenserver.org [mailto:xs-devel-***@lists.xenserver.org] On Behalf Of Iñigo Martinez Lasala
Sent: 30 May 2016 10:59
To: Andrew Halley <***@citrix.com>
Cc: xs-***@lists.xenserver.org
Subject: Re: [xs-devel] VM copy between pools

Hi Andrew.

I've tested with your suggestions. With xe cli there is no problem and I can copy all VMs to destination pool without any problem. So, it appears to be a Xencenter problem and not a Xenserver problem.

I've included you some screenshots. Xenserver version is latest one included with Xenserver 7.0.0.

And now the funny final scene... after executing a xe vm-migrate from command line and starting copying vm, Xencenter shows the "copy icon". Cancel and after that... voilá... I can manually copy previously locked VMs to destination from graphical interface for all previously "not allowed" VMs... !!! WTF !! :-O


2016-05-29 16:55 GMT+02:00 Andrew Halley <***@citrix.com<mailto:***@citrix.com>>:
From Engineering :
----
HI,

I tried to reproduce the issue based on your description. I created various VM configurations, but I couldn't reproduce the situation you described.

The difference is, I always see a "copy VM" entry on the context menu of a halted VM, disregarding what the VM is (even a dummy VM), and the "copy VM" entry always lead me to the selection page with both options ("Within pool" or "Cross-pool"). This does not imply one can always migrate/copy VM of any configuration/state, as the "Cross-pool" option might eventually lead to an empty list of destination pools or a set of pool candidates all grayed out (due to various restrictions). But since I can always reach the selection page at least, this is different from the situation you described.

I couldn't figure out what exactly caused the difference without more detailed information. Here are a few things you could check and experiment with:

* Make sure you are using the latest XenCenter, and make sure the operator has enough privilege in both the source and destination pool
* Tried the suggestion in my previous comment to see if XenCenter allow you to move/migrate the same VM to the destination instead of copy.
* Try to use the corresponding xe CLI directly to see if that fails and why. The CLI is something like "xe vm-migrate vm=XXXX copy=true remote-master=xxx remote-username=xxx remote-password=xxx vif:xxxx=xxxx"
* It would be very useful if you could generate some logs (right after you try the "copy VM" click and can't see the selection page you'd expect) and then send to us. This could be either a complete status-report generated via XenCenter, or at least the following items (XenCenter log, /var/log/xensource.log, and a data dump generated by "xe pool-dump-database").

Cheers,
----

________________________________

From: Iñigo Martinez Lasala <***@playgiga.com<mailto:***@playgiga.com>>
Date: 28 May 2016 at 09:58:07 BST
To: Andrew Halley <***@citrix.com<mailto:***@citrix.com>>
Cc: xs-***@lists.xenserver.org<mailto:xs-***@lists.xenserver.org> <xs-***@lists.xenserver.org<mailto:xs-***@lists.xenserver.org>>

Subject: Re: [xs-devel] VM copy between pools


Hi.

I use Xencenter.

Those machines that can be copied to another pool give you the option when copying to select your pool or another pool as destination.

Those that cannot directly show the standard window for copy in your pool (full copy or fast clone) without giving the option for pool selection.
El 28 may. 2016 8:57, "Andrew Halley" <***@citrix.com<mailto:***@citrix.com>> escribió:
From engineering :

Do you use XenCenter or CLI? When you say some VMs can not be copied, what actually happens when you try to do so?

For any VM that you couldn't do the copy, could you try to storage migration it (running or halted) to your destination pool? If that works, I can't see why the copy wouldn't. Effectively the copy is just a special mode ("copy" mode) of the storage migration, which will leave the original VM untouched and change a few things on destination VM to distinguish it from the source VM. They shares the similar "assert-can-migrate" judgement.

________________________________

From: Tobias Kreidl <***@nau.edu<mailto:***@nau.edu>>
Date: 27 May 2016 at 23:59:12 BST
To: xs-***@lists.xenserver.org<mailto:xs-***@lists.xenserver.org> <xs-***@lists.xenserver.org<mailto:xs-***@lists.xenserver.org>>, ***@playgiga.com<mailto:***@playgiga.com> <***@playgiga.com<mailto:***@playgiga.com>>
Subject: Re: [xs-devel] VM copy between pools

I agree. I do not recall running into this issue under Dundee TP3.

On 5/27/2016 11:15 AM, Iñigo Martinez Lasala wrote:

Hi Tobias.

But if VM is shut down that should not matter...
We will check on Monday.

Thank you!
El 27 may. 2016 16:45, "Tobias Kreidl" <***@nau.edu<mailto:***@nau.edu>> escribió:
For 7.0, the main issue I can think of would be XenTools.

On 5/27/2016 5:11 AM, Iñigo Martinez Lasala wrote:
Hi everybody.

Does anybody know what criteria must accomplish a VM for be copied between pools (with the VM shutdown)?

We have been working with several Xenserver 6.5 and 7.0 pools and we have not found when we can use this feature. We have checked if there are snapshots, if there are vGPU assigned, different OS (Windows 2008, 2012, Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver versions, but the true is that some of then can be copied and some not without identifying any common pattern.

Thanks in advance.
--
[Image removed by sender. PlayGiga]<http://www.playgiga.com/>

Iñigo Martinez Lasala
System Manager
[phone]

[Image removed by sender. Profile on linkedin]<http://es.linkedin.com/in/inigoml> [Image removed by sender. Profile on Twitter] <https://twitter.com/inigoml2> [Image removed by sender. skype alberto.zuya] inigoml

[phone] - Avenida de Burgos 12, 2-D 28036 Madrid
www.playgiga.com<http://www.playgiga.com>

[Tobias Kreidl]

Given that it will be possible under XenDesktop 7.9 MCS to split from
the main vDisk where the difference disk location goes, this makes it
possible to for instance leverage local SRs to hold these data. That's
great, but if the server crashes, is it assumed there will be a local SR
available when the VM restarts on a different server in the XenServer
pool, and if not, what happens -- does it fall back to the same pooled
storage on which the VM resides?

Also, note that if IntelliCache is used, the upgrade to XS 7.0 if going
to the new disk layout will totally wipe out any local SRs, and so any
and all will need to be re-created, including the IntelliCache ext3
ones. In any case, is it safe to assume the necessary storage will be
re-created as needed, but if originally specified to be on local
storage, will it be attempted to redo the layout the way it was
originally specified?

Ergo, => _Please_ improve the documentation on both the XS upgrade
procedure going from 6.5 to 7.0 and reverting and all, which doesn't
cover the specifics in adequate detail and also give some guidelines as
to some good choices (best practices) for the MCS-based storage
allocations and how server failures are handled regarding storage
(re)allocation.

One big issue still unresolved is that While XenServer has supported
storage Xenmotion for some time, this is _still_ not an option with VM
storage under XenDesktop runnin gon XenServer. It would be really nice
to be able to re-balance the storage load and not be stuck having to
reprovision to get a VM's storage to be relocated to a different SR.

That all said, XS 7.0 has some fantastic new features and optimizations.
This is a great release, people!

Thank you,
--Tobias

[Andrew Halley]

Hi Tobias, it's a uk public holiday this weekend. I have asked the day's other team to answer your question in full on their return in Tuesday. Andy

________________________________

From: Tobias Kreidl <***@nau.edu>
Date: 29 May 2016 at 19:06:43 BST
To: xs-***@lists.xenserver.org <xs-***@lists.xenserver.org>
Cc: Tobias Kreidl <***@nau.edu>
Subject: Re: [xs-devel] XenDesktop 7.9 MCS and storage under XS 7.0

Anybody home (or are most of you too exhausted from Synergy/E2EVC? :-)

On 5/28/2016 9:35 AM, Tobias Kreidl wrote:
Given that it will be possible under XenDesktop 7.9 MCS to split from the main vDisk where the difference disk location goes, this makes it possible to for instance leverage local SRs to hold these data. That's great, but if the server crashes, is it assumed there will be a local SR available when the VM restarts on a different server in the XenServer pool, and if not, what happens -- does it fall back to the same pooled storage on which the VM resides?

Also, note that if IntelliCache is used, the upgrade to XS 7.0 if going to the new disk layout will totally wipe out any local SRs, and so any and all will need to be re-created, including the IntelliCache ext3 ones. In any case, is it safe to assume the necessary storage will be re-created as needed, but if originally specified to be on local storage, will it be attempted to redo the layout the way it was originally specified?

Ergo, => Please improve the documentation on both the XS upgrade procedure going from 6.5 to 7.0 and reverting and all, which doesn't cover the specifics in adequate detail and also give some guidelines as to some good choices (best practices) for the MCS-based storage allocations and how server failures are handled regarding storage (re)allocation.

One big issue still unresolved is that While XenServer has supported storage Xenmotion for some time, this is still not an option with VM storage under XenDesktop runnin gon XenServer. It would be really nice to be able to re-balance the storage load and not be stuck having to reprovision to get a VM's storage to be relocated to a different SR.

That all said, XS 7.0 has some fantastic new features and optimizations. This is a great release, people!

Thank you,
--Tobias

[Tobias Kreidl]

OK, thank you, Andy! Monday is a holiday here, as well, but you know how
I feel in general about most holidays. :-D
Cheers,
--Tobias

P.S. Great Synergy and E2EVC sessions on XenServer. Super advancements
and just a few more important add-ons needed to have an even more
fantastic product.

Post by Andrew Halley
Hi Tobias, it's a uk public holiday this weekend. I have asked the
day's other team to answer your question in full on their return in
Tuesday. Andy
------------------------------------------------------------------------
*Date:* 29 May 2016 at 19:06:43 BST
*Subject:* Re: [xs-devel] XenDesktop 7.9 MCS and storage under XS 7.0
Anybody home (or are most of you too exhausted from Synergy/E2EVC? :-)

Post by Tobias Kreidl
Given that it will be possible under XenDesktop 7.9 MCS to split from
the main vDisk where the difference disk location goes, this makes it
possible to for instance leverage local SRs to hold these data.
That's great, but if the server crashes, is it assumed there will be
a local SR available when the VM restarts on a different server in
the XenServer pool, and if not, what happens -- does it fall back to
the same pooled storage on which the VM resides?
Also, note that if IntelliCache is used, the upgrade to XS 7.0 if
going to the new disk layout will totally wipe out any local SRs, and
so any and all will need to be re-created, including the IntelliCache
ext3 ones. In any case, is it safe to assume the necessary storage
will be re-created as needed, but if originally specified to be on
local storage, will it be attempted to redo the layout the way it was
originally specified?
Ergo, => _Please_ improve the documentation on both the XS upgrade
procedure going from 6.5 to 7.0 and reverting and all, which doesn't
cover the specifics in adequate detail and also give some guidelines
as to some good choices (best practices) for the MCS-based storage
allocations and how server failures are handled regarding storage
(re)allocation.
One big issue still unresolved is that While XenServer has supported
storage Xenmotion for some time, this is _still_ not an option with
VM storage under XenDesktop runnin gon XenServer. It would be really
nice to be able to re-balance the storage load and not be stuck
having to reprovision to get a VM's storage to be relocated to a
different SR.
That all said, XS 7.0 has some fantastic new features and
optimizations. This is a great release, people!
Thank you,
--Tobias

[Mark Syms]

With regard to

"Given that it will be possible under XenDesktop 7.9 MCS to split from the main vDisk where the difference disk location goes, this makes it possible to for instance leverage local SRs to hold these data. That's great, but if the server crashes, is it assumed there will be a local SR available when the VM restarts on a different server in the XenServer pool, and if not, what happens -- does it fall back to the same pooled storage on which the VM resides?"

This is entirely XenDesktop behaviour and independent of the Hypervisor in use. If local storage is used as the temporary cache layer (as opposed to separate cheaper shared storage than that used to host the master images) then the VMs will be tied to host with this local storage and this is the case with all supported Hypervisors.

With regard to

"One big issue still unresolved is that While XenServer has supported storage Xenmotion for some time, this is still not an option with VM storage under XenDesktop runnin gon XenServer. It would be really nice to be able to re-balance the storage load and not be stuck having to reprovision to get a VM's storage to be relocated to a different SR."

This again is a XenDesktop problem to solve as it needs to be contextually aware of the location of all the disks and deltas for the machines in the catalog. Moving disks using Storage Motion (on any hypervisor) will lead to XenDesktop having major confusion about the location of disks. There are a number of items about this in the XenDesktop requirements backlog.

Thanks,

Mark.

[Tobias Kreidl]

Mark,
Comments in-line.

Thank you,
--Tobias



With regard to

"Given that it will be possible under XenDesktop 7.9 MCS to split from the main vDisk where the difference disk location goes, this makes it possible to for instance leverage local SRs to hold these data. That's great, but if the server crashes, is it assumed there will be a local SR available when the VM restarts on a different server in the XenServer pool, and if not, what happens -- does it fall back to the same pooled storage on which the VM resides?"

This is entirely XenDesktop behaviour and independent of the Hypervisor in use. If local storage is used as the temporary cache layer (as opposed to separate cheaper shared storage than that used to host the master images) then the VMs will be tied to host with this local storage and this is the case with all supported Hypervisors.

/Yes, of course it's tied to the host using the local storage. The
question is if the VM crashes and starts on a new host, how does the VM
choose what it then uses as an SR for the difference disk? Does it (1)
look for a local SR on that new host and create it there, or (2) default
or fall back to the pooled SR on which the main vDisk resides? I just
want to know if a VM is started on a different XenServer in the pool,
where does the diff disk get re-created under these circumstances?/



With regard to

"One big issue still unresolved is that While XenServer has supported storage Xenmotion for some time, this is still not an option with VM storage under XenDesktop runnin gon XenServer. It would be really nice to be able to re-balance the storage load and not be stuck having to reprovision to get a VM's storage to be relocated to a different SR."

This again is a XenDesktop problem to solve as it needs to be contextually aware of the location of all the disks and deltas for the machines in the catalog. Moving disks using Storage Motion (on any hypervisor) will lead to XenDesktop having major confusion about the location of disks. There are a number of items about this in the XenDesktop requirements backlog.

/I understand this is the current situation. What I'm asking is why in
the world would you support storage Xenmotion for years under XenServer
and yet not allow XenDesktops to leverage this? All that information is
in a DB for XenDesktop; it has to be put there when the VM is
provisioned in the first place. It would appear you are you saying that
XenServer is not XenDesktop aware. That being the case, are there any
plans to change this or is this not something you see asked about much?/

Thanks,

Mark.

[Mark Syms]

Clarification inline

Mark,
Comments in-line.

Thank you,
--Tobias




With regard to

"Given that it will be possible under XenDesktop 7.9 MCS to split from the main vDisk where the difference disk location goes, this makes it possible to for instance leverage local SRs to hold these data. That's great, but if the server crashes, is it assumed there will be a local SR available when the VM restarts on a different server in the XenServer pool, and if not, what happens -- does it fall back to the same pooled storage on which the VM resides?"

This is entirely XenDesktop behaviour and independent of the Hypervisor in use. If local storage is used as the temporary cache layer (as opposed to separate cheaper shared storage than that used to host the master images) then the VMs will be tied to host with this local storage and this is the case with all supported Hypervisors.

Yes, of course it's tied to the host using the local storage. The question is if the VM crashes and starts on a new host, how does the VM choose what it then uses as an SR for the difference disk? Does it (1) look for a local SR on that new host and create it there, or (2) default or fall back to the pooled SR on which the main vDisk resides? I just want to know if a VM is started on a different XenServer in the pool, where does the diff disk get re-created under these circumstances?

[Mark Syms] If the VM crashes it won't restart on a different host, it can only ever start on the host that has the local SR that its temporary cache disk is located on.

With regard to

"One big issue still unresolved is that While XenServer has supported storage Xenmotion for some time, this is still not an option with VM storage under XenDesktop runnin gon XenServer. It would be really nice to be able to re-balance the storage load and not be stuck having to reprovision to get a VM's storage to be relocated to a different SR."

This again is a XenDesktop problem to solve as it needs to be contextually aware of the location of all the disks and deltas for the machines in the catalog. Moving disks using Storage Motion (on any hypervisor) will lead to XenDesktop having major confusion about the location of disks. There are a number of items about this in the XenDesktop requirements backlog.

I understand this is the current situation. What I'm asking is why in the world would you support storage Xenmotion for years under XenServer and yet not allow XenDesktops to leverage this? All that information is in a DB for XenDesktop; it has to be put there when the VM is provisioned in the first place. It would appear you are you saying that XenServer is not XenDesktop aware. That being the case, are there any plans to change this or is this not something you see asked about much?

[Mark Syms] No, I'm saying that XenServer can't in the case of doing storage migration go and update the XenDesktop database (especially as there may in a worst case scenario be multiple XenDesktop sites utilising a single XenServer pool and the VM migrated may not be a XenDesktop machine). The migration process has to be driven from the XenDesktop side and that functionality doesn't yet exist.

[Tobias Kreidl]

I see. As to flexibility and high availability, not being able to use
anything but the original local host is a real limitation. Ditto for not
supporting storage Xenmotion. I do hope these are considered for future
releases. I do see that both are specific to being able to track and
update DB information intrinsic to the VM's storage configuration.

Thanks for the clarifications, Mark.

Regards,
--Tobias

Post by Mark Syms
Clarification inline
Mark,
Comments in-line.
Thank you,
--Tobias
With regard to
"Given that it will be possible under XenDesktop 7.9 MCS to split from the main vDisk where the difference disk location goes, this makes it possible to for instance leverage local SRs to hold these data. That's great, but if the server crashes, is it assumed there will be a local SR available when the VM restarts on a different server in the XenServer pool, and if not, what happens -- does it fall back to the same pooled storage on which the VM resides?"
This is entirely XenDesktop behaviour and independent of the Hypervisor in use. If local storage is used as the temporary cache layer (as opposed to separate cheaper shared storage than that used to host the master images) then the VMs will be tied to host with this local storage and this is the case with all supported Hypervisors.
Yes, of course it's tied to the host using the local storage. The question is if the VM crashes and starts on a new host, how does the VM choose what it then uses as an SR for the difference disk? Does it (1) look for a local SR on that new host and create it there, or (2) default or fall back to the pooled SR on which the main vDisk resides? I just want to know if a VM is started on a different XenServer in the pool, where does the diff disk get re-created under these circumstances?
[Mark Syms] If the VM crashes it won't restart on a different host, it can only ever start on the host that has the local SR that its temporary cache disk is located on.
With regard to
"One big issue still unresolved is that While XenServer has supported storage Xenmotion for some time, this is still not an option with VM storage under XenDesktop runnin gon XenServer. It would be really nice to be able to re-balance the storage load and not be stuck having to reprovision to get a VM's storage to be relocated to a different SR."
This again is a XenDesktop problem to solve as it needs to be contextually aware of the location of all the disks and deltas for the machines in the catalog. Moving disks using Storage Motion (on any hypervisor) will lead to XenDesktop having major confusion about the location of disks. There are a number of items about this in the XenDesktop requirements backlog.
I understand this is the current situation. What I'm asking is why in the world would you support storage Xenmotion for years under XenServer and yet not allow XenDesktops to leverage this? All that information is in a DB for XenDesktop; it has to be put there when the VM is provisioned in the first place. It would appear you are you saying that XenServer is not XenDesktop aware. That being the case, are there any plans to change this or is this not something you see asked about much?
[Mark Syms] No, I'm saying that XenServer can't in the case of doing storage migration go and update the XenDesktop database (especially as there may in a worst case scenario be multiple XenDesktop sites utilising a single XenServer pool and the VM migrated may not be a XenDesktop machine). The migration process has to be driven from the XenDesktop side and that functionality doesn't yet exist.

[Stephen Turner]

Tobias, I think you need to take these to your XD contacts, rather than to xs-devel. As a customer, you probably have more influence over them than we do!

--
Stephen


From: xs-devel-***@lists.xenserver.org [mailto:xs-devel-***@lists.xenserver.org] On Behalf Of Tobias Kreidl
Sent: 01 June 2016 17:17
To: xs-***@lists.xenserver.org
Cc: Tobias Kreidl <***@NAU.EDU>
Subject: Re: [xs-devel] XenDesktop 7.9 MCS and storage under XS 7.0

I see. As to flexibility and high availability, not being able to use anything but the original local host is a real limitation. Ditto for not supporting storage Xenmotion. I do hope these are considered for future releases. I do see that both are specific to being able to track and update DB information intrinsic to the VM's storage configuration.

Thanks for the clarifications, Mark.

Regards,
--Tobias

On 6/1/2016 9:11 AM, Mark Syms wrote:

Clarification inline



Mark,

Comments in-line.



Thank you,

--Tobias









With regard to



"Given that it will be possible under XenDesktop 7.9 MCS to split from the main vDisk where the difference disk location goes, this makes it possible to for instance leverage local SRs to hold these data. That's great, but if the server crashes, is it assumed there will be a local SR available when the VM restarts on a different server in the XenServer pool, and if not, what happens -- does it fall back to the same pooled storage on which the VM resides?"



This is entirely XenDesktop behaviour and independent of the Hypervisor in use. If local storage is used as the temporary cache layer (as opposed to separate cheaper shared storage than that used to host the master images) then the VMs will be tied to host with this local storage and this is the case with all supported Hypervisors.



Yes, of course it's tied to the host using the local storage. The question is if the VM crashes and starts on a new host, how does the VM choose what it then uses as an SR for the difference disk? Does it (1) look for a local SR on that new host and create it there, or (2) default or fall back to the pooled SR on which the main vDisk resides? I just want to know if a VM is started on a different XenServer in the pool, where does the diff disk get re-created under these circumstances?



[Mark Syms] If the VM crashes it won't restart on a different host, it can only ever start on the host that has the local SR that its temporary cache disk is located on.



With regard to



"One big issue still unresolved is that While XenServer has supported storage Xenmotion for some time, this is still not an option with VM storage under XenDesktop runnin gon XenServer. It would be really nice to be able to re-balance the storage load and not be stuck having to reprovision to get a VM's storage to be relocated to a different SR."



This again is a XenDesktop problem to solve as it needs to be contextually aware of the location of all the disks and deltas for the machines in the catalog. Moving disks using Storage Motion (on any hypervisor) will lead to XenDesktop having major confusion about the location of disks. There are a number of items about this in the XenDesktop requirements backlog.



I understand this is the current situation. What I'm asking is why in the world would you support storage Xenmotion for years under XenServer and yet not allow XenDesktops to leverage this? All that information is in a DB for XenDesktop; it has to be put there when the VM is provisioned in the first place. It would appear you are you saying that XenServer is not XenDesktop aware. That being the case, are there any plans to change this or is this not something you see asked about much?



[Mark Syms] No, I'm saying that XenServer can't in the case of doing storage migration go and update the XenDesktop database (especially as there may in a worst case scenario be multiple XenDesktop sites utilising a single XenServer pool and the VM migrated may not be a XenDesktop machine). The migration process has to be driven from the XenDesktop side and that functionality doesn't yet exist.

[Tobias Kreidl]

Stephen,
OK, I am willing to do that. I will also post it on the Podio CTP "wish
list".

Thank you,
--Tobias

Post by Stephen Turner
Tobias, I think you need to take these to your XD contacts, rather
than to xs-devel. As a customer, you probably have more influence over
them than we do!
--
Stephen
*Sent:* 01 June 2016 17:17
*Subject:* Re: [xs-devel] XenDesktop 7.9 MCS and storage under XS 7.0
I see. As to flexibility and high availability, not being able to use
anything but the original local host is a real limitation. Ditto for
not supporting storage Xenmotion. I do hope these are considered for
future releases. I do see that both are specific to being able to
track and update DB information intrinsic to the VM's storage
configuration.
Thanks for the clarifications, Mark.
Regards,
--Tobias
Clarification inline
Mark,
Comments in-line.
Thank you,
--Tobias
With regard to
"Given that it will be possible under XenDesktop 7.9 MCS to split from the main vDisk where the difference disk location goes, this makes it possible to for instance leverage local SRs to hold these data. That's great, but if the server crashes, is it assumed there will be a local SR available when the VM restarts on a different server in the XenServer pool, and if not, what happens -- does it fall back to the same pooled storage on which the VM resides?"
This is entirely XenDesktop behaviour and independent of the Hypervisor in use. If local storage is used as the temporary cache layer (as opposed to separate cheaper shared storage than that used to host the master images) then the VMs will be tied to host with this local storage and this is the case with all supported Hypervisors.
Yes, of course it's tied to the host using the local storage. The question is if the VM crashes and starts on a new host, how does the VM choose what it then uses as an SR for the difference disk? Does it (1) look for a local SR on that new host and create it there, or (2) default or fall back to the pooled SR on which the main vDisk resides? I just want to know if a VM is started on a different XenServer in the pool, where does the diff disk get re-created under these circumstances?
[Mark Syms] If the VM crashes it won't restart on a different host, it can only ever start on the host that has the local SR that its temporary cache disk is located on.
With regard to
"One big issue still unresolved is that While XenServer has supported storage Xenmotion for some time, this is still not an option with VM storage under XenDesktop runnin gon XenServer. It would be really nice to be able to re-balance the storage load and not be stuck having to reprovision to get a VM's storage to be relocated to a different SR."
This again is a XenDesktop problem to solve as it needs to be contextually aware of the location of all the disks and deltas for the machines in the catalog. Moving disks using Storage Motion (on any hypervisor) will lead to XenDesktop having major confusion about the location of disks. There are a number of items about this in the XenDesktop requirements backlog.
I understand this is the current situation. What I'm asking is why in the world would you support storage Xenmotion for years under XenServer and yet not allow XenDesktops to leverage this? All that information is in a DB for XenDesktop; it has to be put there when the VM is provisioned in the first place. It would appear you are you saying that XenServer is not XenDesktop aware. That being the case, are there any plans to change this or is this not something you see asked about much?
[Mark Syms] No, I'm saying that XenServer can't in the case of doing storage migration go and update the XenDesktop database (especially as there may in a worst case scenario be multiple XenDesktop sites utilising a single XenServer pool and the VM migrated may not be a XenDesktop machine). The migration process has to be driven from the XenDesktop side and that functionality doesn't yet exist.

[Germano Percossi]

Hi Tobias,

Post by Tobias Kreidl
Also, note that if IntelliCache is used, the upgrade to XS 7.0 if going
to the new disk layout will totally wipe out any local SRs, and so any
and all will need to be re-created, including the IntelliCache ext3
ones. In any case, is it safe to assume the necessary storage will be
re-created as needed, but if originally specified to be on local
storage, will it be attempted to redo the layout the way it was
originally specified?

Upgrades are safe (if you do use XC or follow the instructions for CLI),
especially for what concerns the local SR:

- If the local SR contains VDIs, the new dom0 disk layout
is not used and the old one is kept
- The vhdcache files, I am pretty sure, are not counted as
VDIs (they are not), so if they are the only one in the
local SR, it is likely it is considered empty and the
new layout gets implemented.
- The vhdcache files, in that case, will be automatically
recreated when you restart your VMs.
- If you do want to preserve those caches (for some reason),
I advice to create any VDI in the local SR before the upgrade.
- The only problem would be if during the layout change, your
local SR would be converted back to an lvm one but this is
NOT the case.

Hope it helps,
Germano

[Zheng Li]

Do you use XenCenter or CLI? When you say some VM can not be copied, what actually happens when you tried to?

For any VM that you couldn't do the copy, could you start the VM then try to storage migration it to your destination pool? If that works, I can't see why the copy wouldn't. Effectively the copy is just a special mode ("copy" mode) of storage migration, which will leave the original VM untouched and change a few things on destination VM to distinguish it from the source VM. They share the same "assert-can-migrate" judgement.

Cheers,
Zheng

Post by Iñigo Martinez Lasala
Hi everybody.
Does anybody know what criteria must accomplish a VM for be copied between pools (with the VM shutdown)?
We have been working with several Xenserver 6.5 and 7.0 pools and we have not found when we can use this feature. We have checked if there are snapshots, if there are vGPU assigned, different OS (Windows 2008, 2012, Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver versions, but the true is that some of then can be copied and some not without identifying any common pattern.
Thanks in advance.

[Iñigo Martinez Lasala]

Hi Zheng.

The problem is only from Xencenter. Via xe cli I can copy VM without any
problem. Once I've tried to copy it via cli, I can copy via xencenter
again. It's like some kind of "lock" has been removed.

This behavior is not general. Only some VMs cannot be copied from
Xencenter. And it does not depend of operating system (some are Linux
Ubuntu 14.04, other Windows 2012 R2), virtualization type (some are PVHVM,
other PVM), BIOS strings (some have BIOS strings copied, some not) or PCI
Passthrough (some have GPU attached, some not). It's quite strange.

Anyway, it's not a big problem for me but some developers do not feel
confident with xe cli.

Post by Zheng Li
Do you use XenCenter or CLI? When you say some VM can not be copied, what
actually happens when you tried to?
For any VM that you couldn't do the copy, could you start the VM then try
to storage migration it to your destination pool? If that works, I can't
see why the copy wouldn't. Effectively the copy is just a special mode
("copy" mode) of storage migration, which will leave the original VM
untouched and change a few things on destination VM to distinguish it from
the source VM. They share the same "assert-can-migrate" judgement.
Cheers,
Zheng

Post by Iñigo Martinez Lasala
Hi everybody.
Does anybody know what criteria must accomplish a VM for be copied
between pools (with the VM shutdown)?
We have been working with several Xenserver 6.5 and 7.0 pools and we have
not found when we can use this feature. We have checked if there are
snapshots, if there are vGPU assigned, different OS (Windows 2008, 2012,
Ubuntu), type of virtualization (HVM, PV or PVHVM), Xenserver versions, but
the true is that some of then can be copied and some not without
identifying any common pattern.
Thanks in advance.