| 2018-12-11 13:27:55 |
Calvin Hartwell |
bug |
|
|
added bug |
| 2018-12-11 13:28:54 |
Calvin Hartwell |
description |
Hey all,
When Juju deploys virtual machines on vSphere, it does not provide any way to select the datastore which should be used to provide storage for the virtual machines. By default, it attempts to use the datastore which is available on the ESX hypervisor it is using to run the VM(s).
There are two problems with this approach:
1) Customers generally don't want the VM disks to sit on the local datastore, as this is usually a small disk used for snapshots, ISO images and other misc files.
2) If the VM disks being provisioned are too large, I.E bigger than those provided by the local datastore, it will not work because thin provisioning is not used by default (https://bugs.launchpad.net/juju/+bug/1807957) and the disks are always thick provisioned.
So, we need a way of specifying which datastore should be used when provisioning new VM(s) on vSphere. Usually each hypervisor is exposed or has connectivity to several different datastores.
Cheers,
- Calvin
Related issue with the vSphere provider: https://bugs.launchpad.net/juju/+bug/1807953
Related issue with lack of thin provisioning: https://bugs.launchpad.net/juju/+bug/1807957 |
Hey all,
When Juju deploys virtual machines on vSphere, it does not provide any way to select the datastore which should be used to provide storage for the virtual machines. By default, it attempts to use the datastore which is available on the ESX hypervisor it is using to run the VM(s).
There are two problems with this approach:
1) Customers generally don't want the VM disks to sit on the local datastore, as this is usually a small disk used for snapshots, ISO images and other misc files.
2) If the VM disks being provisioned are too large, I.E bigger than those provided by the local datastore, it will not work because thin provisioning is not used by default (https://bugs.launchpad.net/juju/+bug/1807957) and the disks are always thick provisioned.
So, we need a way of specifying which datastore should be used when provisioning new VM(s) on vSphere. Usually each hypervisor is exposed or has connectivity to several different datastores.
vSphere versions used were: 6.5 and 6.7.
Cheers,
- Calvin
Related issue with the vSphere provider: https://bugs.launchpad.net/juju/+bug/1807953
Related issue with lack of thin provisioning: https://bugs.launchpad.net/juju/+bug/1807957 |
|
| 2018-12-11 13:33:18 |
Calvin Hartwell |
bug |
|
|
added subscriber Michael Iatrou |
| 2018-12-11 13:38:50 |
Calvin Hartwell |
description |
Hey all,
When Juju deploys virtual machines on vSphere, it does not provide any way to select the datastore which should be used to provide storage for the virtual machines. By default, it attempts to use the datastore which is available on the ESX hypervisor it is using to run the VM(s).
There are two problems with this approach:
1) Customers generally don't want the VM disks to sit on the local datastore, as this is usually a small disk used for snapshots, ISO images and other misc files.
2) If the VM disks being provisioned are too large, I.E bigger than those provided by the local datastore, it will not work because thin provisioning is not used by default (https://bugs.launchpad.net/juju/+bug/1807957) and the disks are always thick provisioned.
So, we need a way of specifying which datastore should be used when provisioning new VM(s) on vSphere. Usually each hypervisor is exposed or has connectivity to several different datastores.
vSphere versions used were: 6.5 and 6.7.
Cheers,
- Calvin
Related issue with the vSphere provider: https://bugs.launchpad.net/juju/+bug/1807953
Related issue with lack of thin provisioning: https://bugs.launchpad.net/juju/+bug/1807957 |
Hey all,
When Juju deploys virtual machines on vSphere, it does not provide any way to select the datastore which should be used to provide storage for the virtual machines. By default, it attempts to use the datastore which is available on the ESX hypervisor it is using to run the VM(s).
There are two problems with this approach:
1) Customers generally don't want the VM disks to sit on the local datastore, as this is usually a small disk used for snapshots, ISO images and other misc files.
2) If the VM disks being provisioned are too large, I.E bigger than those provided by the local datastore, it will not work because thin provisioning is not used by default (https://bugs.launchpad.net/juju/+bug/1807957) and the disks are always thick provisioned.
So, we need a way of specifying which datastore should be used when provisioning new VM(s) on vSphere. Usually each hypervisor is exposed or has connectivity to several different datastores.
You will end up hitting out-of-space errors like this one: https://gist.githubusercontent.com/CalvinHartwell/1c19f2956629cbb68840731ccce8bb5c/raw/797ff5f890b0c2cea4d8a3e6cb5a0a435b100292/vmware-out-of-space.log
Machine State DNS Inst id Series AZ Message
0 pending juju-fcc43f-0 bionic poweredOn
1 pending juju-fcc43f-1 bionic poweredOn
2 pending juju-fcc43f-2 bionic poweredOn
3 pending juju-fcc43f-3 bionic poweredOn
3/lxd/0 pending pending bionic
4 down pending bionic Insufficient disk space on datastore ''.
5 down pending bionic Insufficient disk space on datastore ''.
6 down pending bionic Insufficient disk space on datastore ''.
7 down pending bionic Insufficient disk space on datastore ''.
8 down pending bionic Insufficient disk space on datastore ''.
9 pending juju-fcc43f-9 bionic poweredOn
10 down pending bionic Insufficient disk space on datastore ''.
11 down pending bionic Insufficient disk space on datastore ''.
vSphere versions used were: 6.5 and 6.7.
Cheers,
- Calvin
Related issue with the vSphere provider: https://bugs.launchpad.net/juju/+bug/1807953
Related issue with lack of thin provisioning: https://bugs.launchpad.net/juju/+bug/1807957 |
|
| 2018-12-11 13:40:02 |
Calvin Hartwell |
description |
Hey all,
When Juju deploys virtual machines on vSphere, it does not provide any way to select the datastore which should be used to provide storage for the virtual machines. By default, it attempts to use the datastore which is available on the ESX hypervisor it is using to run the VM(s).
There are two problems with this approach:
1) Customers generally don't want the VM disks to sit on the local datastore, as this is usually a small disk used for snapshots, ISO images and other misc files.
2) If the VM disks being provisioned are too large, I.E bigger than those provided by the local datastore, it will not work because thin provisioning is not used by default (https://bugs.launchpad.net/juju/+bug/1807957) and the disks are always thick provisioned.
So, we need a way of specifying which datastore should be used when provisioning new VM(s) on vSphere. Usually each hypervisor is exposed or has connectivity to several different datastores.
You will end up hitting out-of-space errors like this one: https://gist.githubusercontent.com/CalvinHartwell/1c19f2956629cbb68840731ccce8bb5c/raw/797ff5f890b0c2cea4d8a3e6cb5a0a435b100292/vmware-out-of-space.log
Machine State DNS Inst id Series AZ Message
0 pending juju-fcc43f-0 bionic poweredOn
1 pending juju-fcc43f-1 bionic poweredOn
2 pending juju-fcc43f-2 bionic poweredOn
3 pending juju-fcc43f-3 bionic poweredOn
3/lxd/0 pending pending bionic
4 down pending bionic Insufficient disk space on datastore ''.
5 down pending bionic Insufficient disk space on datastore ''.
6 down pending bionic Insufficient disk space on datastore ''.
7 down pending bionic Insufficient disk space on datastore ''.
8 down pending bionic Insufficient disk space on datastore ''.
9 pending juju-fcc43f-9 bionic poweredOn
10 down pending bionic Insufficient disk space on datastore ''.
11 down pending bionic Insufficient disk space on datastore ''.
vSphere versions used were: 6.5 and 6.7.
Cheers,
- Calvin
Related issue with the vSphere provider: https://bugs.launchpad.net/juju/+bug/1807953
Related issue with lack of thin provisioning: https://bugs.launchpad.net/juju/+bug/1807957 |
Hey all,
When Juju deploys virtual machines on vSphere, it does not provide any way to select the datastore which should be used to provide storage for the virtual machines. By default, it attempts to use the datastore which is available on the ESX hypervisor it is using to run the VM(s).
There are two problems with this approach:
1) Customers generally don't want the VM disks to sit on the local datastore, as this is usually a small disk used for snapshots, ISO images and other misc files.
2) If the VM disks being provisioned are too large, I.E bigger than those provided by the local datastore, it will not work because thin provisioning is not used by default (https://bugs.launchpad.net/juju/+bug/1807957) and the disks are always thick provisioned.
So, we need a way of specifying which datastore should be used when provisioning new VM(s) on vSphere. Usually each hypervisor is exposed or has connectivity to several different datastores.
You will end up hitting out-of-space errors like this one: https://gist.githubusercontent.com/CalvinHartwell/1c19f2956629cbb68840731ccce8bb5c/raw/797ff5f890b0c2cea4d8a3e6cb5a0a435b100292/vmware-out-of-space.log
Machine State DNS Inst id Series AZ Message
0 pending juju-fcc43f-0 bionic poweredOn
1 pending juju-fcc43f-1 bionic poweredOn
2 pending juju-fcc43f-2 bionic poweredOn
3 pending juju-fcc43f-3 bionic poweredOn
3/lxd/0 pending pending bionic
4 down pending bionic Insufficient disk space on datastore ''.
5 down pending bionic Insufficient disk space on datastore ''.
6 down pending bionic Insufficient disk space on datastore ''.
7 down pending bionic Insufficient disk space on datastore ''.
8 down pending bionic Insufficient disk space on datastore ''.
9 pending juju-fcc43f-9 bionic poweredOn
10 down pending bionic Insufficient disk space on datastore ''.
11 down pending bionic Insufficient disk space on datastore ''.
vSphere versions used were: 6.5 and 6.7.
Cheers,
- Calvin
Related issue with the vSphere provider: https://bugs.launchpad.net/juju/+bug/1807953
Related issue with lack of thin provisioning: https://bugs.launchpad.net/juju/+bug/1807957 |
|
| 2019-01-14 12:39:50 |
Richard Harding |
juju: status |
New |
Triaged |
|
| 2019-01-14 12:39:57 |
Richard Harding |
juju: importance |
Undecided |
High |
|
| 2019-01-14 12:40:01 |
Richard Harding |
juju: milestone |
|
2.5.1 |
|
| 2019-01-28 22:08:06 |
Ian Booth |
juju: milestone |
2.5.1 |
2.5.2 |
|
| 2019-03-11 23:01:50 |
Canonical Juju QA Bot |
juju: milestone |
2.5.2 |
2.5.3 |
|
| 2019-03-26 02:09:10 |
Canonical Juju QA Bot |
juju: milestone |
2.5.3 |
2.5.4 |
|
| 2019-04-01 08:53:42 |
Christian Muirhead |
juju: status |
Triaged |
In Progress |
|
| 2019-04-01 08:53:45 |
Christian Muirhead |
juju: assignee |
|
Christian Muirhead (2-xtian) |
|
| 2019-04-02 01:46:33 |
Canonical Juju QA Bot |
juju: milestone |
2.5.4 |
2.5.5 |
|
| 2019-04-04 02:42:28 |
Christian Muirhead |
juju: status |
In Progress |
Fix Committed |
|
| 2019-05-09 14:04:04 |
Simon Richardson |
juju: status |
Fix Committed |
Fix Released |
|
| 2019-05-14 06:06:25 |
Anastasia |
juju: milestone |
2.5.6 |
2.5.7 |
|
