Search This Blog

Tuesday, October 1, 2019

Improve user experience using QEMU/KVM with Windows guest

A lot of sysadmins, SRE o wherever you want to call us, using native Linux in our laptops have the need to use virtual machines running Windows (some support, pentesting tasks, etc), if you are passionate about running periodic updates by now you figure out the main problem of this, if not, you will; the main problem is that on every kernel upgrade, you will lose the modules of VMware or VirtualBox, the best solution for this is to use QEMU/KVM, the K is for kernel so the support is embedded in the kernel, with this you will never lose support on your virtual machines, but there is a catch, even if you install virtIO drivers you will face issues like the screen does not resize, copy and paste from host to guest does not work, and is very sad to work that way.

So the solution: The SPICE project aims to provide a complete open-source solution for remote access to virtual machines in a seamless way so you can play videos, record audio, share USB devices, and share folders without complications.





SPICE could be divided into 4 different components: Protocol, Client, Server, and Guest. The protocol is the specification in the communication of the three other components; A client such as a remote viewer is responsible to send data and translate the data from the Virtual Machine (VM) so you can interact with it; The SPICE server is the library used by the hypervisor in order to share the VM under SPICE protocol; And finally, the Guest side is all the software that must be running in the VM in order to make SPICE fully functional, such as the QXL driver and SPICE VDAgent.





Just put in your virtual machine a channel spice and install the driver, the latest version could be found here.

Thursday, May 23, 2019

fake_pxe as pm_type in RHOSP13 (TripleO + OpenStack Queens)

So, in RHOSP13 fake_pxe is being deprecated to change in RHOSP14 for manual management, the problem is that is just in between the migration, so there is no a clean way to use fake_pxe in RHOSP13. Another change is in the installation of undercloud, the option enabled_drivers is now DEPRECATED and changed by enabled_hardware_types. What now, in order to be able to use fake_pxe as a pm_type first install the undercloud without the options enabled_drivers, only use enabled_hardware_types, and add at the end manual-management, like this:

... #enabled_drivers=pxe_drac,pxe_ilo,pxe_ipmitool enabled_hardware_types=redfish,ipmi,idrac,ilo,manual-management ...

After that just install the undercloud using the common way.

[stack@director01 ~]$ openstack undercloud install ... ############################################################################# Undercloud install complete. The file containing this installation's passwords is at /home/stack/undercloud-passwords.conf. There is also a stackrc file at /home/stack/stackrc. These files are needed to interact with the OpenStack services, and should be secured. ############################################################################# [stack@director01 ~]$

Next, change manually the ironic.conf file located in /etc/ironic/ironic.conf to enable the DEPRECATED option enabled_drivers and add fake as a new driver.

enabled_drivers=pxe_drac,pxe_ilo,pxe_ipmitool,fake enabled_hardware_types=redfish,ipmi,idrac,ilo,manual-management

And restart ironic-conductor service:

(undercloud) [stack@director01 ~]$ sudo systemctl restart openstack-ironic-conductor

check the drivers:

(undercloud) [stack@director01 ]$ openstack baremetal driver list +---------------------+------------------------+ | Supported driver(s) | Active host(s) | +---------------------+------------------------+ | idrac | director01 | | ilo | director01 | | ipmi | director01 | | manual-management | director01 | | pxe_drac | director01 | | pxe_ilo | director01 | | pxe_ipmitool | director01 | | redfish | director01 | +---------------------+------------------------+

Now can we add a instackenv.json file.

(undercloud) [stack@director01 ~]$ cat instackenv-controller01.json { "nodes":[ { "mac":["controller1_mac"], "name":"nuc-controller01", "arch":"x86_64", "capabilities":"profile:control,node:controller-0,boot_option:local", "pm_type":"fake" } ] }

If you don't do this or try to use manual-management pm_type at this moment you will get an error similar to this one:

(undercloud) [stack@director01 ~]$ openstack overcloud node import ~/instackenv-controller01.json Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: 6ce7871c-d9d0-448e-9b46-78ced387fa48 Waiting for messages on queue 'tripleo' with no timeout. No valid host was found. Reason: No conductor service registered which supports driver fake. (HTTP 400) Exception registering nodes: No valid host was found. Reason: No conductor service registered which supports driver fake. (HTTP 400)

Import the new node definition to ironic and run introspection:

(undercloud) [stack@director01 ~]$ openstack overcloud node import ~/instackenv-compute01.json Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: 434cfe01-740d-4d58-b504-6f291ab12823 Waiting for messages on queue 'tripleo' with no timeout. 1 node(s) successfully moved to the "manageable" state. Successfully registered node UUID 62ce7d2c-03ae-4c6e-8c4a-13e817f26fa3 (undercloud) [stack@director01 ~]$ (undercloud) [stack@director01 ~]$ openstack baremetal introspection start --wait nuc-controller01 Waiting for introspection to finish... +------------------+-------+ | UUID | Error | +------------------+-------+ | nuc-controller01 | None | +------------------+-------+

