I do :) I run Jeskola Buzz in a Windows VM. At least in a macOS host, audio latency is BETTER than I remember it being on native Windows (back when I ran that).
On macOS nothing works better for vm audio than Parallels. Never experienced latency with it. However, I would never use Parallels with Vagrant. I do all my dev using VMWare.
Not who you were asking but personally I'd be apprehensive about going off the beaten path with my tools. Less community support and effective Google searches.
A few reasons: The VMWare Vagrant provider is a core provider, well maintained, and supported. The Parallels provider, by contrast, is third-party and rarely updated. Further, it does not even work unless you have a Parallels Professional subscription.
Second: Stability. This is more historical, but Parallels has a bad history of being a poor citizen, eating up CPU power for no apparent reason (even when a VM is not running). Truth be told, I have not seen this issue in the last couple of major releases, but it happened so often in the past that I used VMWare exclusively for my Windows VM because I could rely on it not to trounce my CPU. I now use Parallels again for Windows, but only for Windows.
Third: OS Support. Parallels is so tuned to specific OSes that if you try to use anything out of the ordinary, like OpenBSD, you will struggle. VMWare, by contrast, will even work with completely fringe OSes, such as Haiku (a beOS fork), which Parallels won't even boot.
Finally, image portability: I can use the same base image for development and deployment to ESX. And speaking of ESX, VMWare Fusion can connect to ESX hosts and manage / pull up a console / upload and download to data stores. On a Mac this is invaluable because the vCenter plugins just do not work right on anything but Windows. For instance, I have never managed to upload an OVA or ISO to ESX using the vSphere Web Client on a Mac. It always fails.
I really like vbox. When work forced me to have MS windows box I did 90℅ of my time in Fullscreen vb running Ubuntu. I also ran widows vbs.
Now on osx I run dev db and other server as needed. Nice to roll back to snapshot
Fits in tool box for non automated, as hoc servers. Dont have to configure anything, or write script. Just acts like buying new hardware and slipping in CD.
I really had problems going this route (Ubuntu host with Windows guest). While the guest ran in VB reasonably well, trying to snapshot a baseline image and generally use VBox differencing disks quickly ran me out of space on the host SSD.
Even with a 256GB drive and a number of tweaks like hosting the Windows pagefile and temp from a passthrough disk, disabling Windows automatic updates, and using an immutable disk containing the OS install/multi-attach for copy-on-write behavior, VBox still used a ton of space to track the differences from my baseline snapshots. Even starting the VM quickly consumed 10-20GB in the new disk image. Was hard to conclude anything other than it wasn't a viable "dual workstation" setup and I capitulated and moved to Windows 10.
Sucks, because it was really quite nice to have a unix under the hood, though WSL makes this a bit more tolerable in Win 10 AU.
A 512GB SSD is minimum for multi-VM dev. I have Ubuntu host and ran out of space after a few VM's on 256GB. I wasted a lot of time(money) trying to slim down the Windows installs, a few hours&dollars to upgrade SSD was good investment ...
It's inappropriate to target space saving when it comes virtualization, as it's not what hypervisors are designed for - if so, a hypervisor would have to interpret the underlying FS calls, and optimize them space-wise.
Besides, I think pretty much all the formats behave the same; qcow2 for example, does not optimize on the fly the writing of zeros.
All in all though, if you ultimately moved to a native Windows 10, therefore allocated X space of native disk, the space requirement is not different from having only a virtualized one with X space of virtualized disk (heck, you could even pass a partition).
Having said that, if 10-20 GB of space are taken so quickly on boot, it may be worth investigating (you could even vim the diff disk), but I find your claim somewhat misleading, as you're likely experiencing this on the first absolute boot after taking then snapshot, but not on the subsequent ones; therefore, if your system steadily takes 20+20 GB of space, that's a perfectly reasonable requirement.
Anyone have as many problems as I have with virtualbox, vagrant and Ubuntu 16.04 as a guest OS? I would expect it to be one of the most common Linux versions running in vbox now a days as it's the latest LTS.
Nonetheless, I have had all sorts of issues with trying to tie my 16.04 box to a specific private network IPs.
Something to watch out for is that vagrant does not always (most of the times really) work with the latest release of virtualbox. Try skimming through the documentation of vagrant and they'll say what versions of virtualbox they support. By using the version they say should work, I have no problems (and I'm on 16.04 as well)
Overall, I have had enough unnecessarily poor experiences with both Virtualbox and Ubuntu that I try to not use them in general, fwiw. I don't use Vagrant so I don't have recommendations for that specific case, I'm sorry.
I tried setting up with Vagrant once. Gave up since I rarely ever have to spin up new VM's enough (and my preferred distro is now Arch) to actually get with it, although I might take a second shot.
IIRC though Vagrant requires that you keep the default NAT configured which can make configuring networking on a VM client rather difficult in VBox.
I finally have it stable on VirtualBox (5.0 or 5.1.x), but now am having issues with VMware 8.5, go figure. The boxes published on Atlas are all stable and working with any recent version of VirtualBox or VMware Fusion, though: https://vagrantcloud.com/geerlingguy/boxes/ubuntu1604
Networking at first, then open VM tools integration, and now something with VMware Fusion 8.5... still trying to figure out what's going wrong this time :/
The CentOS 6 and 7 boxes I maintain have been quite stable forever; each Ubuntu release seems to carry some lurking demons that pop up in random Packer, Ubuntu, Vagrant, VirtualBox or VMware updates.
<nod> I ask because I have a bevy of 14.04LTS installs (bare metal), and have never had any issues running same in VBox. 16.x and its systemd move has left me quite uninspired, so wondered if anything was due to that.
This also ties into 'reproducible builds', even if you find nothing at all what does it mean if you compile the sources and don't end up with a binary that is identical. Oh, and do make sure to check if your compiler isn't inserting it's own backdoor.
The real problem is that security tends to wreck stuff in absolute terms (as in binary: your company lives versus your company dies) but until that happens it is seen as a cost without any benefits.
So far oracle has successfully turned into crap every single community of free software they put their hands on:
- java,
- mysql,
- openoffice.
Just because I believe in the power of communities over the power of license and I see a pattern in Oracle corporate culture inability to plays nicely with open source communities I know give up on using any free software that is related to Oracle.
I pad for the VMware plugin and the support was awful. It's supported on a best effort basis.
The horrible VMware plugin is what's making us stick to VirtualBox, even though everybody hates it (shared folders and 3D acceleration being the worst areas).
3D acceleration on VMware Workstation 12.1 is awesome (60fps inside the VM in OpenGL) and it let's me use the VM as a full desktop without even noticing I'm on a VM. Shared folders performance is also 10x better than VirtualBox.
Unfortunately, I have to use vagrant for work and that means my VMware install is dormant... and vagrant's VMware plugin license was wasted money.
> I paid for the VMware plugin and the support was awful
I paid for the plugin early on, when it was Hashicorp's first monetization effort. Having good experiences with similar projects like Sidekiq Pro, I was quite surprised when an issue I ran into was summarily dismissed. I can't imagine what it's like post-funding.
Theoretically, any network setup a virtual machine manager can do, so should a container engine. The bulk of the work setting up the network happens on the host side anyway, and Linux guests can be made to see whatever network interfaces the host/engine wants it to see.
systemd's containerization solution supports quite a few ways to construct network setups. Look for 'network' in `man systemd-nspawn`.
I can't say much about Docker's support though. Haven't used it since 0.6, and I didn't have a favourable opinion of their network management ideas back then either.
To add some technical explanation to what larrybud said: Docker containers aren't full VMs. They don't virtualize the computer hardware or the OS kernel. So when you run a bunch of Docker containers on a computer, all of those containers are still using the same underlying OS kernel. Docker really only natively runs on Linux (and BSD), and all Docker containers are running in Linux, so running a Windows VM inside a Docker container would really only be possible if you also ran something like VirtualBox inside the Docker container (and I can't really imagine that working or being a good idea).
In short: VirtualBox is still probably the best option for running those IE VMs, and for cases like this Docker is not really a replacement for or competitor with solutions like VirtualBox.
Essentially, they have a docker-API-compatible HTTP server that runs a different set of container images. Similar to how SmartOS has a docker-API-compatible HTTP server (running on top of, essentially, a Linux emulation layer).
Microsoft gave a big pile of cash to Docker to figure out how to make Windows based Docker images.
I haven't been following it closely so I don't know what's become of it since then, but if you want IE you're going to need that work.
For other browsers, the Selenium team maintains docker images containing all of the drivers and XVFB code to make them run. They even have a debug image with xvnc on it so you can spy on the browser if something is going wrong.
> Microsoft gave a big pile of cash to Docker to figure out how to make Windows based Docker images.
Actually Microsoft has been contributing quite a bit to the OCI (Open Container Initiative), as well as Docker. So they have been putting in the work. I'm not really partial to Microsoft, but they do have some good engineers that are working on free software.
My big issue with Docker on Mac is that, if I understand it correctly, I have to provision the max amount of RAM my containers will need and have that sitting, consumed, when Docker is enabled (the Linux VM is running).
At least with traditional VMs for development I can spin up a few low memory VMs (256MB, for example), using just as much RAM as needed. My understanding is that running one low memory Docker container will cause the VM to consume 4GB (or whatever my default is). On a MacBook, where RAM is at a premium, this doesn't work for me.
I imagine the native experience on Linux is much nicer.
Better shared folders and 3D acceleration would be a good start. They are completely broken and/or missing important features.
The community has no interest in maintaining VirtualBox, mostly because of Oracle. It's a dead project just like OpenOffice, OpenSolaris, etc. One day, enough customers will stop paying Oracle for it, they will look at community contributions (rare to nonexistent?) and will close the project down rationalizing it as they did all the work. The reality is, they don't know how to steer open source projects and have no desire to do that anyway (separate private bug tracker? write access to repository only to Oracle employees? harsh email replies and comments on bug reports?).
It's on life support and will stay like that for a little while. Unfortunately, it's the only hypervisor that vagrant supports decently and it works on Mac OS X, Windows and Linux (as opposed to using KVM on Linux, xhyve on OSX and Hyper-V on Windows... for someone considering building vagrant boxes).
Is there a good article that explains why is so hard to properly do 3D acceleration in a VM? And why is it so hard to do GPU passthrough? And if there's any hope this might improve significantly, let's say 70~90% of native GPU performance. I understand you need compatible hardware and NVIDIA makes it harder just to sell cards that are more expensive. Maybe you have some insight.
Off-topic: You go in one of those Linux boards and they all say it's so easy to do it. I mean, yes, I can follow instructions and make it work but it's so cumbersome for every day usage if you want to use a Windows guest. Death by a thousand paper cuts. I don't have the time or patience to use weird setups in my work desktop anymore. To think about it, I did some pretty crazy stuff a few years ago, I'm surprised I wasn't even fired back then. The Linux equivalent of betting your income on a Hackintosh.
Kinda like anything Linux related. Don't get me wrong, all my servers are using some variation of it, but when it comes to UX (I'm not talking about GUI) and desktop stuff (not only games but anything GPU related) I wish some things were more mature.
I've extensively tried and finally succesfully setup a VGA passthrough, so I'll chime in.
> why is so hard to properly do 3D acceleration in a VM?
I don't have a precisely informed answer to this, but I think it's simply because GPUs do not support/accelerate virtualization in hardware.
> And why is it so hard to do GPU passthrough?
Now the interesting bit!
The core problem is that VGA passthrough requires an extensive collaboration of software and hardware parts, I believe significantly more than CPU virtualization.
As a matter of fact, the term "GPU passthrough" is inappropriate/imprecise - you pass an entire card (hence, "VGA passthrough").
I'll enumerate a few critical examples:
- in real world, you can't reliably transfer ownership of the VGA from the driver to VFIO¹; this means that if you want a stable VGA passthrough, you need to lock it at boot time, and renounce using it on the host
- the software matured only very recently. around an year ago, QEMU had a bug which prevented Windows 7 (without a hack) to perform an installation; until Yakkety, the precompiled UEFI firmware had a bug which prevented Windows 10 to perform an installation; locking devices is something that has been introduced (I think, not sure) no early than an year ago in the kernel
- there are many tweaks on the host which can radically affect the guest performance (eg. if you don't disable nested paging on [some] AMD systems, you will get CPU speed down to 30% of native; this will destroy the GPU performance)
- nVidia blocks VGA passthrough on consumer machines (it can be worked around easily), and it blatantly lies about it
- IOMMUs associated with their support in the BIOS may be buggy
- not all the IOMMUs support the conditions required to make VGA passthrough work out of the box
- even if all the factors apply, you may still have a system which severely underperforms without any understandable reason.
There isn't a central, comprehensive, up to date, documentation, this is true.
All of this factors are not really domain of the hypervisor; of course they could be integrated, but not in a consistent, safe way.
Now the good part!
If you have a proper system (both in HW and SW), VGA passthrough rocks; I get almost native performance (I can't distinguish native from virtual), it's perfectly stable (doesn't crash and I can execute it multiple times a day), and I launch it in a single command.
As a matter of fact, I've entirely removed Windows from my disk (modern/high end motherboards support BIOS updating directly from a USB memory).
I think it's important to clarify that the problems of VGA passthrough are radically different from the ones of Hackintosh.
Mac O/S is not designed to run on hypervisors unless certain conditions are met (the absence of such conditions being defined as "Hackintosh"), and hypervisors can't officially support conditions other than those.
In other words, Hackintosh is something that is not supposed to exist.
VGA passthough on the other hand is something that is supposed to exist and work, it's just very much dependent on the hardware support, and both HW and SW just very recently matured.
What people I think get wrong is that they think VGA passthrough as a function of the software. When the HW support is not there, like in your experience, you will die of a thousand paper cuts.
If one thinks VGA passthrough as a matter of hardware instead, then it will work wonderfully. So if you really want to get rid of that nasty Windows partition (oh yeah!) you should start with the correct HW, then the SW will work butter smooth.
¹=on large scale. of course, there will be systems where one can.
Performance optimization, using the latest instruction sets. Wayland support. Improved 3D drivers with full Vulkan support and maybe DirectX via Gallium3D. Fully open source drivers for all common hardware, so no more need for the extension pack. Update to Python 3.
Every maintenance release is filled with special-cased 'fixes' that wind up breaking something else, calling for the next round of special-cased 'fixes', ad infinitum.
We've completely abandoned it for kvm and docker because we got tired of having our test platform broken with each patch release. Since we left virtualbox behind, all of our partners have had an easier time replicating our environment reliably.
I've had to flip to VMWare for packaging usb-related software for deployment purposes. USB detection and function is hit and miss.
This is just my own experience, but I will say that when you attempt to find solutions to this sort of issue, one encounters a lot of posts from folks looking for the same thing. And not many answers.
I'd be happy for someone here to tell me I'm wrong and point me in the right direction.
Edit: replied to a parent not the correct child. My bad.
101 comments
[ 2.9 ms ] story [ 162 ms ] threadWill this improve or worsen audio latency, or is it just using a more modern API with the same performance characteristics?
Second: Stability. This is more historical, but Parallels has a bad history of being a poor citizen, eating up CPU power for no apparent reason (even when a VM is not running). Truth be told, I have not seen this issue in the last couple of major releases, but it happened so often in the past that I used VMWare exclusively for my Windows VM because I could rely on it not to trounce my CPU. I now use Parallels again for Windows, but only for Windows.
Third: OS Support. Parallels is so tuned to specific OSes that if you try to use anything out of the ordinary, like OpenBSD, you will struggle. VMWare, by contrast, will even work with completely fringe OSes, such as Haiku (a beOS fork), which Parallels won't even boot.
Finally, image portability: I can use the same base image for development and deployment to ESX. And speaking of ESX, VMWare Fusion can connect to ESX hosts and manage / pull up a console / upload and download to data stores. On a Mac this is invaluable because the vCenter plugins just do not work right on anything but Windows. For instance, I have never managed to upload an OVA or ISO to ESX using the vSphere Web Client on a Mac. It always fails.
Don't know about audio in VmWare vSphere, I don't use remote servers to play music :D
Now on osx I run dev db and other server as needed. Nice to roll back to snapshot
Fits in tool box for non automated, as hoc servers. Dont have to configure anything, or write script. Just acts like buying new hardware and slipping in CD.
At least Windows can be run in a VM unlike Hitler's OS (for the dim-witted: that's OS X).
Please stop violating the guidelines by posting such deliberately inflammatory and uninformative comments. That's not what this site is for.
Even with a 256GB drive and a number of tweaks like hosting the Windows pagefile and temp from a passthrough disk, disabling Windows automatic updates, and using an immutable disk containing the OS install/multi-attach for copy-on-write behavior, VBox still used a ton of space to track the differences from my baseline snapshots. Even starting the VM quickly consumed 10-20GB in the new disk image. Was hard to conclude anything other than it wasn't a viable "dual workstation" setup and I capitulated and moved to Windows 10.
Sucks, because it was really quite nice to have a unix under the hood, though WSL makes this a bit more tolerable in Win 10 AU.
All in all though, if you ultimately moved to a native Windows 10, therefore allocated X space of native disk, the space requirement is not different from having only a virtualized one with X space of virtualized disk (heck, you could even pass a partition).
Having said that, if 10-20 GB of space are taken so quickly on boot, it may be worth investigating (you could even vim the diff disk), but I find your claim somewhat misleading, as you're likely experiencing this on the first absolute boot after taking then snapshot, but not on the subsequent ones; therefore, if your system steadily takes 20+20 GB of space, that's a perfectly reasonable requirement.
When the application, running in the guest, output files in the main directory I want them to immediately be available in the host.
This is like vagrant's #1 use case, I don't get why it's not receiving more attention.
Nonetheless, I have had all sorts of issues with trying to tie my 16.04 box to a specific private network IPs.
IIRC though Vagrant requires that you keep the default NAT configured which can make configuring networking on a VM client rather difficult in VBox.
I finally have it stable on VirtualBox (5.0 or 5.1.x), but now am having issues with VMware 8.5, go figure. The boxes published on Atlas are all stable and working with any recent version of VirtualBox or VMware Fusion, though: https://vagrantcloud.com/geerlingguy/boxes/ubuntu1604
The CentOS 6 and 7 boxes I maintain have been quite stable forever; each Ubuntu release seems to carry some lurking demons that pop up in random Packer, Ubuntu, Vagrant, VirtualBox or VMware updates.
Thanks
https://www.virtualbox.org/browser/vbox/trunk
This also ties into 'reproducible builds', even if you find nothing at all what does it mean if you compile the sources and don't end up with a binary that is identical. Oh, and do make sure to check if your compiler isn't inserting it's own backdoor.
http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomps...
Just because I believe in the power of communities over the power of license and I see a pattern in Oracle corporate culture inability to plays nicely with open source communities I know give up on using any free software that is related to Oracle.
R.I.P. virtualbox.
Why is this news?
The horrible VMware plugin is what's making us stick to VirtualBox, even though everybody hates it (shared folders and 3D acceleration being the worst areas).
3D acceleration on VMware Workstation 12.1 is awesome (60fps inside the VM in OpenGL) and it let's me use the VM as a full desktop without even noticing I'm on a VM. Shared folders performance is also 10x better than VirtualBox.
Unfortunately, I have to use vagrant for work and that means my VMware install is dormant... and vagrant's VMware plugin license was wasted money.
I paid for the plugin early on, when it was Hashicorp's first monetization effort. Having good experiences with similar projects like Sidekiq Pro, I was quite surprised when an issue I ran into was summarily dismissed. I can't imagine what it's like post-funding.
It was a beautiful day.
systemd's containerization solution supports quite a few ways to construct network setups. Look for 'network' in `man systemd-nspawn`.
I can't say much about Docker's support though. Haven't used it since 0.6, and I didn't have a favourable opinion of their network management ideas back then either.
In short: VirtualBox is still probably the best option for running those IE VMs, and for cases like this Docker is not really a replacement for or competitor with solutions like VirtualBox.
Essentially, they have a docker-API-compatible HTTP server that runs a different set of container images. Similar to how SmartOS has a docker-API-compatible HTTP server (running on top of, essentially, a Linux emulation layer).
I haven't been following it closely so I don't know what's become of it since then, but if you want IE you're going to need that work.
For other browsers, the Selenium team maintains docker images containing all of the drivers and XVFB code to make them run. They even have a debug image with xvnc on it so you can spy on the browser if something is going wrong.
Actually Microsoft has been contributing quite a bit to the OCI (Open Container Initiative), as well as Docker. So they have been putting in the work. I'm not really partial to Microsoft, but they do have some good engineers that are working on free software.
[1] https://github.com/docker/for-mac/issues/77
At least with traditional VMs for development I can spin up a few low memory VMs (256MB, for example), using just as much RAM as needed. My understanding is that running one low memory Docker container will cause the VM to consume 4GB (or whatever my default is). On a MacBook, where RAM is at a premium, this doesn't work for me.
I imagine the native experience on Linux is much nicer.
I stopped using mac a while ago to avoid performance overhead. Now i'm curious how the new Docker Mac would treat me
https://www.virtualbox.org/browser/vbox/trunk#src/VBox
But it looks like it is not an easy task thanks to Qt.
It's not new nor noteworthy. :\",
The community has no interest in maintaining VirtualBox, mostly because of Oracle. It's a dead project just like OpenOffice, OpenSolaris, etc. One day, enough customers will stop paying Oracle for it, they will look at community contributions (rare to nonexistent?) and will close the project down rationalizing it as they did all the work. The reality is, they don't know how to steer open source projects and have no desire to do that anyway (separate private bug tracker? write access to repository only to Oracle employees? harsh email replies and comments on bug reports?).
It's on life support and will stay like that for a little while. Unfortunately, it's the only hypervisor that vagrant supports decently and it works on Mac OS X, Windows and Linux (as opposed to using KVM on Linux, xhyve on OSX and Hyper-V on Windows... for someone considering building vagrant boxes).
It's sad but completely expected.
Off-topic: You go in one of those Linux boards and they all say it's so easy to do it. I mean, yes, I can follow instructions and make it work but it's so cumbersome for every day usage if you want to use a Windows guest. Death by a thousand paper cuts. I don't have the time or patience to use weird setups in my work desktop anymore. To think about it, I did some pretty crazy stuff a few years ago, I'm surprised I wasn't even fired back then. The Linux equivalent of betting your income on a Hackintosh.
Kinda like anything Linux related. Don't get me wrong, all my servers are using some variation of it, but when it comes to UX (I'm not talking about GUI) and desktop stuff (not only games but anything GPU related) I wish some things were more mature.
> why is so hard to properly do 3D acceleration in a VM?
I don't have a precisely informed answer to this, but I think it's simply because GPUs do not support/accelerate virtualization in hardware.
> And why is it so hard to do GPU passthrough?
Now the interesting bit!
The core problem is that VGA passthrough requires an extensive collaboration of software and hardware parts, I believe significantly more than CPU virtualization.
As a matter of fact, the term "GPU passthrough" is inappropriate/imprecise - you pass an entire card (hence, "VGA passthrough").
I'll enumerate a few critical examples:
There isn't a central, comprehensive, up to date, documentation, this is true.All of this factors are not really domain of the hypervisor; of course they could be integrated, but not in a consistent, safe way.
Now the good part!
If you have a proper system (both in HW and SW), VGA passthrough rocks; I get almost native performance (I can't distinguish native from virtual), it's perfectly stable (doesn't crash and I can execute it multiple times a day), and I launch it in a single command.
As a matter of fact, I've entirely removed Windows from my disk (modern/high end motherboards support BIOS updating directly from a USB memory).
I think it's important to clarify that the problems of VGA passthrough are radically different from the ones of Hackintosh.
Mac O/S is not designed to run on hypervisors unless certain conditions are met (the absence of such conditions being defined as "Hackintosh"), and hypervisors can't officially support conditions other than those. In other words, Hackintosh is something that is not supposed to exist.
VGA passthough on the other hand is something that is supposed to exist and work, it's just very much dependent on the hardware support, and both HW and SW just very recently matured.
What people I think get wrong is that they think VGA passthrough as a function of the software. When the HW support is not there, like in your experience, you will die of a thousand paper cuts. If one thinks VGA passthrough as a matter of hardware instead, then it will work wonderfully. So if you really want to get rid of that nasty Windows partition (oh yeah!) you should start with the correct HW, then the SW will work butter smooth.
¹=on large scale. of course, there will be systems where one can.
Every maintenance release is filled with special-cased 'fixes' that wind up breaking something else, calling for the next round of special-cased 'fixes', ad infinitum.
We've completely abandoned it for kvm and docker because we got tired of having our test platform broken with each patch release. Since we left virtualbox behind, all of our partners have had an easier time replicating our environment reliably.
I've had to flip to VMWare for packaging usb-related software for deployment purposes. USB detection and function is hit and miss.
This is just my own experience, but I will say that when you attempt to find solutions to this sort of issue, one encounters a lot of posts from folks looking for the same thing. And not many answers.
I'd be happy for someone here to tell me I'm wrong and point me in the right direction.
Edit: replied to a parent not the correct child. My bad.