User Tools

Site Tools


computing:virtmanagerhell

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
computing:virtmanagerhell [2018/05/18 07:58] – created oemb1905computing:virtmanagerhell [2026/04/05 00:45] (current) oemb1905
Line 1: Line 1:
 +-------------------------------------------
 +  * **virtmanagerhell** 
 +  * **Jonathan Haack**
 +  * **Haack's Networking**
 +  * **netcmnd@jonathanhaack.com** 
  
 ------------------------------------------- -------------------------------------------
-#**virt-manager stuff** 
-------------------------------------------- 
-Start defualt   
-  sudo virsh net-start default  
  
-Remove bridge +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 qemu-img create -f raw new.img 1000G''. Here's a basic block:
-  sudo ifconfig virbr0 dow +
-  sudo brctl delbr virbr0+
  
-List all +  sudo virt-install --name=new.img \ 
-  sudo virsh net-list --all +  --os-type=Linux \ 
 +  --os-variant=debian10 \ 
 +  --vcpu=1 \ 
 +  --ram=2048 \ 
 +  --disk path=/mnt/vms/students/new.img \ 
 +  --graphics spice \ 
 +  --location=/mnt/vms/isos/debian-11.4.0-amd64-netinst.iso \ 
 +  --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/console inside the shell of the host to manage the install itself:
  
