qemu-img convert -O raw diskimage.qcow diskimage.raw
Posts Tagged ‘Virtualization’
qemu-img convert -O raw diskimage.qcow diskimage.raw
After doing a host name change on a Zimbra appliance the domain was locked. Error messages included:
This account is currently in maintenance mode
The domain is temporarily locked by the server. You will not be able to make any changes to the domain until the internal lock is removed.
ERROR: service.PERM_DENIED (permission denied: can not access domain, domain is in shutdown status)
Unfotunately, it’s not possible to change the status in the Admin FE. You’re going to have to either use ldapmodify, or if you’re ldap-squeamish like me phpldapadmin.
I went through maybe two dozen bellyaching forum threads complaining about this problem and how no one has come up with a solution until I found this article at http://www.zoobey.com/index.php/resources/all-articles-list/430-zimbra-rename-domain-fix:
You may have to run this multiple times for every 1000 users because of a java/zimbra bug. After it you are left with both domains in shutdown mode and having a rename status. These are store in openldap. Below is method to fix it. This is for zimbra 6.0+ – I did it on 7.1.3. BE REALLY CAREFUL AND BACKUP AS YOU CAN MESS STUFF UP Easily.
First, backup your entire /opt/zimbra is recommended and at least your ldap
su – zimbra
download phpldapadmin (you can do this using ldapmodify as well or any other ldap tool)
$config->custom->appearance['friendly_attrs'] = array(
‘facsimileTelephoneNumber’ => ‘Fax’,
‘gid’ => ‘Group’,
‘mail’ => ‘Email’,
‘telephoneNumber’ => ‘Telephone’,
‘uid’ => ‘User Name’,
‘userPassword’ => ‘Password’
$servers = new Datastore();
$servers->setValue(‘server’,'name’,'My LDAP Server’);
$servers->setValue(‘server’,'host’,'YOUR HOST IP’);
Using PHPLDAPADMIN do the following
Search Base DN
Click on domain, make changes searching for
zimbraDomainRenameInfo – set to “active” no quotes
zimbraDomainStatus – delete all text from box
zimbraMailStatus – enabled
zmprov md YOUR_DOMAIN_NAME zimbraMailStatus enabled
update verify it updated as it sometimes will prompt you “Click Update Object” button at bottom of object
as zimbra user
zmprov md YOUR_NEWLY_RENAMED_DOMAIN_NAME zimbraMailStatus enabled
If you want to remove old domain
zmprov dd THE_OLD_DOMAIN
You can obtain your LDAP password by running:
$ zmlocalconfig -s | grep zimbra_ldap_password zimbra_ldap_password = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
I found the config.php part uneccecary since the default installation of phpldapadmin supplies a form for directly logging in.
Full-disk images – that is to say a file containing an MBR, partition table and one or more partitions – are a pain in the arse to scale. Conventional wisdom tells us we should be able to do this with losetup and parted, or less gracefully with (c)fdisk but I’ve never had anything but trouble. In the end, it tends to be much easier to move the contents of the image to a file-system-only image and externalize the kernel since we’ll no longer have the benefit of a bootloader.
Let’s create and mount our new image to start off:
# dd if=/dev/zero of=newimage.img bs=1M count=4000 # mke2fs -j newimage.img # mkdir /mnt/rawroot # mount -o loop newimage.img /mnt/rawroot
Now we’re going to mount our old full disk image’s partition. Use kpartx -l to determine what node the partition will be mapped to:
# kpartx -l oldimage.hdd loop34p1 : 0 4190208 /dev/loop34 2048
This tells us the full disk will be on /dev/loop34 and the partition itself will be on /dev/mapper/loop34p1.
# kpartx -a oldimage.hdd # mkdir /mnt/rawroot2 # mount /dev/mapper/loop34p1 /mnt/rawroot2
Alternatively, we can let lomount do the work for us:
# lomount -diskimage oldimage.hdd -partition 1 /mnt/rawroot2
Now we’ll copy the files in the old file system to the new image exactly as they stand:
# cd /mnt/ # cp -ax rawroot2/* rawroot/
It’s important that we use the -a flag or we may end up breaking file system links and will almost certainly fill up the new image when we hit device nodes like /dev/zero, /dev/urandom and so on.
Edit the /etc/fstab in the new image and ensure it reflects the new configuration; / will probably come from /dev/xvda1. Old references by LABEL or UUID will no longer be valid.
Since we’ll be forgoing a bootloader it is necessary to externalize the kernel and initrd images:
# cp rawroot2/boot/vmlinuz-3.2.0-29-generic /xen/myvm/ # cp rawroot2/boot/initrd.img-3.2.0-29-generic /xen/myvm/
Now we can unmount both images:
# umount rawroot # umount rawroot2
If you used kpartx instead of lomount you should remove the old image from the loop device:
# kpartx -d oldimage.hdd
Now alter the Xen configuration file to reference the externalized kernel and initrd:
kernel = "/xen/myvm/vmlinuz-3.2.0-29-generic" initrd = "/xen/myvm/initrd.img-3.2.0-29-generic"
Remove or comment your reference to pygrub and boot the machine. If everything went well you will be looking at a login prompt shortly.
Please see my article on resizing file system images for details on how to grow the new image.
apache attack ClearOS disk dns documentary dos economics emerge encryption file system filesystem firewall Gentoo init iptables iran kernel linux media military mysql netfilter network Networking php politics portage power propaganda ram religion router script search Security server ssh united states Virtualization vm war web xen zimbra