kode54

Look for some CPUID related options in your BIOS? I know some Intel boards had options to limit the maximum CPUID level reported for older operating systems.

I find it strange that either your processor or your kernel don't support the debug register MSR. Are you sure you haven't turned something off in your BIOS? Adding ignore_msrs=1 was a workaround that worked for some people, but that's already in the stock /etc/modprobe.d/kvm.conf.

Limetech will still need to create the service for (1), but the user will host it themselves. Or Limetech will need to support any one of a number of possible open source generic Telegram bots, as there are probably lots of them, and they're probably not compatible with each other. Most of the time, people will acquire one or another bot, hand edit it to their needs, and employ it. So I guess you can look to one of your many community developers, maybe the LinuxServer team would be interested in creating a Telegram bot Docker container specifically for this notification system, since it will likely be some Python or TCL or Go or even PHP concoction, and won't be able to run directly on the unRAID server.

Your network sounds like it is the bottleneck, but you'll definitely get faster file transfers if you perform them on the server itself, likely using rsync. From the SSH terminal of the unRAID instance: rsync -va --progress /mnt/diskN/folder/ /mnt/diskT/folder/ Where folder names are the same, and diskN is the source and diskT is the target. Then spend some time watching crap scroll by for hours, or find something else to do. It should go as fast as the bus can transport data from one drive to another if you do it locally. If you're "moving files between shares" across the network, it's still bottlenecked by your network reading the files to the machine doing the copying, then writing them back to the server.

I didn't search anywhere. I merely saw this topic on the first page of the forum and assumed that the opening post was maintained to keep an up-to-date list of his containers. My bad. I also searched the topic for "Lounge", but found nothing. I was unaware that Sparklyballs had joined the LinuxServer.io collaborative project, or that it was a collaborative project to begin with. I also sort of expected that he would respond on IRC, but I guess he's either too busy to respond to every trigger, or doesn't even have a client monitoring them. Then again, my turnaround for responding to my nick being spoken in a given channel may range as high as half to a whole day, depending on whether I remember to scroll my channels list and check for highlight indicators on the message counts.

Run from a shell (SSH, etc): virsh undefine --nvram "name of VM"

Intel B150 supports VT-d, but with the MSI B150M Bazooka, you must enable it in the BIOS, it is disabled by default.

Regarding the key sticking with your Microsoft Account after Anniversary Update: From what I've heard, you may only have one Windows license tied to a given Microsoft account. Obviously, Microsoft does not expect people to simultaneously use the same Microsoft Account from multiple Windows machines, ever. If so, then why did they make settings synchronization a thing?

Telegram would require either: 1) User creates a bot under their own Telegram account, using a unique user name for the bot, and registers their API key with unRAID. unRAID uses bot to send notices to the user. 2) Lime Technology registers their own bot, under their own Telegram account, and generates their own API key, and runs a central bot on their own servers. Lime Technology requires unRAID users to: 2a) Verify with the official unRAID Telegram bot that they control the Telegram account they are electing as the target for the notifications. This stops maliciously or accidentally sending messages to arbitrary users without their permission. 2b) Verify with the Lime Technology bot service that they have a valid unRAID license, by the unRAID software identifying its trial or paid license serial to the service. This hopefully stops just anyone from uncovering the protocol of your server API and abusing it to flood users with notifications, or causing your bot to abuse the Telegram service. 2c) Official unRAID bot then sends them any notifications pushed with the semi-permanent session access keys granted to their unRAID instance. I kind of like the latter, since while it is more work for Lime Technology, it requires little work or setup by the users who wish to employ it, and it should scale to hundreds or even thousands of users. Technically, you could support both. The first in the interrim, the latter as a more permanent solution. Both methods would require a Telegram bot daemon, the former requires it to be run by the user, the latter requires you to run it yourselves.

This container isn't really prime for use anyway, as it generates a new random MAC address every time you launch it, and can quickly exhaust your Google account's limit for unique machines, assuming it doesn't immediately hit an address that's in use by another user.

