Also generate images for Hyper-V #98
Conversation
Sealing removes the persistent udev rules for eth0 and the sshd host keys, which is a good idea for an image that will serve as a template for creating multiple guest VMs.
VirtualBox and Hyper-V do not have a serial console by default. This is mostly harmless when the console is only used for output, but relabeling the filesystem insists on having a tty, passing init=/bin/bash or booting a fully sealed template also require a tty - resulting in a system that always hangs indefinitely on boot (or, in the init case, produces a kernel panic).
|
will removing the console from ttyS0 not mean that we lose it on libvirt runs ? |
|
Yes - is that used anywhere? I asked on the centos-devel mailing list, nobody seemed to use it. I had to remove it due to hangs during boot when the serial console isn't enabled (as is the case with most virtualization providers). See issue #100 - but I've also had while trying to fine-tune the sealed images for Hyper-V - if you |
|
having access to the console is handy. Do we just need to fork the hyper-v kickstarts ? |
|
No, if anything, we need to separate libvirt from the others. VirtualBox doesn't have a serial console by default, which leads to the hang in Relax and Resue (issue #100), and VMware also doesn't have it enabled by default, although it seems smart enough to emulate a disconnected one if a guest tries to use the matching ports (despite not being listed by the emulated hardware). Hyper-V also doesn't have one by default. It would still be possible for users to enable it after the first boot by calling grubby - just not when creating a new Vagrant box. |
|
I forgot to mention, we could also patch Image Factory to enable a disconnected UART for each virtualization solution we support in the OVF hardware description (although I've only looked at this for VirtualBox). |
|
Ping @scooley - here's the PR I mentioned today |
|
I enabled the serial console again, just set tty0 as default to avoid those hangs (works fine in my local tests with VirtualBox on OS X). This was about 8 days ago, maybe I should have mentioned it here instead of #centos-devel. @kbsingh any thoughts? |
| # Seal for deployment | ||
| rm -rf /etc/ssh/ssh_host_* | ||
| hostnamectl set-hostname localhost.localdomain | ||
| rm -rf /etc/udev/rules.d/70-* |
There was a problem hiding this comment.
sys-unconfig uses rm -f /etc/udev/rules.d/*-persistent-*.rules on EL7.
There was a problem hiding this comment.
@ekohl Thanks for taking a look! I took that line directly from Red Hat's Virtual Machine Management Guide, which is the latest version. I'd rather stick to the official documentation when possible, unless there are good arguments against it (although in our case it's probably the same thing, the only file in /etc/udev/rules.d after our minimal installation is 70-persistent-net.rules).
There was a problem hiding this comment.
I agree it'll be the same in practice. Just odd that sys-unconfig as shipped by init-scripts uses something different from the documentation.
|
Let's fork these ks files specifically for hyperv, so the changes dont impact kvm and vbox images. We can then get it merged in and built released. |
|
I separated the kickstarts for hyperv from the other ones due to @kbsingh's concerns about the serial console. I'm pretty unhappy about this solution: all further changes to the kickstarts will have to be performed in 4 kickstarts, as opposed to just 2 like now. cico: please [test] |
|
We can merge them back in once we get the changes better tested on other hv's. |
|
[Test] |
Hyper-V support finally made possible by recent upgrades to CBS; in particular, we are now using qemu-img-ev from the Virt SIG; qemu-img from CentOS generates sparse .vhd files, which expand to the full 40GB size on Windows and generate lots of disk I/O.