This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| computing:virtmanagerhell [2022/11/13 16:15] – oemb1905 | computing:virtmanagerhell [2026/04/05 00:45] (current) – oemb1905 | ||
|---|---|---|---|
| Line 7: | Line 7: | ||
| ------------------------------------------- | ------------------------------------------- | ||
| - | To make a VM from the command line, do the following. Note that this recipe assumes you have already created your virtual switch, br0. It also presumes you have already created your virtual disk, and if you have not, simply run '' | + | To make a VM from the command line, do the following. Note that this recipe assumes you have already created your virtual switch, br0. It also presumes you have already created your virtual disk, and if you have not, simply run '' |
| sudo virt-install --name=new.img \ | sudo virt-install --name=new.img \ | ||
| Line 18: | Line 18: | ||
| --location=/ | --location=/ | ||
| --network bridge:br0 | --network bridge:br0 | ||
| + | |||
| + | Here's a more complex block, that enables trim on vdd, uses a preseed.cfg file to automate install, establishes a custom vnet name, enables the guest agent, and opens a terminal/ | ||
| + | |||
| + | virt-install --name=domain.com.qcow2 \ | ||
| + | --os-variant=debian12 \ | ||
| + | --vcpu=2 \ | ||
| + | --memory 4096 \ | ||
| + | --disk path=/ | ||
| + | --check path_in_use=off \ | ||
| + | --graphics none \ | ||
| + | --location=/ | ||
| + | --network bridge: | ||
| + | --channel unix, | ||
| + | --initrd-inject=/ | ||
| + | --extra-args=" | ||
| To clone an existing image, do the following: | To clone an existing image, do the following: | ||
| Line 44: | Line 59: | ||
| virsh destroy guest1 | virsh destroy guest1 | ||
| - | I prefer the raw format (.img) but if I change my mind later, perhaps because I want snapshots, then I can easily shutdown the machine and convert the image as follows: | + | I prefer the raw format (.img) but if I change my mind later, perhaps because I want snapshots, then I can easily shutdown the machine and convert the image as follows. If I change my mind, I can also go in reverse back to raw. |
| - | qemu-img convert -f raw -O qcow2 guest1.img guest1.qcow2 | + | qemu-img convert |
| + | qemu-img convert -p -f qcow2 -O raw guest1.qcow2 guest1.raw | ||
| | | ||
| If you do end up using this, then you will need to edit the virtual machine' | If you do end up using this, then you will need to edit the virtual machine' | ||
| Line 71: | Line 87: | ||
| virsh snapshot-revert guest1 --current | virsh snapshot-revert guest1 --current | ||
| | | ||
| - | If you need to delete a particular snapshot, execute | + | If you need to delete a particular |
| | | ||
| virsh snapshot-delete guest1 snapshot1 | virsh snapshot-delete guest1 snapshot1 | ||
| + | virsh snapshot-delete guest1 --current --children-only | ||
| + | |||
| | | ||
| To list all snapshots for a particular guestOS, execute this: | To list all snapshots for a particular guestOS, execute this: | ||
| Line 83: | Line 101: | ||
| virsh snapshot-info guest1 snapshot | virsh snapshot-info guest1 snapshot | ||
| virsh snapshot-dumpxml guest1 snapshot1 | virsh snapshot-dumpxml guest1 snapshot1 | ||
| + | | ||
| + | If you need to make a live backup, do the following (Note: make sure that '' | ||
| + | |||
| + | |||
| + | virsh domfsfreeze guest1.qcow2 | ||
| + | qemu-img create -f qcow2 -b guest1.qcow2 snapshot.qcow2 | ||
| + | virsh domfsthaw guest1.qcow2 | ||
| + | |||
| | | ||
| At times you may need to resize or gather information about a particular virtual disk. If they are in the qcow2 format, gather information as follows: | At times you may need to resize or gather information about a particular virtual disk. If they are in the qcow2 format, gather information as follows: | ||
| Line 88: | Line 114: | ||
| qemu-img info disk.qcow2 | qemu-img info disk.qcow2 | ||
| | | ||
| - | To regain space that is being used needlessly, you can sparsify the qcow2 disk as follows: | + | To regain space that is being used needlessly, you can sparsify the qcow2 disk. Note that you must install virt-sparsify separately with '' |
| virt-sparsify --in-place disk.qcow2 | virt-sparsify --in-place disk.qcow2 | ||
| Line 97: | Line 123: | ||
| qemu-img resize disk.qcow2 1000G | qemu-img resize disk.qcow2 1000G | ||
| qemu-img resize disk.qcow2 +10G | qemu-img resize disk.qcow2 +10G | ||
| + | | ||
| + | Okay, so another big issue with qcow2 images is them growing over time from writes/ | ||
| + | | ||
| + | sudo systemctl enable fstrim.timer | ||
| + | sudo systemctl start fstrim.timer | ||
| + | | ||
| + | You can also manually run fstrim and then power down the qcow2 image and convert it. You may optionally use compression to save more space, but it takes very long. | ||
| + | |||
| + | fstrim -v / | ||
| + | qemu-img convert -O qcow2 guest.qcow2 guest-trimmed.qcow2 | ||
| + | qemu-img convert -O qcow2 -c guest.qcow2 guest-trimmed.qcow2 | ||
| + | | ||
| + | To test trimming functionality, | ||
| + | |||
| + | dd if=/ | ||
| + | | ||
| + | To create a backup volume inside a guest you create the volume, attach it, and then shell into the guest and format, mount, and create an fstab entry. First, on the hostOS: | ||
| + | | ||
| + | cd / | ||
| + | qemu-img create -f qcow2 vm1-backup.qcow2 32G | ||
| + | virsh attach-disk guestOS.qcow2 \ | ||
| + | --source / | ||
| + | --target vdb \ | ||
| + | --persistent | ||
| + | | ||
| + | Then, on the guestOS: | ||
| + | | ||
| + | mkdir /mnt/backup | ||
| + | mkfs.ext4 /dev/vdb | ||
| + | mount -t auto /dev/vdb /mnt/backup | ||
| + | nano /etc/fstab | ||
| + | /dev/vdb /mnt/backup ext4 defaults, 0 0 | ||
| The rest from here on out is my attempt at resizing an .img virtual disk using tools exclusively from virsh / virt-manager. These are highly risky moves and totally not needed for day to day operations. It was more of a mission I was on and based on a tutorial I used nearly 15 years ago when expanding a Windows VM I used for teaching software that was only on that VM. At any rate, I have only succeeded twice doing this, and often get confused looking at the l00ps. Proceed with caution! | The rest from here on out is my attempt at resizing an .img virtual disk using tools exclusively from virsh / virt-manager. These are highly risky moves and totally not needed for day to day operations. It was more of a mission I was on and based on a tutorial I used nearly 15 years ago when expanding a Windows VM I used for teaching software that was only on that VM. At any rate, I have only succeeded twice doing this, and often get confused looking at the l00ps. Proceed with caution! | ||
| Line 177: | Line 235: | ||
| kpartx -d debian10.img | kpartx -d debian10.img | ||
| + | | ||
| + | User and group perms: | ||
| + | |||
| + | adduser libvirt-qemu kvm | ||
| + | adduser cockpit-ws kvm | ||
| + | newgrp kvm | ||
| + | |||
| + | Add network interface as custom name for easy tracking: | ||
| + | |||
| + | < | ||
| + | virsh edit domain.com.qcow2 | ||
| + | | ||
| + | < | ||
| + | <mac address=' | ||
| + | <source bridge=' | ||
| + | <target dev=' | ||
| + | <model type=' | ||
| + | <address type=' | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | Make sure that Cockpit can access a terminal: | ||
| + | |||
| + | < | ||
| + | virsh edit domain.com.qcow2 | ||
| + | < | ||
| + | <listen type=' | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | If you don't have video enabled, do the following (also needed for Cockpit Terminal rendering): | ||
| + | |||
| + | Option 1 (cirrus): | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | Option 2 (qxl) | ||
| + | < | ||
| + | < | ||
| + | < | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | Option 3 (use commands) | ||
| + | virt-xml domain.com.qcow2 --add-device --graphics vnc, | ||
| + | virt-xml domain.com.qcow2 --add-device --video qxl | ||
| + | virsh reboot domain.com.qcow2 | ||
| + | |||
| + | Add virtiofs mount point. Here's two, note the staggered bus entry of '' | ||
| + | |||
| + | < | ||
| + | < | ||
| + | <driver type=' | ||
| + | <source dir='/ | ||
| + | <target dir=' | ||
| + | <address type=' | ||
| + | </ | ||
| + | < | ||
| + | <driver type=' | ||
| + | <source dir='/ | ||
| + | <target dir=' | ||
| + | <address type=' | ||
| + | </ | ||
| + | </ | ||
| + | |||
| + | Then, inside the VM: | ||
| + | |||
| + | mkdir -p / | ||
| + | mkdir -p / | ||
| + | nano /etc/fstab | ||
| + | support1 | ||
| + | support2 | ||
| + | | ||
| + | If you find '' | ||
| + | |||
| + | sudo systemctl enable serial-getty@ttyS0.service | ||
| + | sudo systemctl start serial-getty@ttyS0.service | ||
| + | |||
| + | Migrating an existing VDD and virsh instance ... just dump or copy paste the .xml with '' | ||
| + | |||
| + | virsh define host.com.xml | ||
| + | virsh start host.com | ||
| + | | ||
| + | You should for sure check the network interface and MAC address, the storage location directory, and obviously run through anything else that might be different on the target migration host. | ||
| - | --- //[[jonathan@haacksnetworking.org|oemb1905]] | + | --- //[[alerts@haacksnetworking.org|oemb1905]] |