High time you replace that dated Shout-IRC container with The Lounge? It also seems as if your Shout configuration may be using the default "Public" mode, which does not support persistent connections. Yeah, I guess it's not ready yet, since it requires configuration of the client from the command line before launching it, and also requires creating users and assigning them passwords, if persistent connection support is desired.

Which virtual CPU are you emulating? If you are using host passthrough, it should not occur.

If you originally used the machine bare metal with the same GPU, you may need to clean up devices in the device manager. Boot with your VNC so it actually gets to a working desktop. Open Device Manager. Configure it to show hidden devices. Navigate around to places like display adapters and such. Delete all of the devices which appear grayed out as "disconnected." Shut down cleanly. Now try rebooting with the GPU passed in. It should at least detect it as a basic VGA adapter and allow you to install the drivers again. Bonus points if it installs the drivers again automatically.

Zen shouldn't be a problem, when it comes out. You're talking about a really old part by technology standards. In my opinion, the last great AMD processor was the first Athlon64. Then Intel produced the Core series, starting with the Core Duo and Core Quad, and moving on to Core 2, and various generations of i3/i5/i7. All of which have had higher prices, but also higher performance per watt than AMD's competing offerings. It was a no brainer if you were building a server which would be running 24/7. With Zen coming out Soon™, the game may finally change again to favor AMD. If you can wait a few more months, to early 2017, you may change your mind on dropping AMD. I'm undecided, but I tend to go with whatever flies by my whim at the moment, and this new tech looks like it could be a game changer. Supporting everything up to AVX2, likely all models will have IOMMU, and it's possible there will be some server models with ECC UDIMM support.

This would be useful for cases where redundancy of the data is not needed, but compounding the space of multiple drives is. The suggested options would be: Data as RAID1: Wanted redundancy, although true backup is probably a way better idea. Data as RAID0: Redundancy not wanted, and all drives are 100% identical in size. Data as single: Drives are unbalanced in size, utilize all available space for data. Metadata should always be RAID1, though, so there's at least two copies of it floating around in the volumes.

You may want to request this from the Samba developers as well, since it's their software in use here. It may be a candidate for the vfs_fruit module.

Care to insert your old drive somewhere and list the output of "print" from fdisk? It sounds as if your old drive got mispartitioned or something. That, or it was just bad.

Modify the share to cache only if necessary, then activate the Mover.

Try: dosfslabel /dev/sda1 "UNRAID" Where /dev/sda is the USB drive. Make sure from your by-id links and from attempting to mount it manually first: mount /dev/sdx1 /boot

I made a mistake. Without knowing the output of: numactl -H ...You cannot know how you should arrange your pinned cores. Please post that here, if you need help. Hyper threaded CPUs will still show up as a single node, with the virtual core set listed after the main core set. Your problem likely stems from mixing cores from one CPU and the other within the same VMs. You will need to pick an even number of main and their matching virtual cores from the first NUMA node for your One virtual machine, and the same count and such from node two for your Two virtual machine. Unless, for some reason, you wish to run them both on the same CPU.

Ah, yes, the slightly larger one was extracted from a WD MyCloud that went on the fritz, and I didn't feel like having it serviced only to lose all the data I had stored on it. I have two SSDs and room for one more data drive on my current license, but may expand my license later if I ever get a machine with the capacity for a lot of drives. (I have one more Intel controller port left, and two from the added vendor my board threw in.)

I am currently running with 2x 4TB drives and 1x 640GB, my oldest surviving drive. I had a 1.5TB drive die last year. Anyway, I was wondering if I should plan ahead for future capacity and buy a 6TB or larger drive for parity. Would this make sense if I am not currently using parity and none of my drives are nearly that large? I only ask this because of the size discrepancies I've experienced with the WD Red NAS 4TB drives, having bought one, then bought another identical model almost a year later only to find that it has about 100MB less capacity.

Did you allocate the cores correctly? 0-3 + 8-11, 4-7 + 12-15. And don't forget to adjust the CPU topology: <topology sockets='1' cores='4' threads='2'/>

Those entries in the XML should be managed='yes', otherwise they will not be unbound from the host first.

It doesn't appear to have gotten the 20161012beta1 update, either, as of 10/12.