Thanks Michael,
I've added a system filesystem to our SCSSnebula cluster and that
seems to fix things. I wasn't at all obvious that this would be an issue
in the upgrade.
Regards,
Gerry
On 07/01/2014 23:54, Michael wrote:
My setup looks pretty similar to yours as I'm using ceph to store my
data so it all just gets lumped together ;)
Modifying the DB sounds a bit risky... you'd be looking to change
<CLUSTER_ID>-1</CLUSTER_ID> to <CLUSTER_ID>100</CLUSTER_ID> for `oid`
0 in the table `datastore_pool`. It might work fine but I've no way to
test that! If you're comfortable with SQLite then it'd be a cleaner
solution (Which is why I use MySQL instead, bit less of a headache if
you need to faff with it).
You shouldn't need to remove or even touch the 0 datastore. You'll
just be adding another one so new VM's have a place to start up with
the /correct /setup (You can give it a different name, it's just the
type 'system' it's after). Over time your configs/data will get moved
as you recreate the VM's.
-Michael
On 07/01/2014 23:32, Gerry O'Brien wrote:
Hi Michael,
Wow! this seems like it might be at the heart of the issue. Even if
I can work around this and add a non-0 system datastore to my
existing cluster, what happen to VMs that are already running in
datastore 0?
Would it be possible to modify that one.db database to make
datastore 0 part of the SCSSnebula cluster?
As an aside, the reason why all the datastores are in the same
filesystem is my belief/hope that instantiating non-persistent VM
would be more efficiet if the copy was contained within a file system
rather than across filesystems.
Gerry
On 07/01/2014 23:21, Michael wrote:
Hi Gerry,
onedatastore list
ID NAME SIZE AVAIL CLUSTER IMAGES TYPE
DS TM
0 system 21.4T 98% - 0 sys
- shared
1 default 21.4T 98% SCSSnebula 43 img
fs shared
2 files 21.4T 98% SCSSnebula 0 fil
fs ssh
100 Research 21.4T 98% SCSSnebula 0 img
fs shared
101 Teaching 21.4T 98% SCSSnebula 6 img
fs shared
SCHED_MESSAGE="Tue Jan 7 18:58:59 2014 : No system datastore meets
SCHED_DS_REQUIREMENTS: CLUSTER_ID = 100 & !(PUBLIC_CLOUD = YES)"
So there's no system datastore in the cluster as you spotted, I
think this is a new requirement in 4.4 with the change to multiple
system datastores and tiering. There might be an issue with some
configurations after upgrading.
I don't think you can add the 0 datastore to your cluster so as
you're already using a shared datastore which is the same for all
your data you can probably just make a second non id 0 system
datastore linked to the same place as the others and assign it to
the cluster.
-Michael
_______________________________________________
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
--
Gerry O'Brien
Systems Manager
School of Computer Science and Statistics
Trinity College Dublin
Dublin 2
IRELAND
00 353 1 896 1341
_______________________________________________
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
