Support and document how to create blank libvirt VMs

[ukalifon]

I am trying to use linchpin to create VMs with a blank harddisk. The VMs won't boot, except when a user will plug in a live cd. As a disk image, I am passing a url to a blank qcow image (that I prepared ahead of time with qemu-img create):

image_src: file:///tmp/blank-disk-132gb.qcow2

Linchpin still tried to run cloud-init, and to work around that I added:

   cloud_config:
          virt_type: do_nothing

But now it's failing on the ansible task waiting for the machine to get an IP... How can I create a blank VM and not even turn it on?

TASK [libvirt : mac_and_ip | wait up to 5 mins for dhcp ip address] *************************************************************************************************
FAILED - RETRYING: mac_and_ip | wait up to 5 mins for dhcp ip address (30 retries left).
FAILED - RETRYING: mac_and_ip | wait up to 5 mins for dhcp ip address (29 retries left).
FAILED - RETRYING: mac_and_ip | wait up to 5 mins for dhcp ip address (28 retries left).

[Dannyb48]

@JunqiZhang0 Do you have the cycles to check this out and see if we support this use case?

[JunqiZhang0]

@ukalifon Hey Udi, is it something very urgent? Is it OK that I take look at it tomorrow?

[ukalifon]

It can wait until tomorrow, thanks a lot !

[JunqiZhang0]

@ukalifon So I tested yesterday, it seems linchpin can't do blank VM, but I can try adding this function by adding a ifesle statement, if you define the parameter blank_VM, linchpin will skip the VM turn on phase. What do you think?

[ukalifon]

We can consider passing it in cloud_config like this:

cloud_config:
virt_type: blank_VM # pass blank_VM instead of do_nothing

This will keep the use case simple, so that blank_VM won't be required as an additional parameter. In any ways the user will still need to create a blank qcow2 image in advance and save it somewhere on the filesystem, then pass it like I did:
image_src: file:///tmp/blank-disk-132gb.qcow2

I agree that blank_VM should completely skip the turning on of the VM. Thanks a lot for supporting this case!