Posts made by RicknTX1

@julien-f Ahh.. perfect!

This a huge help until the other matter can be dealt with. I see it now and the testing is successful with this change.

Thank you again to you and the team!

@julien-f Hello.. I went ahead and did a pull/build this morning using the from sources steps I usually apply from the documentation.

I'm showing XO commit b8919 and upon testing, it doesn't appear to be providing results if I simply type in the host name in there or partial hostname. I gave the XO a reboot for good measure as well.

Any other tests I can run here or way possible to be sure I have the latest update with the adjustment in there? Maybe I missed a step?

Amazing work!

All of my guest machines are local, no shared SRs for now in the lab. This should get things back on track again!

Do I just need to do another git checkout/git pull --ff-only as noted in the "From the sources" section of the documentation to get the change and build it in?

Thanks again for doing this!! I've all but gone completely away from xcp-center with the amazing work in xo and xolite that has been done. I know that's the goal anyhow!

@julien-f Ahh ok.. Good to know!

Right now, in the given state I haven't found means to getting a list of active running and non-running machines for a given host.

Using the Home / VM List and selecting Hosts under filters, then grabbing the host in there only shows actively running machines. If I've just powered up the hosts and want to quickly filter all machines as I did in the past under the bug, I cannot.

Right now... The only way to get a list of everything is to remove power_state:running, but that gets ugly quickly as it shows literally every machine and you have to find/seek manually down the list to take action on those guests.

Beyond that, I'm having to switch over to the host and pull up XOLite which gives me a bit quicker of a chance to see the machines and power them up before going back to XO.

Thank you for getting back to me on this.. it was definitely a nice feature (cough cough bug) that worked well. We'll see what's to come in the features of the future

Typing in the friendly name of the host returns zero results...

Selecting Host and finding it will show only running devices for that Host:

Easy steps to reproduce things:

Click "Home"
Make sure view is "VM"
In Filters, clear out "power_state:running" and replace with the name of one of your hosts or a partial name (e.g. host is xcp-ng-004 - key in xcp-ng-004 or ng-004).
The results will come up empty or with odd results not related to the search intended.

Workaround for now:
Click "Home"
Make sure view is "VM"
In Filters, select "Hosts" and find your Host to get the filtered listing.
NOTE... this will only show power_state:running since that is in there actively, to get all you have to clear out that from the Filters box.

@olivierlambert Hello... Sure.. Do you need a screenshot example or something specific? Happy to help in anyway I can here for you...

Hello....

I'm running the from sources build (latest) of XO in my lab. Over the past few months releases, I've noticed that the filter feature I used to have is no longer working like it has in the past.

For example.. Whenever I used to want to bring up all of the guests on a specific host (running or not) .. I used to click on "Home" and in the "VM" view... then in the filter at the top of the screen. In the search, I'd put something like the full name or partial name of the host (e.g. xcp-ng-004 or perhaps ng-004) and it would instantly show a list of guest machines that XO located. This was handy whenever I wanted to quickly get a list of guests on a host that I might have just powered back on. I could then go down the list and select to power them up.

A few months ago, I noticed that it won't do that anymore and shows completely random results of what I actually wanted.

Does anyone know if there was some code change possibly that might have broken this ability possibly? It was a quick and easy way to list all of the guests on a host or get to a specific group of guests in short order.

It appears that the search is only targeting perhaps the guest name and description fields where before it would also search the host column as well in this view.

Thanks for an amazing product and all of the great work here!

Thanks Dan..

I went ahead and bumped it up from 2GB to 4GB.

I was poking around trying to find that on the website, but figured I'd give that a go.

Looks like that was the key.

Hi!

Thanks for the updates this morning! I went into my XO from sources build and first updated node from vers 8 to vers 12 using the link from the docs page on XO.

I was able to perform the git command, then the yarn command successfully. Whenever I attempt to run the yard build though, it is failing out during that process with a fatal error:

[14:46:13] Finished 'copyAssets' after 14 s
[14:46:20] Finished 'buildStyles' after 20 s

<--- Last few GCs --->

[3494:0x38b2480]   235157 ms: Mark-sweep 976.8 (1017.0) -> 976.3 (1020.8) MB, 2161.1 / 0.1 ms  (average mu = 0.070, current mu = 0.000) allocation failure GC in old space requested
[3494:0x38b2480]   237282 ms: Mark-sweep 976.3 (1020.8) -> 976.2 (1006.0) MB, 2124.4 / 0.1 ms  (average mu = 0.036, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x13cf019]
Security context: 0x0085cbb408d1 <JSObject>
    1: _parseMappings(aka SourceMapConsumer_parseMappings) [0x8c8e17b73b9] [/opt/xen-orchestra/node_modules/vinyl-sourcemaps-apply/node_modules/source-map/lib/source-map-consumer.js:~423] [pc=0x1ff8fbd63088](this=0x2b25b7f80119 <BasicSourceMapConsumer map = 0x121ba3f798c9>,0x13d463300119 <Very long string[4787562]>,0x3d5d577401b9 <null>)
    2: get [0x33654250bc5...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xa093f0 node::Abort() [gulp build]
 2: 0xa097fc node::OnFatalError(char const*, char const*) [gulp build]
 3: 0xb842ae v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [gulp build]
 4: 0xb84629 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [gulp build]
 5: 0xd30fe5  [gulp build]
 6: 0xd31676 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [gulp build]
 7: 0xd3def5 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [gulp build]
 8: 0xd3eda5 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [gulp build]
 9: 0xd40539 v8::internal::Heap::CollectAllAvailableGarbage(v8::internal::GarbageCollectionReason) [gulp build]
10: 0xd418b6 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [gulp build]
11: 0xd0867d v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::RootIndex, int, v8::internal::Object, v8::internal::AllocationType) [gulp build]
12: 0xd08770 v8::internal::Handle<v8::internal::FixedArray> v8::internal::Factory::NewFixedArrayWithMap<v8::internal::FixedArray>(v8::internal::RootIndex, int, v8::internal::AllocationType) [gulp build]
13: 0xf26b99 v8::internal::HashTable<v8::internal::NameDictionary, v8::internal::NameDictionaryShape>::New(v8::internal::Isolate*, int, v8::internal::AllocationType, v8::internal::MinimumCapacity) [gulp build]
14: 0xf2f11e v8::internal::Dictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape>::Add(v8::internal::Isolate*, v8::internal::Handle<v8::internal::NameDictionary>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyDetails, int*) [gulp build]
15: 0xf2f289 v8::internal::BaseNameDictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape>::AddNoUpdateNextEnumerationIndex(v8::internal::Isolate*, v8::internal::Handle<v8::internal::NameDictionary>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyDetails, int*) [gulp build]
16: 0xf317a3 v8::internal::BaseNameDictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape>::Add(v8::internal::Isolate*, v8::internal::Handle<v8::internal::NameDictionary>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyDetails, int*) [gulp build]
17: 0x1060a6c v8::internal::Runtime_AddDictionaryProperty(int, unsigned long*, v8::internal::Isolate*) [gulp build]
18: 0x13cf019  [gulp build]
Aborted
* xo-web:build − Error: 134
✖ 1
error Command failed with exit code 1.

I've tried removing the node_modules folder and re-running through the process, but it seems to keep failing at the same point.

Any ideas on why this is failing on me? I've been running XO on this Debian box for quite some time from sources. I usually just have to run through the git and then two yarn processes.

Thank you again!
+Rick