Clone VM

[x09]

SUMMARY

Clone VM functionality

ISSUE TYPE

I have few VM as templates (Server OS, Desktop OS, etc). if necessary, I clone the original (source) VM and work in its replica (destination). If I need to create a test bench from 1 server and 5 desktop machines, 2 source (as template) VMs are enough for me. I just clone from them.

I want work with it via ansible, but have not.

COMPONENT NAME

(https://docs.ansible.com/ansible/latest/collections/community/libvirt/virt_module.html)

ADDITIONAL INFORMATION

I suggest add new command, something like

- name: Clone VM
  community.libvirt.virt:
    command: clone
    source_name: vm01_srv_template
    dest_name:  dns_server_01
       dest_pool:  'new_pool_name_if_defined'

[csmart]

Hi @x09 thank you for putting in this suggestion, much appreciated! I can see how a clone function could be useful. I expect that it would have to update MAC addresses and create new images, etc. Perhaps have to see how existing libvirt manages this, for example, selection of storage location, etc.

If you need this kind of functionality right now, I wonder if you could dump the XML from the virtual machine, modify it and define a new machine? Definitely a few more steps, but might be something to consider if it's useful for you. Another option might be to use a virsh command with the Ansible shell module.

Thanks again for the suggestion, we can continue to discuss any thoughts on this issue.

[nodiscc]

Since it is not currently possible to properly clone a VM directly from ansible (or even from a single libvirt command), I have implemented a simple bash command-line wrapper to perform this operation and work around the quirks. You can find it here (L361-492). The quirks are:

• you need to edit the network configuration inside the clone if using static IP addressing (else IP addresses of the clone and the template would collide - I only implemented this for Debian//etc/network/intefaces-based configuration)
• run virt-clone (which also sets random UUID and MAC addresses)
• run virt-sysprep with the correct options (this is important - else the resulting machines will all have the same SSH server key, machine ID, unique identifiers...), which also injects SSH keys, regenerates the server key, prepares user accounts, sets passwords...

You can try it like this:

$ wget https://raw.githubusercontent.com/nodiscc/xsrv/master/xsrv
$ chmod a+x xsrv 
$ ./xsrv init-vm --help
USAGE: ./xsrv init-vm  --name VM_NAME [--template debian11-base] --ip VM_IP --netmask VM_NETMASK --gateway VM_GATEWAY [--ssh-port VM_SSH_PORT] [--sudo-user deploy] [--sudo-password VM_SUDO_PASSWORD] --ssh-pubkey 'ssh-rsa AAAAB...' [--root-password VM_ROOT_PASSWORD] [--disk-path /path/to/my.CHANGEME.org.qcow2] [--memory 1024] [--vcpus NUM_CPU]
        EXAMPLE: ./xsrv init-vm --template debian11-base --name my.CHANGEME.org --ip 10.0.0.223 --netmask 24 --gateway 10.0.0.1 --sudo-user deploy --sudo-password CHANGEME --ssh-pubkey 'ssh-rsa AAAAB...' --root-password CHANGEME --memory 3G --vcpus 4 [--dump]
        Initialize a libvirt VM from a template, configure resources/users/SSH access, and start the VM.
        Requirements: openssh-client sshpass libvirt virtinst libvirt-daemon-system libguestfs-tools pwgen netcat-openbsd util-linux
        --template      name of the template to create the new VM from (default debian11-base)
        --name          REQUIRED name of the VM to create
        --ip            REQUIRED IP address of the VM
        --gateway       REQUIRED default network gateway of the VM
        --netmask       network mask of the VM (CIDR notation, default 24)
        --root-password root account password (default generate and display a random password)
        --sudo-user     administrative (sudoer) user account (default deploy)
        --sudo-password password for the administrative (sudoer) user account (default generate and display a random password)
        --ssh-pubkey    REQUIRED public key to authorize on the administrative (sudoer) account
        --disk-path     path to the qcow2 disk image to create (default: /var/lib/libvirt/images/VM_NAME.qcow2)
        --memory        VM memory with M or G suffix (default 1G)
        --vcpus         number of vCPUs (default: same value as the template)
        --dump          display the VM XML definition after creation, for use with the nodiscc.xsrv.libvirt role

I would also be interested in having this functionality directly available from the libvirt collection/module. I imagine this would take the form of a clone_from: my_template_vm_name parameter, and if the VM does not exist, it would be created from the template passed in this parameter. But as you can see there are many more parameters that one would want to change when cloning a VM, I don't know if it would be possible to manage them all though the module.

[dseeley]

I also have a mechanism for cloning VMs in my own fork of this repo (I've never found the time to write testcases for it, hence why no PR yet) - https://github.com/dseeley/community.libvirt/tree/develop:

• plugins/modules/virt_volume.py is a new module to create/clone a volume, as well as create a cloudinit cdrom (so you can e.g. set the networking parameters on a cloned vm).
• plugins/modules/virt.py is modified to add the functions: get_guest_agent_info, attach_device, detach_device, update_device, set_metadata (so that, amongst other reasons, the cloudinit cdrom can be attached and detached)

I use it in my cluster management software (https://github.com/dseeley/clusterverse), the relevant playbook of which is:

• https://github.com/dseeley/clusterverse/blob/master/create/tasks/create_libvirt.yml

[Tronde]

Hello @x09, Hello All,
I have the same use case as described by @x09 in his initial post. I install some VMs to use them as templates to create new VMs for lab environments as I need them.

To do that I've developed an Ansible Role that enables you to specify the VMs you need and the template to use as a YAML dictionary. Then the role uses this dictionary to perform the following tasks:

1. Get a list of VMs to check whether a VM with the same name already exists.
2. Copy the base disk image.
3. Configure the image (set root password, add ssh key, uninstall cloud-init, and selinux-relabel (only if selinux is installed in template)).
4. Define VMs as specified in dictionary.
5. Create a second disk if specified in dictionary and attach it.
6. Ensure the VMs are started.

You find this role at:

• GitHub: https://github.com/Tronde/kvm_provision_lab
• Galaxy: https://galaxy.ansible.com/Tronde/kvm_provision_lab

Feel free to give it a try. I use it for some time now and would be happy if other folks find it useful, too. Any feedback is appreciated.

Best regards,
Tronde

[Andersson007]

@csmart can @Tronde 's work be somehow incorporated with the project?

[csmart]

Thanks for the suggestion @Tronde and apologies for the delayed response. I think it would be good to include some example playbooks on how to define a machine, one that uses XML template and one that uses virt-install, to help get users started. Although overall, I'd also prefer see the role improve from the Python side to add and improve features, if possible.

I say example playbooks because I'm not sure how possible it would be to include a universal playbook at this stage because it needs to be both flexible and robust, which I don't think is a particularly trivial undertaking (that's is why in my own role I've wrapped virt-install as it includes more of the logic I can take advantage of). For example, supporting multiple disks, various disk types (SCSI/SATA/IDE/NVMe), SSD/rotational disks, disk image formats, multiple disk controllers and settings (SCSI/virtio/SATA, etc), multiple network cards on different networks, unique/defined mac addresses, CPU model, balloon settings, graphics cards, remote settings, serial, passthrough, etc, then tying all the required PCI devices and addresses together to make it work every time. We could potentially do that with some extensive logic in the XML file, but I'm just not sure how easy or worthwhile it would be - this is the kind of thing I'd love to see extended in the Python code.

Please feel free to create a merge request to add a generic playbook based off your work and I'll review and test it! I think it would be good to use as cut down an XML as possible and let libvirt fill in the details when it brings up the VM and ideally if there are some tests so that we can automate testing it on multiple distros, that'd be great!

Please let me know how you go and reach out if you need a hand. Cheers!

[Tronde]

No worries @csmart and thanks a lot for your feedback. The role may improve over time as I use it in my lab environments. I'll show it again when it has advanced.

Cheers!

[csmart]

Hey @Tronde, what I meant to say was that I think your role as it is would be great to add as an example playbook on how to use the collection to define a VM using an XML template. I didn't mean to suggest you need to go and make it more awesome before we can merge it in, so if you're happy to create a MR to get it in as an example for now, feel free. We can always work to improve it over time, but I'll leave it up to you. Cheers!

[Tronde]

Well, I guess I misunderstood you then. Let me give the role one more tweak and I'll send a merge regquest. :-)