(February 2020 onwards) WMT Pi VMs

[TerryJC]

As far as I'm concerned, I think it's fine for the NAS box to be an exception in the VM set-up, because it's not a Pi and doesn't run the same software. We can't really use the same base image for the NAS as we do for the Pis, because they have different sized disks (20GB vs 8GB) with different partitions on them (the Pis use a swap file instead of a swap partition). There's little benefit in trying to make two VMs share a base image if their partitions and basic OS installation are not identical.

A good point which I'd missed,

I'd like to put something in the Installation Spec about creating the image from scratch, simply for consistency with the other images. I will put in a simple instruction to create the image as per any other VM (Windows, Ubuntu, etc) together with your instructions about the options for the virtual disk image.

I will then include instructions to ensure that the packages that Hamish listed here viewtopic.php?p=2233#p2233 are installed (not necessarily at those versions).

(I note that he hasn't included Apache, which isn't really needed for the VM because the SQL commands are written directly by the Python module. However, there may be some packages that might not be included in the standard install of Debian but are in the NAS Box base code. However, I'm assuming that as long as the VM has the right IP Addresss and the database has the correct schema set up, then it should work OK.)

Regarding my instructions, I've just thought of some details which I didn't explicitly put in, but which are not necessarily obvious:

1. You should close VirtualBox completely while making manual edits to the XML virtual machine definition files. (Changing absolute file paths to relative.)
2. I did not explain why I deviated from VirtualBox's defaults when I specified paravirtualised network adaptors. This is a habit of mine when setting up VMs, because paravirtualised networking is so much more resource-efficient and performant than emulated network adaptors. In this application it probably won't make much difference, but there's no good reason not to use it here, so I enabled it as a matter of course.

I'll add this to the Spec in the right places.

I expect to have a new draft of the Installation Spec later today and will post it in the appropriate place in due course.

[PatrickW]

I've read the annexes to the spec. Here are some suggested changes. Sorry, this is quite a long post! I thought it would be best put here, since it focuses on the VMs, rather than in the installation spec thread.

Code: Select all

VBoxManage" storageattach "[GuestOsMachineName]" --storagectl "SATA" --port 1 --device 0 --nonrotational on --discard on --medium "[file.vdi]" --type hdd

There's a typo in my original text: an extra quote, near the beginning. It should read:

Code: Select all

VBoxManage storageattach "[GuestOsMachineName]" --storagectl "SATA" --port 1 --device 0 --nonrotational on --discard on --medium "[file.vdi]" --type hdd

It is suggested that anything that looked like it might be remotely relevant to Python development or which might affect the way the system behaves or operates in normal use should be installed.

I think this is probably a bit unclear, and that probably comes from how I wrote it originally. I read it as meaning that I should install all of the Python development packages from the repository, which is not what it means!

I think we're missing a statement of the intent behind the comparision. So, just after the commands for comparing the packages, I'd insert the instruction "Install and remove packages in Debian to try to minimise the differences between Debian and Raspbian lite." That way, a context is established for properly understanding the subsequent notes.

Using Section 4.4.1.1.2 of this document as a guide install any package present in Debian.

May I suggest "Install the additional Python modules needed for Software Framework. Use Section 4.4.1.1.2 of this document as a guide, but omit packages not present in Debian."

Edit /etc/fstab to add the discard option to the root filesystem, to reduce the size of the virtual disk image when files have been deleted.
Note: Trimming reduced the size of the virtual disk by about 700MB.

The 700MB reduction is not instant after adding the discard option. I think it's very important to recommend running the command "fstrim -a" on the virtual machine, which will force the process to occur straight away. Otherwise, you might be waiting a long time before any reduction in the virtual disk size occurs, or you might go on to finalise the base image without the reduction in size having occurred. Finalising the base image (i.e. making it multi-attach) before its filesystem has been trimmed would be a really bad idea because not only would the larger size of the base image be "locked in", but, when the individual Pi VMs do eventually trim their filesystems, there will end up being very large differences between the Pis and the base image, resulting in very sizeable difference images, which would completely defeat the object of using "discard" to save disk space!

Since this involves detaching and reattaching the disk image on the "base image" VM, remember to re-attach it using the VBoxManage command with the --detach=on option, as above.

There was an error in my original text. There is no "--detach=on" option; I meant "--discard on". Different word and no equals sign. Those two words sound very similar in my head!

There is a slight inconsistency within VirtualBox here; the command you run to enable this option has "--discard on", whereas the resulting XML file contains "discard=true". Hence, I referred, with intent, to both "on" and "true" in various places. (i.e. I was specifically referring to either the XML or to the VBoxManage command. It might be worth reviewing the text for this, as I suspect some of the distinction may be lost and people may wonder why it's inconsistent.

I've omitted to explain HOW to make the image multi-attach (and it is "multi-attach", not "multi-use", but for some reason my fingers keep wanting to type "use").

To configure the base disk image as multi-attach, the process is:

1. Go into VirtualBox's Virtual Media Manager, and locate the base disk image. Select it, click "Detach", click "Modify" and select "Multi-attach".
2. Re-attach it to the base image by running the VBoxManage command with the --discard on option, as above.

Having created the base image VM and configured the base disk image as multi-use, it's then possible to clone the VM. Select the option to reinitialise the MAC addresses of the nework interfaces, and create a Linked clone. This automatically almost everything needed, and preserves the discard=true configuration on the storage. However, it results in a chain of snapshots on the base image VM. These cannot be easily removed afterwards.
Note: It might be better to create a new VM without a disk, configure it as required, clone it and then attach the disks.

I would definitely change that "might be better" note into the main instruction:

• Create a new "clonable" VM with an identical configuration to the base image VM, but having no attached virtual disk.
• Clone the clonable VM as many times as necessary to create each individual Pi VM, selecting the option to renitialise the MAC addresses of the network interfaces. Since the clonable VM has no disk, it makes no difference whether you choose to create a Full or Linked clone.
• After creating the clones, attach the base image individually to each cloned VM, using VBoxManage with the appropriate VM name and "--discard=on"
• Remove the clonable VM, or keep it to hand for producing further clones.

This will produce exactly the same result without having to deal with removing unwanted snapshots.

Configure *no* swap space in the partitioner.

Is this correct for the NAS? I thought it had a swap partition, but I must admit I haven't checked, so I could be totally wrong there.

I don't think you can say that trimming will reduce the size of the NAS disk image by about 700MB, because that will depend on a lot of factors during the OS and software installation.

Packaging VMs for Distribution
The option to export a virtual appliance in .ova format exists. However, this converts all the disk images to .vmdk format, each its own copy. Multi-attach does not seem to get carried over.

Multi-attach does not get carried over. (It's a certainty.)

Nevertheless, the images are smaller than other methods. For distribution, they are compressed to about 500MB per VM, but they expand to about 1.5GB per VM. The resulting .ova file is 5.5GB and would need to be transported on a medium with a filesystem that supports files that large. (i.e. not FAT32).

This is misleading when taken out of context. It implies that exporting a virtual appliance creates the smallest possible images, which is categorically untrue!
When I said the images are smaller than other methods, I was referring to the fact that using multi-attach and discard in the original VMs results in a smaller virtual appliance than you would get if you hadn't used those features, even though the virtual appliance doesn't actually support them. It just benefits slightly from the legacy of having used them to set up the VM initially. The virtual appliance export will never produce images small enough to upload to the file server.

Another option would be to copy the machine files themselves, manually, into a compressed archive. This might not carry over to another system well; it needs to be tested.

This would now be my recommended method for packaging the VMs for distribution. It's the one I ended up using, and the one which is being assumed by the instructions in Annex C. Use the process that has been described under "Final Activities" to organise the VMs into a single directory with relative file paths in the XML, then use your preferred archiving utility to create a compressed archive of that directory. Experimentally, 7z format was found to have the best compression.

Make a snapshot of each VM without the framework. The new snapshot for the current state was added to the basic image's XML definition with an absolute reference, so this needs to be changed to relative for distribution.

Change past tense to future tense "The new snapshot for the current state will be added to the basic image's XML definition with an absolute reference"

If a graphical file manager was used to move the files, ensure that it hasn’t left ‘.desktop’ files

Another similar-sounding-word mistake I made: I these are actually ".directory" files. Dolphin uses them to store the view settings for the current folder, so if you view the directory and change the view mode away from the default, then a .directory file will appear in it. They probably won't harm anything if left in place, but I think it's messy to leave them there. Tools more sophisticated than scp can exclude them from being copied in the first place, if you specify a pattern to exclude. (e.g. I think rsync can do that)

Run:

Code: Select all

systemctl edit [email protected] and add the lines
    [Service]
    ExecStart=
ExecStart=-/sbin/agetty --autologin pi %I $TERM

This is not one command. It should be split up like this:

Run:

Code: Select all

systemctl edit [email protected]

and add the lines

Code: Select all

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin pi %I $TERM

You can change the settings on each machine to match it.

Each virtual machine, that is. (Not each host machine that runs the VMs.)

[hamishmb]

Re the NAS box VM:

This was just something I threw together - it'll need more planning and thought before I can really call it "final", so I wouldn't put too much effort into documenting it yet. It wasn't finished because at the time we hadn't decided usernames and passwords for MySQL accounts and stuff like that. I should also have put phpMyAdmin on it really.

I'll look into this when time and headspace allow and get back to you two.

[TerryJC]

OK. I was just about to implement Patrick's comments, but I'll leave the NAS Box part as pending until we know a bit more.

[hamishmb]

I'm thinking of starting documenting all the NAS box stuff soon, seeing as it's fairly finalised. Should I make a new document (do we have a template?) or add to an existing one?

[TerryJC]

I assume you are talking about a Design Spec or perhaps a Composite Document like I've recently been producing. If so, then I don't have a template as such; I usually start from a document that has already been produced and use that as a template.

Do you intend to document the software only or will there be some hardware elements too. If the former, I'd start from https://wmtprojectsforum.altervista.org ... ss_0.8.odt. If the latter, I would suggest https://wmtprojectsforum.altervista.org ... ss_0.5.odt.

I hope that helps.

[hamishmb]

I'd be documenting the setup/installation process on the NAS box, so I guess I'd maybe want to edit the installation spec instead actually? It will be mostly software and configuration (like setting IP addresses, installing the custom software tools), and then probably hardware stuff afterwards (like I guess the type of battery the RTC needs and similar).

Do you reckon it's okay if I link to the forum topic for my cross-compiling instructions, or better if I include all of that in the spec (would be many., many pages)?

[TerryJC]

I would agree that what you are describing is probably more of an Installation Spec. I've tended to stick to 'proper' documents because I'm an old-fashioned engineer, proper documents can be read easily from end to end and it's easier to intersperse diagrams, etc.

I'm always conscious that I'm not writing these documents for myself, or even for you, Penri, Ian or Patrick. They are for Volunteers who come much later when we may all have moved on and cannot answer questions. The problem with websites, as I see it, is that they aren't very linear so unless you know what you are trying to achieve it can be a very convoluted exercise trying to sort out what has to be done. Websites also disappear if the organisation hosting them goes out of business or goes moribund. We would need some kind of permanent site to mirror the pages to mitigate this.

So if it was me I would definitely produce a 'proper' document. I can probably spare the time to assist in this. If you produce and outline of what you want to include, I should be able to grab stuff from the right places and restructure it into the document. Perhaps we could split the work up between us?

Let me know what you want to do.

[hamishmb]

Good thought. We could avoid the need for it by mirroring those pages on my personal website, but then again might not be too useful if it goes down.

In that case, we could do the instructions for building the cross compiler and similar, but leave the instructions for cross compiling each program until I'm 1000% sure I won't need to build anything more - when the NAS box is ready for deployment I suppose.

Splitting it up and co-authoring sounds like a good idea, especially as you've done a lot more of this than me and have a better idea of how to do it. I'm probably going to take the rest of today off, but perhaps we could start a new thread to organise this? There are so many new threads right now

[TerryJC]

Not a problem.

I'll leave it to you to start the new Topic when you've done an outline.

I'll be starting the reassembly of the SAC after lunch, so wouldn't be ready to do this yet anyway..