VirtuaBox is gone to version 5 and it's VMDK support is still crap.
It's my mistake, when I was creating the last VM I should have paid attention, I was sleepcreatingVMs and accidentally created the VM with a VMDK disk. WRONNNGGG!!! I needed an other 100G on the VM, and then I started banging my head on my desk again.
Luckily it's just tedious stuff. Our good friend qemu-utils package comes to our rescue again, so it's just a waste of space and time. We got to convert it to a better supported format, and then do the work:
time qemu-img convert -f vmdk -O vdi /fullpathtodisk.vmdk /fullpathtodisk.vdi
VBoxManage modifymedium disk /fullpathtodisk.vdi --resize 200000
Note that you got to count the zeros correctly. I typed 20000 and it gave me the unhelpful message:
0%...
Progress state: VBOX_E_NOT_SUPPORTED
VBoxManage: error: Resize medium operation for this format is not implemented yet!
Well, yes, resizing to smaller sizes is not implemented, but at least be more helpful to a sleep-reprived sysadmin. I was telling it to resize it to 20GB, not 200GB! I scratched my head, googled the error, had some coffee, thought about it for a while, came back, tried the vmdk again, wasted more time, only after that I counted the zeros and cursed at myself loudly.
It would be nice if VirtualBox, after all these years, would support mnemonics like MB, GB...
Syntax error: --resize: RTGetOpt: Command line option has argument with bad format.
Darnit!!!
Wednesday, December 16, 2015
Thursday, July 30, 2015
Embrace the dark side:SELinux
It's annoying.
It works.
If you've got a home directory somewhere else than /home, you might have some funny business. It usually shows up as "/usr/bin/xauth: timeout in locking authority file .Xauthority". Some other security related things stop working too.
This is how all that goes away.
Edit /etc/selinux/semanage.conf
usepassword=True
yum install policycoreutils-python
Clone the context from the standard home directory layout into the new home directory, my users are under /test, i.e., /test/user
semanage fcontext -a -e /home /test
restorecon -R /test
Job done, everything works as intended.
It works.
If you've got a home directory somewhere else than /home, you might have some funny business. It usually shows up as "/usr/bin/xauth: timeout in locking authority file .Xauthority". Some other security related things stop working too.
This is how all that goes away.
Edit /etc/selinux/semanage.conf
usepassword=True
yum install policycoreutils-python
Clone the context from the standard home directory layout into the new home directory, my users are under /test, i.e., /test/user
semanage fcontext -a -e /home /test
restorecon -R /test
Job done, everything works as intended.
Monday, July 06, 2015
VirtualBox & VERR_NOT_SUPPORTER with VMDK
So, you've got your 2GB-split VMDK and you want to import to your local Virtualbox and it's not working at all:
hakan@hakan-laptop:16:29:36:~/snafu$ VBoxManage showhdinfo demo.vmdk
VBoxManage: error: Could not get the storage format of the medium '/home/hakan/snafu/demo.vmdk' (VERR_NOT_SUPPORTED)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component Medium, interface IMedium, callee nsISupports
The version of Virtualbox on Ubuntu 15.04 is not capable of handling this format at the moment. Install Qemu-tools and do the conversion there and stop wasting time:
time qemu-img convert -f vmdk -O vdi demo.vmdk demo.vdi
Now that's better:
hakan@hakan-laptop:16:37:34:~/snafu$ VBoxManage showhdinfo demo.vdi
UUID: 24142e20-6273-499a-8bbf-2ae8e27c1cef
Parent UUID: base
State: created
Type: normal (base)
Location: /home/hakan/snafu/demo.vdi
Storage format: VDI
Format variant: dynamic default
Capacity: 20480 MBytes
Size on disk: 19816 MBytes
hakan@hakan-laptop:16:29:36:~/snafu$ VBoxManage showhdinfo demo.vmdk
VBoxManage: error: Could not get the storage format of the medium '/home/hakan/snafu/demo.vmdk' (VERR_NOT_SUPPORTED)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component Medium, interface IMedium, callee nsISupports
The version of Virtualbox on Ubuntu 15.04 is not capable of handling this format at the moment. Install Qemu-tools and do the conversion there and stop wasting time:
time qemu-img convert -f vmdk -O vdi demo.vmdk demo.vdi
Now that's better:
hakan@hakan-laptop:16:37:34:~/snafu$ VBoxManage showhdinfo demo.vdi
UUID: 24142e20-6273-499a-8bbf-2ae8e27c1cef
Parent UUID: base
State: created
Type: normal (base)
Location: /home/hakan/snafu/demo.vdi
Storage format: VDI
Format variant: dynamic default
Capacity: 20480 MBytes
Size on disk: 19816 MBytes
Tuesday, June 09, 2015
LoadRunner, SSH and Remote Agents
I'm running LoadRunner 11.52, RTE with SSH and some remote agent servers to run the load.
And it won't work. The scripts work fine with Vugen but won't work with the Controller.
The reason is this:
[HKEY_CURRENT_USER\Software\Ericom Software\SSH\SshHostKeys]
"rsa2@22:blablabla"="0x25,randomstringforsshkey"
This little piece of crap needs to be in the registry before Ericom - which LoadRunner uses for your SSH connection can connect. It doesn't use Plink, it doesn't use any clever stuff. And if you're using a remote agent with a local system account, whatever I tried - IT DOES NOT WORK!
There are people who claim if you convert this into a HKEY_LOCAL_MACHINE registry entry, it should work, it did not in my case.
In the end I threw up the towel, asked the LR agent to be run as a named user, ran the script ONCE with that user using Vugen - this loaded the key into the registry - and then everything worked from the Controller.
The key is loaded to the registry when you connect to it first time - it pops up a window and asks if you are happy with the fingerprint and want to save it - which you answer by clicking to the "YESSSS" button", unless you're an idiot.
Guess what. LoadRunner is not clever enough to auto-accept this key if you are running this inside the controller. It still prompts for it. You just never see the prompt. It's hanging there, in the ether, waiting for a ghost to find it and try to touch with its cotton rags and see if it can activate the YESSSSSSSS button, forever....
Of course, this is very annoying. For every different server and every different controller you want to use, you have to go through this.
You can have short-cuts. You can do it in one server, then save the registry keys and import into the servers but still, you got to use a named user, just don't bother with the local system account, it's just not worth the stress it's going to cause you.
Probably will apply to 12 as well.
And it won't work. The scripts work fine with Vugen but won't work with the Controller.
The reason is this:
[HKEY_CURRENT_USER\Software\Ericom Software\SSH\SshHostKeys]
"rsa2@22:blablabla"="0x25,randomstringforsshkey"
This little piece of crap needs to be in the registry before Ericom - which LoadRunner uses for your SSH connection can connect. It doesn't use Plink, it doesn't use any clever stuff. And if you're using a remote agent with a local system account, whatever I tried - IT DOES NOT WORK!
There are people who claim if you convert this into a HKEY_LOCAL_MACHINE registry entry, it should work, it did not in my case.
In the end I threw up the towel, asked the LR agent to be run as a named user, ran the script ONCE with that user using Vugen - this loaded the key into the registry - and then everything worked from the Controller.
The key is loaded to the registry when you connect to it first time - it pops up a window and asks if you are happy with the fingerprint and want to save it - which you answer by clicking to the "YESSSS" button", unless you're an idiot.
Guess what. LoadRunner is not clever enough to auto-accept this key if you are running this inside the controller. It still prompts for it. You just never see the prompt. It's hanging there, in the ether, waiting for a ghost to find it and try to touch with its cotton rags and see if it can activate the YESSSSSSSS button, forever....
Of course, this is very annoying. For every different server and every different controller you want to use, you have to go through this.
You can have short-cuts. You can do it in one server, then save the registry keys and import into the servers but still, you got to use a named user, just don't bother with the local system account, it's just not worth the stress it's going to cause you.
Probably will apply to 12 as well.
Wednesday, May 20, 2015
Why you shouldn't hate and disable NetworkManager anymore
James Hogarth has posted a nice mail to the CentOS mailing list on why we shouldn't hate NetworkManager anymore and linked to a very good article on the nmcli. One should bookmark this for future reference.
I used to loathe things that make life easy by trying to "wrap things up" since they make edge cases significantly harder to resolve (and what I mean by edge cases is, servers) but I give up. Life is too short arguing about such things on and on. Eventually things get resolved and people move on I guess and I got to accept NetworkManager instead of fighting against it doing stupid things against my will. Hopefully enough things have been fixed so that it's now sane enough.
I am still against distributions doing "their own things" on such fundamental levels, I accept that I do not matter in the big scheme of things.
IMHO, such basic operations like networking should be standardized across platforms so that we can achieve such operations w/o worrying about such stupid things. I should expect to have certain things always in my service...
Oh well..
I used to loathe things that make life easy by trying to "wrap things up" since they make edge cases significantly harder to resolve (and what I mean by edge cases is, servers) but I give up. Life is too short arguing about such things on and on. Eventually things get resolved and people move on I guess and I got to accept NetworkManager instead of fighting against it doing stupid things against my will. Hopefully enough things have been fixed so that it's now sane enough.
I am still against distributions doing "their own things" on such fundamental levels, I accept that I do not matter in the big scheme of things.
IMHO, such basic operations like networking should be standardized across platforms so that we can achieve such operations w/o worrying about such stupid things. I should expect to have certain things always in my service...
Oh well..
Sunday, January 18, 2015
Subscribe to:
Posts (Atom)