The task was simple: two computers (notebooks). One – we call it A – with a working operating system (Xubuntu) and a new one – we call it B – without operating system. This is how I proceeded:
- Create bootable flash drive with in my case Arch-Linux
- In the Arch-Linux boot loader, press [TAB] and add “copytoram” to the boot command to load the squashfs image into ram. I needed this because in this case I only had a flash drive at hand. If you have two, you don’t need this.
- List network devices:
- Assign a IP adress to computer A with:
ip address add <machine A ip adress> dev <ethernet device>
- To identify source disk, list all block devices with:
- Prepare the copy operation (do not execute yet!) with
dd if=/dev/<source block device> bs=32M status=progress | nc <machine B ip adress> <random port number>
- Boot machine B from the same or different flash drive
- Assign different IP adress
- Identify target device
- Prepare the receiving copy operation with
nc -l -p <same port number as A> | if of=/dev/<destination block device> bs=32M status=progress
- Execute the command on Machine B
- Then execute the command on Machine A
- Wait until the copying process is completed.
- Use at least the Sync command to synchronize corresponding file data in volatile storage and permanent storage
- Restart the machine, you are done
How it works/remarks
dd reads the source drive bit by bit into the normal output stream. The output stream is piped to netcat, which sends it over the network to a receiving netcat process (server with -l). Therefore the server must be started first. The server receives the bits and piped them back to dd, which writes them to the target on machine B.
Maybe this is not the best and/or most efficient way, but transfer speed in my case of 75MB/s (poor performance on screenshots is from a setup with two vm’s) is in IHMO very good for this simple setup.
Thanks to pmenke for his support.
Last week I noticed that the Single Sign-On (SSO) for the vSphere Client (Flex and HTML5) no longer works in my Firefox. Normally, the VMware Enhanced Authentication Plugin toolbar disappears at the bottom and you can enable the “Using Windows Session Authentication” option, but the checkbox remains unchecked. Reinstalling the VMware Enhanced Authentication plugin, updating the vCenter Server and reinstalling the plugin does not work.
Then I open a ticket at Vmware Support. Hours and some technology later, we had no idea what was going on. But, we find out that the local web server at https://vmware-plugin:8094/ (used by the SSO) displays the following error message in Firefox:
It looks like a problem with the Enhanced Authentication Plugin certificate. This is provided by the plugin. It creates a local web server to communicate with the web page. The VMware support team then created the certificate manually, but the error still occurred – even with IE and Edge.
Then I tried it with a fresh portable Firefox and it worked. In my installed Firefox I removed certificate exceptions for the normal host from the vCenter and vmware-plugin. I also – and most importantly – remove the certificate from the vCenter host and the vmware plugin from the certification authorities in Firefox. Reload the page and it’s working again.
After upgrading to vSphere 6.7, a PowerCLI script aborts with this error message:
The vCenter Server is unable to decrypt passwords stored in the customization specification.
To resolve the issue, retype the password in the VMcustomization specifications (under Policies and Profiles). Edit the customization specifications and retype the password under the following two preference points:
– Administrator password
– Workgroup or domain
If your vCenter 6.5 Enhanced Authentication Plugin not working, you just need to navigate to https://vmware-plugin:8094 and add a certificate exception.
~ # esxcli software vib list | grep Mel
net-mst 188.8.131.52-1OEM.5184.108.40.2062560 Mellanox VMwareCertified [...]
~ # esxcli software vib remove -n net-mst
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Removed: Mellanox_bootbank_net-mst_220.127.116.11-1OEM.518.104.22.1682560
Connect to VirtualCenter Server and enter credentials
Connect-VIServer -Server <Server>
Save the credentials to the credential store file (By default the credential store file is stored – encrypted – under the user profile directory)
New-VICredentialStoreItem -Host <Server> -User "<Username>" -Password "<Password>"