Hello.
El 14/03/13 12:45, Thinker Rix escribió:
Thougths & Questions:
==================================
1. Server A in DMZ:
My idea is that I backup the virtual disk file of the current VM to an
USB hard disk, then delete everything and install Proxmox VE on the bare
metal. After this I copy the virtual disk file of the VM back to Proxmox
by reconnecting the USB hard disk and make Proxmox VE run this file as a VM
a) Do you see any obstacles I have to take care of?
Yes.
In case something (anything) goes wrong, you will burn your ships and be
unable to do a graceful rollback.
I would suggest you to get a new hard disk and use it to install
Proxmox, without deleting or overwriting anything on the disk that holds
you current KVM installation. In the worst case, you will have to switch
the disks back and be able to make another attempt later.
Otherwise, you would have to blow dust form your Disaster Recovery Plan,
do you have one?
b) Is it possible to connect the USB hard disk for restoring the virtual
disk file in Proxmox? I have a normal Debian under the hood, isn't it,
so I should be able to just mount the USB disk and copy the file to some
place that Proxmox expects such virtual disk files, right? What place is
that and what would be the procedure be to make Proxmox use this virtual
disk file as a VM afterwords?
Proxmox host is expected to recognize your USB disk as any other Debian
system. You will need to decide a mount point, mount it, and perform any
file operations manually.
After a default installation of Proxmox, the KVM virtual disk images are
stored under /var/lib/vz/images/${VMID}/ .
What I have done successfully, is to create a "empty" VM with the
desired name and configuration on the target host, make sure it's turned
off, and overwrite the files within /var/lib/vz/images/${VMID}/ with the
disk images from my backup. Make sure the filenames and permissions are
right. Check the virtual disk image format (RAW by default).
As you move from another KVM, I would expect this procedure to "just
work". In case you where moving form another type of hypervisor or
baremetal, the contents of the image would probably need to be modified.
c) Do you see any problems concerning the "specs"of the VM and
compatibility with Proxmox VE?
Should not be a problem at all for a Linux VM.
2. Server in LAN:
My idea is to make a full disk backup of the current partition 1 (OS and
server services) with Clonezilla and an rsync-copy of the data on
partiton 2, both to an external USB hard disk. Then I delete everything
and install Proxmox VE on the bare metal. Finally I create a VM, run
clonezilla again and restore partition 1 and the user data of partition
2 by reconnecting the USB-hard disk.
a) Do you see any obstacles I have to take care of?
Same considerations as in case of server A.
Another thought, don't attempt a simultaneous migration. Do first one,
and begin the second only after you finish and arm yourself with the
experience.
Since Proxmox KVM can use a raw image, you may use dd instead of
Clonezilla or rsync-copy. Note that you will have to go around the
change of the partitioning schema.
Consider this example:
1. Create the target raw disk image of the desired size on USB drive, dd
if=/dev/zero of=file.img.
2. Partition your disk images, pretty plain: fdisk file.img
3. Map your disk image partitions to a block device: kpartx -a file.img
(look for the mapped partitions under /dev/mapper).
4. If the sizes allows it, dd data from your actual partition to the
mapped partition. If you change the sizes, it would probably be a better
idea to format the target, mount it, and copy files via "cp -a" to it.
5. Unmap your disk image partitions, so you can take the file elsewhere
or remove the USB: kpartx -d file.img
6. Repeat with each desired partition.
Note that you will have to do something different with your boot drive.
A simple dd of the MBR might work, and might not. A "dump" approach
would be not to bother with the boot loader at all, use a rescue LiveCD
(as ISO image) on the first boot of your VM and apply a standard boot
loader recovery technique (mount, chroot, etc).
b) How about the user data partition? Should I place the data into the
VM I just created, too, or would it be advisable to create some other
data drive for that?
I use a separate virtual disk for separate things, even if they live on
the same VM. This is regardless of the hypervisor used.
For example, in case of a server with user data (homedirs) and service
data it would need 3 virtual disks: mounted, let's say, as /, /home and
/srv.
Note that the VM will see the disks as separated block devices, so it's
a good idea to partition them before use.
Would it be possible to create some kind of "shared
data volume" (on this server, not in the network!) for multiple VMs of
this server to be able to access the data?
Shared between who, different VM's on the same host? That is already so,
/var/lib/vz is shared between VMs and OpenVZ containers.
Not sure if it's possible to attach the same disk image to several VM's
simultaneously, probably not. You can use NFS between two VM's, and
connect them via private network bridge, with no physical interfaces
attached.
Or what do you suggest on how
to handle the Samba Server and it's user data best?
Separate virtual disk for data, no evident need for anything more fancy.
c) Can I make this partition to be growing instead of the necessity to
define a fixed size upfront?
You can always resize an existing virtual disk. Note that after that you
will need to resize the partition within VM, and resize the FS.
http://pve.proxmox.com/wiki/Resizing_disks
Other option would be to define is as a sparse file from the beginning,
but that would complicate the migration process.
--
Alexandre Kouznetsov
_______________________________________________
pve-user mailing list
[email protected]
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
