| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| computing:vmserver [2022/11/12 19:39] – oemb1905 | computing:vmserver [2023/01/22 14:12] – oemb1905 |
|---|
| zfs list -H -o name -t snapshot | xargs -n1 zfs destroy | zfs list -H -o name -t snapshot | xargs -n1 zfs destroy |
| |
| Of course, off-site backups are essential. To do this, I use a small script that powers down the VM, uses ''cp'' with the ''--sparse=always'' flag to preserve space, and then uses tar with pbzip2 compression to save even more space. From my research, bsdtar seems to honor sparsity better than gnutar so install that with ''sudo apt install libarchive-tools''. The ''cp'' command is not optional, moreover, for remember tar will not work directly on an ''.img'' file. Here's a small shell script with a loop for multiple VMs within the same directory. I also added a command at the end that will delete any tarballs older than 180 days. | Of course, off-site backups are essential. To do this, I use a small script that powers down the VM, uses ''cp'' with the ''--sparse=always'' flag to preserve space, and then uses tar with pbzip2 ''sudo apt install pbzip2'' compression to save even more space. From my research, bsdtar seems to honor sparsity better than gnutar so install that with ''sudo apt install libarchive-tools''. The ''cp'' command is not optional, moreover, for remember tar will not work directly on an ''.img'' file. Here's a small shell script with a loop for multiple VMs within the same directory. I also added a command at the end that will delete any tarballs older than 180 days. |
| |
| DATE=`date +"%Y%m%d-%H:%M:%S"` | DATE=`date +"%Y%m%d-%H:%M:%S"` |
| systemctl restart networking.service | systemctl restart networking.service |
| |
| Now that the virtual switch is setup, I can now provision VMs and connect them to the virtual switch ''br0'' in virt-manager. You can provision the VMs within the GUI using X passthrough, or use the command line with something like this: | Now that the virtual switch is setup, I can now provision VMs and connect them to the virtual switch ''br0'' in virt-manager. You can provision the VMs within the GUI using X passthrough, or use the command line. First, create a virtual disk to your desired size by excuting ''sudo qemu-img create -f raw new 1000G'' and then run something like this: |
| |
| #make new vm | sudo virt-install --name=new.img \ |
| sudo virt-install --name=new \ | |
| --os-type=Linux \ | --os-type=Linux \ |
| --os-variant=debian10 \ | --os-variant=debian10 \ |
| --network bridge:br0 | --network bridge:br0 |
| |
| Once the VM is created and attached to the virtual switch (either using the command line or GUI), it is now time to log into the console with X passthrough (or ssh), and configure the guest OS ''interface'' file with the IP you intend to assign it. Once inside the guest OS, execute ''nano /etc/network/interfaces'' and then edit the file with something like this: | The machine will open in virt-viewer, but if you lose the connection you can reconnect easily with: |
| | |
| | virt-viewer --connect qemu:///system --wait new.img |
| | |
| | Once you finish installation, configure the guestOS interfaces file ''sudo nano /etc/network/interfaces'' with the IP you intend to assign it. You should have something like this: |
| |
| auto epr1 | auto epr1 |
| systemctl restart networking.service | systemctl restart networking.service |
| |
| You should once again execute ''ping 8.8.8.8'' and ''ping google.com'' to confirm you can route within the guest OS. Sometimes, I find a reboot is required. At this stage, you now have a physical host configured with a virtual switch, and one VM provisioned to use the switch with its own external IP. Both the physical host and guest OS in this scenario are public facing so take precautions to properly secure each by checking services ''netstat -tulpn'' and/or utilizing a firewall. You are now in a position to create VMs and various production environments at will. One thing I do is I create base VMs that have ''interfaces'' and ''ssh'' access all ready to go, and then I leverage those to make new instances. Make sure to power down the base image so that you don't have an IP conflict at your data center. | You should once again execute ''ping 8.8.8.8'' and ''ping google.com'' to confirm you can route within the guest OS. Sometimes, I find a reboot is required. At this stage, you now have a physical host configured with a virtual switch, and one VM provisioned to use the switch with its own external IP. Both the physical host and guest OS in this scenario are public facing so take precautions to properly secure each by checking services ''netstat -tulpn'' and/or utilizing a firewall. The main things to configure at this point are ssh access so you no longer need to rely on the virt-viewer console which is slow. To do that, you will need to add packages (if you use the netinst.iso). To make that easy, I keep the sources.list on my primary business server: |
| | |
| | wget https://haacksnetworking.org/sources.list |
| | |
| | Once you grab the ''sources.list'' file, install ''openssh-server'' and exchange keys, you can now use a shell to ssh into the guestOS henceforward. This means that at this point you are now in a position to create VMs and various production environments at will or start working on the one you just created. Another thing to consider is to create base VMs that have ''interfaces'' and ''ssh'' access all ready to go, and then leverage those to make new instances using ''cp''. Alternately, you can power down a base VM and then clone it as follows: |
| |
| #clone existing | |
| virt-clone \ | virt-clone \ |
| --original=clean \ | --original=clean \ |
