Accidentally added a 300GB virtual machine to the proxmox node, how now to remove this space? is it possible to use the command
qemu-img resize /media/storage2/images/101/vm-101-disk-0.raw -299G
so as not to lose all the data??
enter image description here
Related
I am using proxmox and created a virtual machine yesterday. Today, I noticed that there is hardly any memory left on my root nodes /dev/mapper disk, which causes the VM to stop. I found out that there is an image file (extension .qcow2) in the directory /var/lib/vz/images, which belongs to the newly created VM, which consumes quite a lot memory.
I know that images can be used to install operating systems from and I asked myself if this image file is a necessary component for the VM to work or if the image file is only created as a kind of backup. If it is a backup file, I could save it on another disk to solve my problem.
Thanks for your help.
It's your virtual machine disk, you cannot just remove it. You can create VM disk with "Thin provision" checked in Storage configuration on hypervisor, it will consume only what you use, not allocate all space at once. Use Clonezilla or dd to clone all data to new disk.
Problem:
Lets say i have a VM with three storage LUNS attached to it through SCSI
VMFS stores each drive as a individual VMDK files.
C:(one_c.vmdk)
D:(two_d.vmdk)
F:(three_f.vmdk)
In ESX host these there vmdk files are stored in /container_name/vm_name/
Is there any way of mapping,given (disk serial number or disk id) and vmdk files location can we figure out to which vmdk file this Drive maps to?
Note: i have gone through this link
VMWare VMDK mapping to Windows Drive Letters. But not that keen to do using scripts
You can use ReconfigVM_Task for the virtual machine that has those disks attached.
You need to pass virtualMachineConfigSpec which, as the name implies, specifies the virtual machine's configuration. Under it you will find virtualDeviceConfigSpec
What you want to do is:
Fetch the existing virtualMachineConfigSpec of your VM
Locate the relevant virtualDeviceConfigSpec for your disk
Edit the backing info of that disk
Change the file name to the correct path (starting from the datastore)
Unset the fileOperation (to avoid creating a new disk there)
Execute ReconfigVM_Task on the VM with the updated spec
Please consult the doc for more specific instructions
https://www.vmware.com/support/developer/converter-sdk/conv50_apireference/vim.VirtualMachine.html#reconfigure
Today, I was trying to get on my Kali Linux virtual machine to just do a basic vulnerability check on a VPS I own. I have my Kali Linux Virtual Disk Image (VDI) saved on a USB external drive, so I plugged that in, fired up Virtual Box, but I got an error when I went to start it. It would appear that the drive letter for this drive has changed from F: to E:. Thus, VirtualBox could not retrieve the VDI from F:\Kali Linux VM\.
Trying to troubleshoot this on my own, I decided to open up the VM settings, remove the SATA Controller VDI that was registered on the F: drive, and then add the VDI from the E: drive (same VDI, just a difference in drive letter). That, however, did not go as smoothly as planned. I was able to remove incorrect VDI path without any problems, but when I tried to add the VDI on the proper path, I got the following error:
Cannot register the hard disk 'E:\Kali Linux VM\Kali Linux.vdi' {6b214e73-ae38-427b-90f8-995c7dd4211c} because a hard disk 'F:\Kali Linux VM\Kali Linux.vdi' with UUID {6b214e73-ae38-427b-90f8-995c7dd4211c} already exists.
Result Code:
E_INVALIDARG (0x80070057)
Component:
VirtualBoxWrap
Interface:
IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945}
Callee RC:
VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
It looks like I cannot add the VDI back to the VM because it is identical to the VDI I removed.
Has anyone else encountered a problem like this? And does anyone have a fix for this so I don't lose all the data on that VM?
Thank you all in advance.
Note: I know this isn't a programming question, so this may be the wrong Stack Exchange. Please let me know if this would be better suited under a different Stack Exchange site.
Open Oracle VM VirtuaBox Manager. Now go to
File > Virtual Media manager
Under Hard disks, select Kali Linux.vdi. Right click and remove it.
NOTE: If remove is disabled. Click release first. Then right click and remove.
Now add the VDI Kali Linux.vdi again.
I have a Jenkins server running on OpenShift Origin 1.1
The pod is using persistent storage using NFS. We have a pv of 3GB and a pvc on this volume. It's bound and Jenkins is using it. But when we perform:
sudo du -sh /folder we see our folder is 15GB. So we want to resize our persistent volume while it's still in use. How can we perform this?
EDIT: or is the best way to recreate the pv and pvc on the same folder as before. So all the data will remain in that folder?
This will be a manual process and is entirely dependent on the storage provider and the filesystem with which the volume is formatted.
Suppose you have NFS that has enough space say 15 Gb and you have pv only of 3Gb then you can simply edit the pv to increase the size.
"oc edit pv [name]" works and you can edit the size of the volume.
I am using a public dataset snapshot in Amazon ec2. The data in the snapshot is roughly 150GB and the snapshot itself is 180GB. I knew that by performing operations on the dataset I would need more than 30GB of free memory so I put the snapshot in a 300GB volume. When I look at my stats though (unfortunately as a process is running, so I think I am about to run out of room), it appears that the snapshot is still limited to 180 GB.
Is there a way to expand its size to the size of the volume without losing my work?
Is there a possibility that the snapshot is actually continuous with another drive (e.g. /dev/sdb)? (A girl can hope, right?)
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.9G 1.1G 8.4G 11% /
none 34G 120K 34G 1% /dev
none 35G 0 35G 0% /dev/shm
none 35G 56K 35G 1% /var/run
none 35G 0 35G 0% /var/lock
none 35G 0 35G 0% /lib/init/rw
/dev/sdb 827G 201M 785G 1% /mnt
/dev/sdf 174G 162G 2.6G 99% /var/lib/couchdb/0.10.0
My instance is running Ubuntu 10.
Is there a way to expand its size to the size of the volume without
losing my work?
That depends on whether you can live with a few minutes downtime for the computation, i.e. whether stopping the instance (hence the computation process) is a problem or not - Eric Hammond has written a detailed article about Resizing the Root Disk on a Running EBS Boot EC2 Instance, which addresses a different but pretty related problem:
[...] what if you have an EC2 instance already running and you need to
increase the size of its root disk without running a different
instance?
As long as you are ok with a little down time on the EC2 instance (few
minutes), it is possible to change out the root EBS volume with a
larger copy, without needing to start a new instance.
You have already done most of the steps he describes and created a new 300GB volume from the 180GB snapshot, but apparently you have missed the last required step indeed, namely resizing the file system on the volume - here are the instructions from Eric's article:
Connect to the instance with ssh (not shown) and resize the root file
system to fill the new EBS volume. This step is done automatically at
boot time on modern Ubuntu AMIs:
# ext3 root file system (most common)
sudo resize2fs /dev/sda1
#(OR)
sudo resize2fs /dev/xvda1
# XFS root file system (less common):
sudo apt-get update && sudo apt-get install -y xfsprogs
sudo xfs_growfs /
So the details depend on the file system in use on that volume, but there should be a respective resize command available for all but the most esoteric or outdated ones, none of which I'd expect in a regular Ubuntu 10 installation.
Good luck!
Appendix
Is there a possibility that the snapshot is actually continuous with
another drive (e.g. /dev/sdb)?
Not just like that, this would require a RAID setup of sorts, which is unlikely to be available on a stock Ubuntu 10, except if somebody provided you with a respectively customized AMI. The size of /dev/sdb does actually hint towards this being your Amazon EC2 Instance Storage:
When an instance is created from an Amazon Machine Image (AMI), in
most cases it comes with a preconfigured block of pre-attached disk
storage. Within this document, it is referred to as an instance store;
it is also known as an ephemeral store. An instance store provides
temporary block-level storage for Amazon EC2 instances. The data on
the instance store volumes persists only during the life of the
associated Amazon EC2 instance. The amount of this storage ranges from
160GiB to up to 3.3TiB and varies by Amazon EC2 instance type. [...] [emphasis mine]
Given this storage is not persisted on instance termination (in contrast to the EBS storage we all got used to enjoy - the different behavior is detailed in Root Device Storage), it should be treated with respective care (i.e. never store something on instance storage you couldn't afford to loose).