But as I said, the fake driver is not going to be supported in RHOSP14 so version 13, is in the middle of the migration and we can introspect the node using fake driver, but we are not going to be able to install it, if we tried so, we will get an error like this one:

(undercloud) [stack@director01 ~]$ openstack action execution output show a637a01a-5f66-48a0-9e25-96700240c17e { "result": "Invalid node data: unknown pm_type (ironic driver to use): manual" }

So in order to solve this we need to change the driver type directly in the database, first, find the password in ironic.conf file

(undercloud) [stack@director01 ~]$ grep mysql /etc/ironic/ironic.conf #mysql_engine = InnoDB connection=mysql+pymysql://ironic:38315b04050cd6ad074ae75855f7c4367299b61a@192.168.10.9/ironic # set this to no value. Example: mysql_sql_mode= (string #mysql_sql_mode = TRADITIONAL #mysql_enable_ndb = false

Then look for the drivers configured.

MariaDB [ironic]> select name,driver from nodes; +------------------+--------+ | name | driver | +------------------+--------+ | nuc-controller01 | fake | | nuc-compute01 | fake | | nuc-compute02 | fake | +------------------+--------+ 3 rows in set (0.00 sec) MariaDB [ironic]> update nodes set driver = "manual-management" where name = "nuc-controller01"; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [ironic]> update nodes set driver = "manual-management" where name = "nuc-compute01"; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [ironic]> update nodes set driver = "manual-management" where name = "nuc-compute02"; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [ironic]> select name,driver from nodes; +------------------+--------+ | name | driver | +------------------+--------+ | nuc-controller01 | manual-management | | nuc-compute01 | manual-management | | nuc-compute02 | manual-management | +------------------+--------+ 1 rows in set (0.00 sec)

After all this you can now safely continue with the common installation process, just remember when performing Overcloud deployment, check the node status with the ironic node-list command. Wait until the node status changes from deploying to deploy wait-callback and then manually power the nodes.

Tuesday, May 21, 2019

How to Boot into Single User Mode in CentOS/RHEL 7

DISCLAIMER: This is not my post is only a copy, in case the original gets deleted or whatever, posting on my personal blog gets easier for me to find it. You can find the original one at this link https://vpsie.com/knowledge-base/boot-single-user-mode-centos-rhel-vpsie/

The first thing to do is to open Terminal and log in to your CentOS 7 server.

After, restarting your server wait for the GRUB boot menu to show.

The next step is to select your Kernel version and press

e

key to edit the first boot option. Find the kernel line (starts with “linux16“), then change the

ro

to

rw init=/sysroot/bin/sh .

When you have finished, press

Ctrl-X

or

F10

to boot into single-user mode

After mounting the root filesystem using the following command:

chroot /sysroot/

Now, to finish this process reboot your server using the following command:

reboot -f

Wednesday, April 17, 2019

XFS online resize

 You're working on an XFS filesystem, in this case, you need to use xfs_growfs instead of resize2fs. Two commands are needed to perform this task :

# growpart /dev/sda 1

growpart is used to expand the sda1 partition to the whole sda disk.

# xfs_growfs -d /dev/sda1

xfs_growfs is used to resize and apply the changes.

# df -h

Friday, April 5, 2019

Convert string <-> int64 using golang #go-nuts

I believe that if you are going to work with timestamps is better to do it in epoch stamps, so in GO epoch is type int64.

package main

import (
    "fmt"
    "time"
    "strconv"
)

func main() {

    now := time.Now()
    nanos := now.UnixNano()
    bufferTimestamp := strconv.FormatInt(nanos, 10)

    fmt.Printf("bufferTimestamp value: %s\n", bufferTimestamp)
    timestamp, err := strconv.ParseInt(string(bufferTimestamp), 10, 64)
    if err != nil {
        fmt.Printf("Error: %d of type %T\n", timestamp, timestamp)
        panic(err)
    } else {
        fmt.Printf("Converted value: %d\n", timestamp)
    }
}

By running this you will have an output like this.

$ go run test/convert_stringtoint64.go 
bufferTimestamp value 1556951794912716618 of type string
Converted value 1556951794912716618 of type int64

Wednesday, December 12, 2018

How to disable Cloud-Init in a EL-like Cloud Image

So this one is pretty simple. However, I found a lot of misinformation along the way, so I figured that I would jot the proper (and most simple) process here.

Symptoms: an RHEL (or variant) VM that takes a very long time to boot. On the VM console, you can see the following output while the VM boot process is stalled and waiting for a timeout. Note that the message below has nothing to do with cloud-init, but it's the output that I have most often seen on the console while waiting for a VM to boot.

[106.325574} random: crng init done

Note that I have run into this issue in both OpenStack (when booting from external provider networks) and in KVM.

