WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple
You are here: Home / Cloning vMA still not supported?

Cloning vMA still not supported?

02.01.2011 by William Lam // 5 Comments

Cloning and/or moving vMA is not supported by VMware, this has been the case since VIMA 1.0. If you take look at the "Known Issues" in the vMA release notes, you will see there is no still workaround. Users may find it useful to be able to clone vMA for backup purposes or to deploy another vMA without having to re-download or re-uploading .OVF from your local desktop/VMware's website.

If you ever tried to clone VIMA 1.0 and boot the system up, you will notice a warning message during the init process when vMA verifies the system's UUID. If it detects that it has been cloned, it will actually disable itself and makes the vMA components unusable until you reinitialize vMA using vimaclean. This is still the case with vMA 4.1, except the vMA components are no longer disabled when you perform a clone.

You will just see the warning message during the init process, but all functionality continues to work. Before the vMA specific components starts up, it makes a call to /opt/vmware/vma/bin/verifyuuid. It verifies the system UUID which you can extract using dmidecode, this is the same UUID found within the .vmx entry called uuid.bios. When you clone a VM, a new UUID will be generated which causes an issue when it tries to verify.

Prior to vMA 4.x, VIMA 1.0 stored all it's configurations within a set of XML files located in /etc/vmware/viconfig, these files held the config for both the vi-fastpass targets and vilogger config and policies. With the release of vMA 4.0, these configurations were migrated to a sqlite3 database which is stored in /var/opt/vmware/vMA/vMA.db. Within this database, it also stored as the old flat file configuration, the system UUID of vMA. This is what verifyuuid was checking against to see if it was cloned or moved, you can actually query the vMA DB to extract this information using a simple SQL query.

To resolve the warning message, you just need to update the new UUID in the vMA DB using an update statement.

Instead of manually typing all that out, I actually created a very simple script that queries for the current system UUID and then updates the vMA DB with the correct UUID. Here is a sample execution:

Download: updatevMAUUID.sh

I suspect that VMware may have allowed cloning of vMA, but just did not update their release notes? The only thing you have to do is manually fix the UUID if you do not want to see the warning message. If you would like to fix this for VIMA 1.0, you will need to do the same thing except you need to modify the UUID found in /etc/vmware/viconfig/viconfig.xml and restart vMA for the changes to effect.

More from my site

  • How to backup/restore vMA's config + vi-fastpass DB
  • Cool Docker Container for VMware Utilities
  • Free Linux & Windows Syslog Alternatives to depercated vi-logger in vMA 5
  • How to install Ruby vSphere Console on vMA
  • ESXi Lockdown mode does not play nice with vMA
Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Categories // Uncategorized Tags // sqlite3, vma, vMA.db

Comments

  1. ramd says

    01/03/2012 at 6:52 pm

    Here are some additional steps by which you reset the vMA (version 4.1) to first boot state. You can use this approach to install additional software/agents on the vMA, and then make this modified vMA as a ready-to-deploy appliance. i use this approach to create a vMA with HP operations agent pre-installed during the 'first boot' itself.

    1. boot up the vMA ovf in the normal mechanism, provide IP address if required or feel free to use DHCP or no networking.

    2. as root, install the additional software - such as HP Operations Agent.

    3. continue logged in as root - then reset the appliance back to first reboot context - this is done by a hack. create the folder '/opt/vmware/vma/VMWARE_VMA_FB_REQUIRED'. presence of this folder ensures that on next reboot, the initial set of installation questions are raised.

    4. remove old certificate files (rm -f /etc/vmware/ssl/rui.*)

    5. remove settings from /etc/sysconfig/network file.

    6. if particular about the history not showing these hacks :), clean up history file

    7. modify vmware-vma init script (it is present under the rc scripts folder) to call the updatevMAUUID.sh script that William provides above.

    8. save the vMA as an appliance with the above config changes done. you can use ovftool for this or you can do this via VI client UI.

    Reply
  2. Anonymous says

    07/25/2012 at 5:41 pm

    same steps for vMA version 5?

    cause I can't do Step 5 or 7

    Reply
  3. Anonymous says

    11/19/2012 at 4:10 pm

    Is the above download link now working..?

    Reply
    • William says

      11/19/2012 at 6:05 pm

      Download link has been fixed, I had moved providers awhile back and didn't get to retrofit all existing links. Thanks

      Reply
    • Anonymous says

      03/25/2013 at 3:55 pm

      I tried your script but unfortunately it won't work on my vMA 4.1 VM.

      If I do all the above desrcibed steps by hand, all works well.

      Reply

Thanks for the comment! Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Support

Recent

  • A first look at the new vSphere+ & vSAN+ Cloud Service 07/01/2022
  • Quick Tip - Prepare VMware Photon OS for use with vSphere Guest OS Customization and cloud-init 06/29/2022
  • Using the new vSphere Guest OS Customization with cloud-init in vSphere 7.0 Update 3 06/27/2022
  • How to forcefully disconnect a vSphere VM Console session? 06/24/2022
  • Quick Tip - Using ESXi Scripted Installation (kickstart) to configure IPv6 networking 06/21/2022

Advertisment

Copyright WilliamLam.com © 2022