search

ISISComputingGroup / IBEX

Top level repository for IBEX stories
5 stars 2 forks source link

An instrument: Install Windows 10 [Timebox: 5 days] #5489

Closed ChrisM-S closed 3 years ago

ChrisM-S commented 4 years ago

As an instrument scientist I would like a reliable instrument computer which is no longer "out of warranty". Although there are issues with Covid working on site currently, it might be better to concentrate on getting the Windows 10 conversion of the IMAT VM done on new hardware ready for a move to the beamline as soon as possible.

Acceptance Criteria

  1. The new VM has all IBEX "personality" modules moved as is from the old VM (these would be the Settings, Var and Data areas and functions identically to the original.
  2. Any missing platform installed modules (query what this might be). are installed and can be re-installed in a later automated update.
  3. Deployment of the system with a VHD copy and automated start up is reproducible and can be automated for Windows system updates.
DominicOram commented 4 years ago

Note a list has started in https://github.com/ISISComputingGroup/IBEX/issues/5437 of what known issues there are with VHD deployment, add to that as we do this ticket

DominicOram commented 4 years ago

Could this be re-prioritised below SANS2D? @ChrisM-S & @FreddieAkeroyd?

Tom-Willemsen commented 4 years ago

Documentation for where I got to so far with this ticket: https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Creating-a-windows-10-instrument-PC-using-VHDs Known issues: https://github.com/ISISComputingGroup/IBEX/issues/5437

For IMAT (or NDXVHDTEST really) I got as far as starting up an IBEX server and client, however there are still a number of "fundamental" problems preventing the installation from being used as an instrument (most notably, lack of labview installation and no labview modules)

As agreed in sprint planning, putting this back into the bucket for now.

Tom-Willemsen commented 4 years ago

After discussion about how to move forwards with this with @ChrisM-S we have agreed the following:

ChrisM-S commented 4 years ago

Just a note to remember to ensure that the builddev VM is added to Nagios, a replica is setup, and added to updates checklist as this is not FIT managed (although it should update itself).

Tom-Willemsen commented 4 years ago

I've now run out of time on the timebox for this ticket. Where I got to:

To review this, I would suggest trying to build a new windows 10 VM by following the instructions above. You can use NDHSPARE80 as the host, and delete and re-create NDXVHDTEST1 by following the instructions above. Ensure that any technical issues you spot are noted on https://github.com/ISISComputingGroup/IBEX/issues/5437

note: a clean set of VHDs are available at \\isis\inst$\Kits$\CompGroup\tom\vhds_for_win10 (some of the ones on the VHDS area are corrupt)

Tom-Willemsen commented 4 years ago

STFC person to review

DominicOram commented 3 years ago

Apologies, lots of comments and I'm aware this ticket has dragged, feel free to skip comments that you feel are me nit picking.

note: a clean set of VHDs are available at \isis\inst$\Kits$\CompGroup\tom\vhds_for_win10 (some of the ones on the VHDS area are corrupt)

Do we have a ticket to address this corruption?

The version of IBEX in MDT claims to be 3.1.1, is this correct? Should we be updating it to the latest? Or is MDT lying about the version? Or are these old versions we should delete from this list?

In general for the build tasks it's not obvious why some are disabled and some aren't, maybe some of these should be removed (e.g. I believe the install client step is disabled as we're just mounting it now)? Or are the disabled ones related to things left on https://github.com/ISISComputingGroup/IBEX/issues/5437? I can't see the relation? It would be good if there were descriptions in at least all of the disabled tasks in the Thick Windows 10 build as to why they're disabled?

It's disconcerting that when you do the install it says you're installing on to MININT-IBEXTEST, can we fix this? Or at least add a note on the docs to say not to worry.

On the docs for building an MDT server:

Find a physical NDH machine with space to host this VM (both in terms of memory and disk space). Standard instrument machines use 14GB of memory, so you will need at least this amount free. You will also need 256GB of free hard disk space.

Do you mean for hosting the instrument? Do we even need an instrument to deploy to at this point?

Find the latest windows 10 ISO file from \\isis\inst$\mdt$\dev1\MDTDeploymentShare\Boot\LiteTouchPE_x64_Hyper-V.iso

Do you mean the latest .iso file in that folder or that particular .iso file or LiteTouchPE_x64_Hyper-V.iso (7).last.iso? That directory is a bit of a mess and it's not clear which files to use. Where do these files come from? What's the process of creating them?

Set startup memory to 14GB

Is this really required? It's not running an instrument right?

Tell Hyper-V to boot from this ISO

It wasn't immediately obvious to me how to do this.

Join the default ISIS workgroup

My default was ... not ISIS workgroup

adkwinpsetup.exe - this may not be necessary?

Based on what? Can we decide if this is necessary or at least say why we think it's not necessary

When asked which features to install remove "windows performance toolkit", "user experience virtualisation", "microsoft application virtualisation", "Media experience analyzer"

Can we instead list the ones required? I think it will be more obvious

Right click "deployment shares" -> "open" -> MDT deployment share location (found on passwords page) -> next -> finish

The deployment workbench did not have access to the share. You first need to net use it as admin, with the account on the passwords page

Set "Network (UNC) path" to the MDT deployment share location (found on passwords page). Note that this cannot be a DFS filesystem, it must point to a real server. DFS shares are not supported by MDT. Under "Rules" tab: You will need to set paths: SLShare to , SLShareDynamicLogging to \dynlogs and BackupShare to . These are directories where logs will be written during the MDT build process, so that you can debug any failures. can be found on the passwords page. Ensure user details in this file match the MDT account detailed on the passwords page Click Edit bootstrap.ini Set DeployRoot to the MDT deployment share location (found on passwords page) Ensure user details in this file match the MDT account detailed on the passwords page

All of this was already set correctly, presumably 'cos I'm using a share that's already been created? Might be worth mentioning that they may already be filled in in this case

On the docs for building a VM from MDT (still working on this):

Copy the set of IBEX VHDs

From where? \\isis\inst$\Kits$\CompGroup\ICP\VHDS?

Is <mdt deployment share location>\Boot\LiteTouchPE_x64_Hyper-V.iso the same as \\isis\inst$\mdt$\dev1\MDTDeploymentShare\Boot\LiteTouchPE_x64_Hyper-V.iso in the other page? If it is why is one private and the other not? Also, similar questions as above on where these ISOs come from, which one am I actually meant to be using?

In Hyper-V manager, add the VHDs as disks for the virtual machine

It's not immediately obvious how to do this, is it add under SCSI Controller?

Select "Build thick updated windows 10 image"

Under re-clone system

When asked for admin password, refer to passwords page and add the new password there if necessary.

I don't think this is entirely clear on which password to use from the page

We also need to create and add a data disk as well as apps/settings/var

Tom-Willemsen commented 3 years ago

note: a clean set of VHDs are available at \isis\inst$\Kits$\CompGroup\tom\vhds_for_win10 (some of the ones on the VHDS area are corrupt)

Do we have a ticket to address this corruption?

This should now be sorted as of the VHD build getting re-enabled. When I wrote the comment initially the VHD build had been disabled for a while.

On the docs for building an MDT server:

Find a physical NDH machine with space to host this VM (both in terms of memory and disk space). Standard instrument machines use 14GB of memory, so you will need at least this amount free. You will also need 256GB of free hard disk space.

Do you mean for hosting the instrument? Do we even need an instrument to deploy to at this point?

The feeling when I discussed this with @ChrisM-S was to have a standardised spec for both instrument machines and MDT build servers. However I should have been explicit on the wiki that it doesn't actually need to be this much if resources are tight. Now clarified.

Find the latest windows 10 ISO file from \\isis\inst$\mdt$\dev1\MDTDeploymentShare\Boot\LiteTouchPE_x64_Hyper-V.iso

Do you mean the latest .iso file in that folder or that particular .iso file or LiteTouchPE_x64_Hyper-V.iso (7).last.iso? That directory is a bit of a mess and it's not clear which files to use. Where do these files come from? What's the process of creating them?

These are the files that MDT creates. In this case it's a bit circular as we're creating an MDT server using MDT... I've clarified that it's "that particular" ISO rather than any of the others.

Set startup memory to 14GB

Is this really required? It's not running an instrument right?

As above, the feeling was that baseline requirements should be the same as an instrument for simplicity, but I've now clarified the docs to say that it can be less if required.

Tell Hyper-V to boot from this ISO

It wasn't immediately obvious to me how to do this.

Clarified the docs for this.

Join the default ISIS workgroup

My default was ... not ISIS workgroup

Clarified the docs for this.

adkwinpsetup.exe - this may not be necessary?

Based on what? Can we decide if this is necessary or at least say why we think it's not necessary

I'm honestly not sure. @ChrisM-S , do you know what this is needed for?

From Win 10 onwards, the ADK setup split out the WinPE tools as a separate kit the adkwinpesetup.exe is essential now.

Right click "deployment shares" -> "open" -> MDT deployment share location (found on passwords page) -> next -> finish

The deployment workbench did not have access to the share. You first need to net use it as admin, with the account on the passwords page

Added this to docs.

Set "Network (UNC) path" to the MDT deployment share location (found on passwords page). Note that this cannot be a DFS filesystem, it must point to a real server. DFS shares are not supported by MDT. Under "Rules" tab: You will need to set paths: SLShare to , SLShareDynamicLogging to \dynlogs and BackupShare to . These are directories where logs will be written during the MDT build process, so that you can debug any failures. can be found on the passwords page. Ensure user details in this file match the MDT account detailed on the passwords page Click Edit bootstrap.ini Set DeployRoot to the MDT deployment share location (found on passwords page) Ensure user details in this file match the MDT account detailed on the passwords page

All of this was already set correctly, presumably 'cos I'm using a share that's already been created? Might be worth mentioning that they may already be filled in in this case

Added note to docs saying this may not be required.

DominicOram commented 3 years ago

Given that I don't seem to be making any progress on the review of this I'm going to increase the points on it to be more realistic on what I have done. Then we can have a meeting when @ChrisM-S and @Tom-Willemsen are back on next steps, this is impeded until then.

kjwoodsISIS commented 3 years ago

Actually, this ticket has reached the end of its timebox (and beyond) and it has been reviewed. So it's done.
I agree that it has not achieved its objective. It turned out to be complex and difficult - but we anticipated that (that's why we timeboxed it in the first place). We should mark this ticket as complete and create a new one to consider our next steps.

kjwoodsISIS commented 3 years ago

5923 created. Marking this ticket as complete.