Upon initial boot of the VM, run the command below.

13:18:01 alvaro@lykan /home/alvaro/Documents/2post
$ sudo dnf install libguestfs libguestfs-tools openssl
Last metadata expiration check: 1:53:31 ago on Mon 16 Jul 2018 01:51:05 PM CDT.
Package libguestfs-1:1.38.2-1.fc27.x86_64 is already installed, skipping.
Package libguestfs-tools-1:1.38.2-1.fc27.noarch is already installed, skipping.
Package openssl-1:1.1.0h-3.fc27.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!

13:18:26 alvaro@lykan /home/alvaro/Documents/2post
$ guestfish --rw -a ../../Downloads/CentOS-7-x86_64-GenericCloud-1805.qcow2
Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.

Type: ‘help’ for help on commands
‘man’ to read the manual
‘quit’ to quit the shell

> run
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
> list-filesystems
/dev/sda1: xfs
> mount /dev/sda1 /
> touch /etc/cloud/cloud-init.disabled
> quit

Seriously, that’s it. No need to disable or remove cloud-init services.

Monday, July 16, 2018

Change password to users on qcow2 disk or images

Sometimes you need to change the password to a user in a qcow2 image, to test locally, or if you are using an infrastructure without cloud-init, regardless of the user the procedure is the same.

Depending on the system the packages name could change a little, I'm using Fedora 27 I have installed

[alvaro@lykan 2post]$ sudo dnf install libguestfs libguestfs-tools openssl
Last metadata expiration check: 1:53:31 ago on Mon 16 Jul 2018 01:51:05 PM CDT.
Package libguestfs-1:1.38.2-1.fc27.x86_64 is already installed, skipping.
Package libguestfs-tools-1:1.38.2-1.fc27.noarch is already installed, skipping.
Package openssl-1:1.1.0h-3.fc27.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!


Obviously, I have a QEMU environment to test and run the images, a very important part just to know that your steps are working.

[alvaro@lykan 2post]$ guestfish --rw -a ../../Downloads/CentOS-7-x86_64-GenericCloud-1805.qcow2

Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.

Type: ‘help’ for help on commands
‘man’ to read the manual
‘quit’ to quit the shell

><.fs> run
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
><.fs> list-filesystems
/dev/sda1: xfs
><.fs> mount /dev/sda1 /
><.fs> cp /etc/shadow /etc/shadow-original
><.fs> vi /etc/shadow


Inside the vim editor, you will see the file and now you can change the hash of any user (do not close this until you reached the last step), in any other terminal run:

[alvaro@lykan 2post]$ openssl passwd -1 mysuperpassword
$1$GKdzYMMe$q20PpMv5i/QFbmgwOqtZy1


Copy that generated hash and copy inside the first and second colon punctuation symbol (delete every inside this)


Before

root:!!:17687:0:99999:7:::
bin:*:17632:0:99999:7:::
daemon:*:17632:0:99999:7:::
adm:*:17632:0:99999:7:::
lp:*:17632:0:99999:7:::
sync:*:17632:0:99999:7:::
shutdown:*:17632:0:99999:7:::
halt:*:17632:0:99999:7:::
mail:*:17632:0:99999:7:::
operator:*:17632:0:99999:7:::
games:*:17632:0:99999:7:::
ftp:*:17632:0:99999:7:::
nobody:*:17632:0:99999:7:::
systemd-network:!!:17687::::::
dbus:!!:17687::::::
polkitd:!!:17687::::::
rpc:!!:17687:0:99999:7:::
rpcuser:!!:17687::::::
nfsnobody:!!:17687::::::
sshd:!!:17687::::::
postfix:!!:17687::::::
chrony:!!:17687::::::


After

root:$1$GKdzYMMe$q20PpMv5i/QFbmgwOqtZy1:17687:0:99999:7:::
bin:*:17632:0:99999:7:::
daemon:*:17632:0:99999:7:::
adm:*:17632:0:99999:7:::
lp:*:17632:0:99999:7:::
sync:*:17632:0:99999:7:::
shutdown:*:17632:0:99999:7:::
halt:*:17632:0:99999:7:::
mail:*:17632:0:99999:7:::
operator:*:17632:0:99999:7:::
games:*:17632:0:99999:7:::
ftp:*:17632:0:99999:7:::
nobody:*:17632:0:99999:7:::
systemd-network:!!:17687::::::
dbus:!!:17687::::::
polkitd:!!:17687::::::
rpc:!!:17687:0:99999:7:::
rpcuser:!!:17687::::::
nfsnobody:!!:17687::::::
sshd:!!:17687::::::
postfix:!!:17687::::::
chrony:!!:17687::::::


Close the vim editor, save the changes, and exit guestfish

><.fs> quit

[alvaro@lykan 2post]$


Now you can test the image on any cloud environment or using your local QEMU environment.