By default, Remote Display only works on localhost / 127.0.0.1 and cannot be accessed by ip address or hostname.
Check VRDE / Remote Display IP Address
You can check VRDE / Remote Display ip address using the following methods:
Open command prompt and run netstat -an |find /i “listening” or netstat -an |find /i “[PORT_NUMBER]” and you shall notice it is listening on 127.0.0.1:PORT. Continue reading “Virtualbox fixing VRDE on 0.0.0.0 instead 127.0.0.1” »
Step 1 : Migrate all VMs to another active node
Migrate all VMs to another active node. You can use the live migration feature if you have a shared storage or offline migration if you only have local storage.
Step 2 : Display all active nodes
Display all active nodes in order identify the name of the node you want to remove Continue reading “Remove Node from Proxmox Cluster” »
When trying to “Stop” or “Shutdown” virtual machine from Proxmox (PVE) web gui, the “Cluster log” shows
end task UPID:pve:xxxxxxxx:xxxxxxxx:xxxxxxx:qmstop:xxx:root@pam: can’t lock file ‘/var/lock/qemu-server/lock-xxx.conf’ -got timeout
end task UPID:pve:xxxxxxxx:xxxxxxxx:xxxxxxx:qmreboot:xxx:root@pam: VM quit/powerdown failed
We can manually delete the lock from following path
# The file will be
Make sure only delete the correct one!
You can also do it using script from this site-
Sparse disk image formats such as qcow2 only consume the physical disk space which they need. For example, if a guest is given a qcow2 image with a size of 100GB but has only written to 10GB then only 10GB of physical disk space will be used. There is some slight overhead associated, so the above example may not be strictly true, but you get the idea.
Sparse disk image files allow you to over allocate virtual disk space – this means that you could allocate 5 virtual machines 100GB of disk space, even if you only have 300GB of physical disk space. If all the guests need 100% of their 100GB disk space then you will have a problem. If you use over allocation of disk space you will need to monitor the physical disk usage very carefully.
There is another problem with sparse disk formats, they don’t automatically shrink. Let’s say you fill 100GB of a sparse disk (we know this will roughly consume 100GB of physical disk space) and then delete some files so that you are only using 50GB. The physical disk space used should be 50GB, right? Wrong. Because the disk image doesn’t shrink, it will always be 100GB on the file system even if the guest is now using less. The below steps will detail how to get round this issue. Continue reading “Reclaim disk space from a sparse image file qcow2/ vmdk” »
In this guide we will go over creating a Proxmox KVM Template from a Cloud Image. This same process will work for any Cloud-Init Openstack based image type you can find online.
Having done a number of these for our Proxmox based VPS service I wanted to post up a guide to help anyone else looking to do the same thing.
My workflow for customizing one of those for use with Proxmox with cloud-init deployment from WHMCS and root login is below. Once you setup one template you can rapidly reinstall new containers and test stuff.
If not installed already installed you will need libguestfs-tools :
apt-get install libguestfs-tools
To edit the image before importing. We will use virt-edit which is a part of libguestfs-tools. Continue reading “Proxmox Cloud-Init OS template creation” »
Download the Win-Virtio Driver and load it on VM CDRom Drive. Download can be found here:
Now install the Virtio Balloon driver AND the Balloon service in the guest as follows:
- Open Device Manager and see if there is an unknown PCI device. If so, right click it and install the driver manually from D:\Balloon\2K16\amd64 (or 2k12, 2k8, etc)
- Now copy the entire amd64 folder into C:\Program Files\ (NOT x86) and rename it “Balloon”. So, now you have the amd64 folder from the disc copied as C:\Program Files\Balloon
- Open an Administrative Command Prompt and cd to C:\Program Files\Balloon
- Run this command:
Continue reading “Fixing Slow Windows VM boot on Proxmox KVM with balloon driver” »
From the XenServer Command Line Interface (CLI), issue the following command:
Note: If you have more than one XenServer in the pool, you must issue the xe host-list command to list all the XenServer hosts and write down the Universally Unique Identifier (UUID) of the host that you added the new NIC, then issue command xe pif-list host-uuid=[uuid of the XenServer host]
The preceding command lists all the physical NICs of that XenServer. If you do not see the additional NIC, you must scan for new physical interface(s) on a XenServer and issue this command:
xe pif-scan host-uuid=[uuid of the XenServer host]
Press Enter. Continue reading “How to Add Additional Physical NICs to XenServer” »
XCP-NG + Xen Orchestra Community Edition = a powerful 100% free virtualization environment and backup solution. I’m writing this to provide hand holding for those interested in XCP-NG but intimidated by the required command line setup to get Xen Orchestra Community Edition (XOCE) working.
The installation and update scripts for Xen Orchestra were written by DustinB3403; I’m using information from a few different sources to make an easy to follow guide.
For the purposes of this guide I’ll presume you already have XCP-NG installed and that XOCE will be running as a VM on XCP-NG. I’ll also assume you already have XCP-NG Center installed on a Windows OS. You can download XCP-NG Center at https://github.com/xcp-ng/xenadmin/releases.
*Updated 08-16-19 with TOML instructions for HTTPS. Thanks again to SloopDog for posting the HTTPS instructions.
Step 1: Download Linux ISO
I used Ubuntu Server 18.04 LTS (http://releases.ubuntu.com/18.04/). If you’re not comfortable with Linux I suggest you do the same so you can use the same commands without modification. Otherwise, feel free to use your own flavor. Download the Linux ISO and save it in a shared windows folder. Continue reading “Setup Xen Orchestra (XO) Community Edition” »
To update the present cluster host proxmox following files need to be updated:
/etc/pve/corosync.conf (only on one node necessary)
However, corosync.conf needs special way to edit the file!
Editing the corosync.conf file is not always very straightforward. There are two on each cluster node, one in /etc/pve/corosync.conf and the other in /etc/corosync/corosync.conf. Editing the one in our cluster file system will propagate the changes to the local one, but not vice versa. The configuration will get updated automatically as soon as the file changes. This means changes which can be integrated in a running corosync will take effect immediately. So you should always make a copy and edit that instead, to avoid triggering some unwanted changes by an in-between safe.
cp /etc/pve/corosync.conf /etc/pve/corosync.conf.new
Then open the config file with your favorite editor, nano and vim.tiny are preinstalled on any Proxmox VE node for example. Continue reading “Change cluster node IP in Proxmox” »
Prerequisite: Operating System and Software Versions
- Operating System: – Redhat 7.3
- Software: – libvirtd (libvirt) 2.0.0
Obtain Source Virtual Machine’s information
Before we begin cloning any virtual machine we first need to obtain some basic information about it. The absolute minimum information required about the source virtual machine we are about to clone would be its name and number of disk in use. To get virtual machines name run:
# virsh list
Id Name State
1 server1.local running
Next, we may would like to know the number of disk our source virtual machines is using as well as its location. The information about disks location is optional as it only provides us with a hint on where to store new clone disk files for the sake of consistency: # virsh dumpxml server1.local | grep "source file"
From the above output we can see that our original virtual machine has three disks stored in location /var/lib/libvirt/images/. Continue reading “Clone KVM-based Virtual Machines on Redhat / CentOS Linux” »