-------------------------------------------- +  virt-install --name=domain.com.qcow2 \ 
-#**Simple Bridge Mode Virt-Manager** +    --os-variant=debian12 \ 
-------------------------------------------- +    --vcpu=2 \ 
-create it - use gui, or brctl+    --memory 4096 \ 
 +    --disk path=/mnt/machine/domain.com.qcow2,driver.discard=unmap \ 
 +    --check path_in_use=off \ 
 +    --graphics none \ 
 +    --location=/mnt/isos/debian-13.1.0-amd64-netinst.iso \ 
 +    --network bridge:br0,target=domain-com \ 
 +    --channel unix,target_type=virtio,name=org.qemu.guest_agent.0 \ 
 +    --initrd-inject=/mnt/configs/${hostname}/preseed.cfg \ 
 +    --extra-args="auto=true priority=critical preseed/file=/preseed.cfg console=ttyS0,115200n8" 
 + 
 +To clone an existing image, do the following: 
 + 
 +  virt-clone \ 
 +  --original=clean \ 
 +  --name=sequoia \ 
 +  --file=/mnt/vms/students/sequoia.img 
 + 
 +If you have a legacy image that needs to be larger, then install a few tools and the proceed to expand the virtual hard disk as follows: 
 + 
 +  apt install qemu-img kpartx 
 +  qemu-img resize debian10.img +50G 
 +   
 +After expanding the virtual hard disk, open gparted in X passthrough / command line and expand the existing partition into as much of the the new space as you prefer. And to rename a VM (domain), do the following: 
 +   
 +  virsh shutdown <old-name> 
 +  virsh domrename <old-name> <new-name> 
 +   
 +To delete a domain, virt-manager uses the undefine command. To remove the accompanying storage with it, parse the command as follows: 
 + 
 +  virsh undefine guest1 --remove-all-storage 
 +   
 +If you need to force stop a machine, virt-manager uses the destroy command, as follows: 
 + 
 +  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. 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 --f qcow2 -O raw guest1.qcow2 guest1.raw 
 +   
 +If you do end up using this, then you will need to edit the virtual machine's xml file. To do that, open the file and edit the disk type. Change ''type'' and ''source file='' to match the new type and extension. If you also moved the location, you can edit that now as well. 
 + 
 +  virsh edit guest1 
 +  <driver name='qemu' type='raw' cache='none'/> 
 +  <source file='/mnt/vms/students/guest1.qcow2'/> 
 +   
 +Another essential tool is the ability to create snapshots and, when necessary, revert to them. Here are the commands to create snapshot1 and then later revert to that specific snapshot. 
 + 
 +  virsh snapshot-create-as guest1 snapshot1 --description "first snapshot 11-13-22" 
 +  virsh snapshot-revert guest1 snapshot1 
 +   
 +If you don't care about naming the snapshot or customizing the description, you may optionally create the snapshot by excuting this: 
 + 
 +  virsh snapshot-create guest1 
 +   
 +To create an external snapshot, append the following arguments: 
 + 
 +  virsh snapshot-create-as guest1 snapshot1 --description "first snapshot 11-13-22" --diskspec vda,snapshot=external 
 +   
 +If you want to revert to the latest snapshot, then execute this:  
 + 
 +  virsh snapshot-revert guest1 --current 
 +   
 +If you need to delete a particular snapshot, or delete all children of a snapshot, execute: 
 +   
 +  virsh snapshot-delete guest1 snapshot1 
 +  virsh snapshot-delete guest1 --current --children-only 
 + 
 +   
 +To list all snapshots for a particular guestOS, execute this: 
 + 
 +  virsh snapshot-list guest1 
 +   
 +To get information about the snapshot, these commands help: 
 + 
 +  virsh snapshot-info guest1 snapshot 
 +  virsh snapshot-dumpxml guest1 snapshot1 
 +   
 +If you need to make a live backup, do the following (Note: make sure that ''sudo apt install qemu-guest-agent'' is installed on the guest OS): 
 + 
 + 
 +  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: 
 + 
 +  qemu-img info disk.qcow2 
 +   
 +To regain space that is being used needlessly, you can sparsify the qcow2 disk. Note that you must install virt-sparsify separately with ''sudo apt install libguestfs-tools''.  
 + 
 +  virt-sparsify --in-place disk.qcow2 
 +   
 +Most importantly, there's often a need to expand a qcow2 disk. For that, I first recommend you backup the disk. Then, you can either specify the desired or target size, or you specify an increment of space to add on to the disk. 
 + 
 +  cp -ar --sparse=always disk.qcow2 disk.bk.qcow2 
 +  qemu-img resize disk.qcow2 1000G 
 +  qemu-img resize disk.qcow2 +10G 
 +   
 +Okay, so another big issue with qcow2 images is them growing over time from writes/deletes and then those blocks taking up space on the hypervisor while not actually being used on the guestOS any longer. To stop this, enable unmap on the virtIO disk in virsh, and then schedule a timer within the guest OS to trim those underlying blocks. 
 +   
 +  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,use a combination of ``ncdu`` which shows actually consumed space on the host OS, along with the following dd command to easily consume and delete space: 
 + 
 +  dd if=/dev/urandom of=file bs=4M count=500 
 +   
 +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 /mnt/vms/backups/vm1-backup-dir/ 
 +  qemu-img create -f qcow2 vm1-backup.qcow2 32G 
 +  virsh attach-disk guestOS.qcow2 \ 
 +    --source /mnt/vms/backups/vm1-backup-dir/vm1-backup \ 
 +    --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! 
 +   
 +  sudo apt install libguestfs-tools 
 +   
 +After that, confirm the location of your virtual machine.  You need to know the actual name of the .img file for this to work.  Usually (unless it was changed by someone), this is the name that appears in the virt-manager window. 
 +   
 +  virsh dumpxml putnameofimagehere | xpath -e /domain/devices/disk/source 
 + 
 +Navigate to the directory it spit out, and back up the image and rename it before you proceed: 
 + 
 +  cd /var/lib/libvirt/images/ 
 +  sudo cp /var/lib/libvirt/images/putnameofimagehere.img /var/lib/libvirt/images/putnameofimagehere.img.bak 
 + 
 +Once you know the name of the .img file and the location of it, prepare the virtual file systems for expansion: 
 + 
 +  virt-filesystems --long --parts --blkdevs -h -a /var/lib/libvirt/images/putnameofimagehere.img 
 +   
 +Build a new, larger, container for the final disk, and set it aside for the merge/expansion that the tools are going to provide: 
 + 
 +  truncate -s 128G /var/lib/libvirt/images/outdisk 
 + 
 +Now it is time to resize the existing image, using the container you just created: 
 + 
 +  virt-resize --expand /dev/sda2 /var/lib/libvirt/images/putnameofimagehere.img /var/lib/libvirt/images/outdisk 
 +   
 +Okay, now we need to rename the new image we created to the name that virt-manager is looking for, i.e., the name of the original image.  Remember, you should have the .bak file you made earlier in case this does not work.  This is done as follows: 
 + 
 +  cp /var/lib/libvirt/images/putnameofimagerhere.img /var/lib/libvirt/images/putnameofimagerhere.img.old 
 +  mv /var/lib/libvirt/images/outdisk /var/lib/libvirt/images/putnameofimagehere.img 
 +  
 +Made yet another attempt to do by command line in 2022. Install packages required for resizing virtual hard disks and for listing partitions inside virtual hard disks. 
 +   
 +  apt install qemu-img kpartx 
 +   
 +Add 50G of size to the emulated physical hard disk. This is not to be confused with adding space to, or extending, the partition inside it. 
 + 
 +  qemu-img resize debian10.img +50G 
 +   
 +Mount the image file in the present directory, and show all of its mappings. 
 + 
 +  kpartx -v -a debian10.img 
 +   
 +Now, it is time to extend the partition. Your loops might have different #s after, use tab to find the right one (prolly largest #). 
 + 
 +  parted /dev/loopXX print 
 +   
 +You will get output like this: 
 + 
 +  Model: Unknown (unknown) 
 +  Disk /dev/loopXX: 142GB 
 +  Sector size (logical/physical): 512B/512B 
 +  Partition Table: loop 
 +  Disk Flags:  
 +  Number  Start  End    Size   File system  Flags 
 +        0.00B  142GB  142GB  ext4 
 +    
 +Remove the appropriate mapping. In my case, I am extending the boot volume of a virtual machine, so it was entry 1.  
 + 
 +  parted /dev/loopXX rm 1 
 +   
 +Extend the partition from the start of the mapping you removed to the upper size limit listed in Disk. 
 + 
 +  parted /dev/loopXX mkpart primary ext4 0.00B 142GB 
 +   
 +Verify the new mapping. 
 + 
 +  parted /dev/loopXX print 
 +   
 +Run fsck before resizing the file system. You here appending "p1" to the name in order to make a new partition or mapping. 
 + 
 +  e2fsck -f /dev/mapper/loopXXp1 
 +   
 +Extend the file system inside the partition to the entirety of the partition table. 
 + 
 +  resize2fs /dev/mapper/loopXXp1  
 +   
 +Unmount the image 
 + 
 +  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: 
 + 
 +<code> 
 +  virsh edit domain.com.qcow2 
 +   
 +  <interface type='bridge'> 
 +    <mac address='11:23:11:7b:99:33'/> 
 +    <source bridge='br0'/> 
 +    <target dev='domain-com'/> 
 +    <model type='virtio'/> 
 +    <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> 
 +  </interface> 
 +</code> 
 + 
 +Make sure that Cockpit can access a terminal: 
 + 
 +<code> 
 +  virsh edit domain.com.qcow2 
 +  <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'> 
 +    <listen type='address' address='127.0.0.1'/> 
 +  </graphics> 
 +</code> 
 + 
 +If you don't have video enabled, do the following (also needed for Cockpit Terminal rendering): 
 + 
 +Option 1 (cirrus): 
 +<code> 
 + <video> 
 +   <model type='cirrus' vram='16384' heads='1' primary='yes'/> 
 +   <address type='pci' domain='0x0000' bus='0x10' slot='0x01' function='0x0'/> 
 + </video> 
 +</code> 
 + 
 +Option 2 (qxl) 
 +<code> 
 + <video> 
 +   <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> 
 + </video> 
 +</code> 
 + 
 +Option 3 (use commands) 
 +  virt-xml domain.com.qcow2 --add-device --graphics vnc,listen=127.0.0.1 
 +  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 ''0x07'' vs. ''0x08'': 
 + 
 +<code> 
 +  <filesystem type='mount' accessmode='passthrough'> 
 +    <driver type='virtiofs'/> 
 +    <source dir='/mnt/support1'/> 
 +    <target dir='support1'/> 
 +    <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> 
 +  </filesystem> 
 +  <filesystem type='mount' accessmode='passthrough'> 
 +    <driver type='virtiofs'/> 
 +    <source dir='/mnt/support2'/> 
 +    <target dir='support2'/> 
 +    <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/> 
 +  </filesystem> 
 +</code> 
 + 
 +Then, inside the VM:
  
-sudo nano /etc/network/interfaces+  mkdir -p /mnt/support1 
 +  mkdir -p /mnt/support2 
 +  nano /etc/fstab 
 +  support1   /mnt/support1   virtiofs   defaults,_netdev   0 0 
 +  support2   /mnt/support2   virtiofs   defaults,_netdev   0 0 
 +   
 +If you find ''virsh console domain.com.qcow2'' does not provide a functioning terminal, then run this inside the guest:
  
-  auto br1 +  sudo systemctl enable serial-getty@ttyS0.service 
-  iface br1 inet dhcp +  sudo systemctl start serial-getty@ttyS0.service
-     bridge_ports enp3s0 +
-     bridge_stp on +
-     bridge_fd 0.0+
  
 +Migrating an existing VDD and virsh instance ... just dump or copy paste the .xml with ''virsh dump'' or ''virsh edit'', then create a new xml file, typically in ''/var/lib/libvirtd/qemu'', then run:
  
 +  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.
  
 + --- //[[alerts@haacksnetworking.org|oemb1905]] 2026/04/05 00:42//
computing/virtmanagerhell.1526630333.txt.gz · Last modified: (external edit)