ddelnano
commented
3 years ago I found out that this actually a race condition. If the VIF attachment, detachment code runs before the guest kernel has loaded its drivers it throws that error. The key was to add time.Sleeps into the code for now and the test mentioned above has been re-enabled.
When I was developing #54, I noticed that when my terraform acceptance code tried to create a second VIF for a VM I would receive the following error from the XO api.
What made this very confusing was that if I created a VM from the same template through the XO web UI or calling
vm.createwith the xo-cli I never experienced this issue. I did notice that when the terraform acceptance tests run that the VM created during the test has a kernel panic and goes into a crash loop. When the VM was created outside the test the kernel panic doesn't occur. Unfortunately I was only able to see the console output in the XO UI which isn't that helpful for copy and pasting or seeing the full log. I tried configuringxenconsoledto log the output to the filesystem (using--log=all). This created a file for each VM but the boot logs I was interested in weren't written to the file :(.The acceptance criteria is to fix these missing pv drivers, update the following tests (will add link once #54 is merged) to not bypass returning errors and add additional assertions about VIF state during the acceptance tests.