Major Description
I understand that this is something that can be done in the CLI using the XAPI/XE commands, however my team and I do not see this as an acceptable answer. By having a XenCenter be a GUI layer to the Xapi, the absence of support for features that the API permits is certainly a bug, despite what Citrix support continues to tell us. I've pasted below excerpts from our most recent ticket.
US:
According to your white papers and documentation, Xenserver 6.5.0 allows up to 16 Virtual DIsks per VM assuming the OS can allocate this many. http://docs.citrix.com/content/dam/en-us/xenserver/xenserver-65/XenServer-6.5.0-Configuration_Limits.pdf
We are running CentOS VMs so the theoretical limit is well above 16 disks. The issue is that this is extremely false since we are maxing out at 6 disks. I can set a screenshot if required.
CS (Citrix Support):
It's not a bug. it's by design.
Its a configuration limit.
US:
I don't understand how that would be a configuration limit if the option is allowed via cmd line. Is there a way to bump the configuration limit?
CS:
No Ryan. No command to increase this limit.
US:
I think his question is why is this a configuration limit in the the XenCenter UI but not in the CLI?
I have always wondered this for adding memory as well. If I want to add more the 16GB of RAM i need to use the CLI... Seems like a bug to me.
CS:
Form VM user guide :
For Storage XenMotion, VMs with more than six attached VDIs cannot be migrated.
Refer : https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-vm-users-guide.pdf (page 25)
US:
Hi,
I guess we're really just wondering why these things are the way they are. If we can perform these actions with the CLI, why is it not possible to perform them in the GUI (XenCenter), especially considering XenCenter is simply a layer on top of the xapi/xe toolstack. It seems like these decisions have been made to not support these actions in the GUI because it causes other issues, such as not being able to use Storage XenMotion--but it's concerning to wonder why, for example, Storage XenMotion cannot be carried out with more than six VDIs.
Both of these issues, both the max VDIs and max Memory allocation, appear to us to be the result of underlying bugs in the XenServer platform, which you can get around by performing CLI actions. However for more advanced users, would it not be more prudent to allow XenCenter to perform these actions, even if you show the user a warning before they perform them? For example, when adding more than six VDIs to a VM, you could display a warning that you won't be able to use Storage XenMotion on the VM since it has more than 6 disks.
More importantly: why are we unable to use Storage XenMotion on VMs with more than 6 VDIs? Is this because of a bug, or because the developers of XenMotion decided 6 was the limit? Regardless of being told we can perform these "advanced" actions in the CLI, the lack of support for them in XenCenter is most certainly a bug. If XenCenter is to be an implementation of the Xen API/XE Toolstack, then the absence of support for things that the API can do is most certainly a bug, and should be classified as such.
Can we open a bug report for these issues?
CS:
The reason these operations are not allowed from XenCenter are because it's not a supported configuration. Yes the customers can attach more disks via CLI but that would end up being on unsupported configuration.
Yes the Storage XenMotion has a limitation of 6 VDIs which has always been the case with XenServer product.
Every software/feature comes with limitations and they have been documented in the edocs.I would not consider this a bug as the XenCenter was designed keeping in mind only the supported operations.