Перезапуск VM из другого файла VHD (но копия старой)
AOT только устраняет необходимость (большинства) компиляция JIT. Вам все еще нужен VM для всех других услуг, которые он предоставляет - сборка "мусора", метаданные, IO, безопасность, динамическая компиляция, и т.д.
Преимущество AOT в настольной среде состоит в том, чтобы уменьшить время запуска, позволить более дорогой оптимизации компилятора использоваться и позволить совместное использование кода между приложениями.
IPhone является особым случаем, так как он запрещает и динамические библиотеки и JITing. Таким образом, код CLI AOT-компилируется в статические библиотеки, которые затем связаны вместе с сокращенным Моно временем выполнения, произведя единственный двоичный файл. Однако отключение JIT добавляет некоторые ограничения. Например, определенное использование дженериков невозможно (компилятор AOT не может всегда статически определять, который овеществил универсальные типы, которые он должен скомпилировать), и динамическая генерация кода (необходимый языкам как IronPython) невозможна.
Ваш лучший выбор состоял бы в том, чтобы создать Параллельную Моно Среду - или создать его непосредственно на удаленной машине, или создать его локально, установка в некоторый временный префикс, tar это и скопировать его.
First of all, some basic concepts about Windows machines/domains you need to know (and may or may not already know):
Computers are security principals just like users
Names are just human-friendly references to an underlying SID
Computers authenticate to the domain on startup
Computers accounts have password too (that change every 30 days by default)
Basically, what happened when you jammed the old VHD in your machine is (I'm betting), the local password for the computer account failed to match the password the DC had for the computer account, because the password got changed sometime between the backup you did and the time you restored it. As a result, the Domain Controller wouldn't let the computer authenticate, and the error you see is a failed trust relationship.
This relies on an assumption or two, most notably that your backup and the machine that failed didn't have different SIDs, which will also break the domain trust. That commonly happens when you rename a computer or join a computer to a domain with the same name as an existing account. The newly renamed computer will try to authenticate with its new SID, but the name maps to the old SID, so when AD checks, the SIDs don't match and the authentication fails.
So either way, you basically broke authentication between your VM and the domain when you "restored" the old backup. I trust you can see why that's bad. (It's less bad if it was just the machine password, and not a different SID, which is worth mentioning.)
Why it's "bad practice" to do as you did is subjective and will get different answers (or different specific concerns) from different admins, but my answer would basically be that it's bad practice because there's a better way to do it that doesn't break domain authentication or add complexity and unknowns into the mix. (How old was the backup? What changed on the system between then and now? What's relying on those changes that could break or cause monstrously difficult to troubleshoot issues? etc.) It's also bad practice because it sounds like you don't have actual, effective backups, or a quick process to restore from [a real] backup if/when needed. That's very bad, for reasons I hope you don't need clarification on.
Having said all that, it sounds like you're relatively safe. (Assuming, of course, the old backup isn't missing a bunch of SQL data, or has an older version of something installed, or anything basic like that.) The different computer account password won't be referenced anywhere, and generally your computer's full SID isn't going be referenced by much outside of AD either, so changing it shouldn't cause problems. (But like any admin who's been around the block once or twice, I've seen stuff that would make your blood curdle and results in my qualifying what would otherwise be absolute statements.)
Hope that's helpful.
Domain members sync domain membership credentials periodically. When a system is offline for an extended period the domain no longer recognizes the systems credentials. As long as you don't rename the system you can rejoin the domain without issue note you can also try NLTEST /SC_RESET:domain_name\DC_name rather than rejoin the domain
Проблема в том, что это делается с контроллером домена. Он имеет базу данных с уникальными номерами, которые используются совместно и синхронизируются с другими контроллерами домена. Внезапное возвращение одного из них к старым несинхронизированным номерам - плохая идея.
Изменить: Может быть, я был немного краток. Позвольте мне добавить еще три вещи:
- Поскольку единственный случай, в котором вы могли бы восстановить контроллер домена из резервной копии , - это когда все контроллеры домена были утеряны, принудительное восстановление не требуется. Источник: Microsoft technet .
- База данных часто имеет особые потребности. Если это широко используемая БД, то вам нужно настроить на нее весь сервер. Это включает ЦП, ОЗУ (размер ОЗУ по сравнению с активно используемым набором данных) и диски. (См. SF. Какие существуют различные широко используемые уровни RAID и когда я должен их рассматривать? "> Канонический ответ по RAID для последней части. Кажется, в последнее время я довольно часто ссылаюсь на это).
- Контроллер домена не работает. нужно много, но вы хотите, чтобы это происходило быстро. Самый медленный новый сервер, который вы можете купить, подойдет, но попробуйте запустить его как единственную задачу на сервере. Даже если для этого нужно купить новый сервер. Другие серверы могут перезагрузиться или выйти из строя, но в сети ms вам нужен хотя бы один DC, у которого есть ресурсы для быстрого ответа.