gabriel-samfira's profile - activity

Hi David! Currently we support OPC cloud (the oracle public cloud - classic compute), and Oracle VM , with OCI (formerl

Hi David! Currently we support OPC cloud (the oracle public cloud - classic compute), and OCI (formerly BMCS - bare met

Hi jang0913, Yes, Juju charms for windows are supported on Azure, although due to some Azure specific constraints some

Hi jang0913, Yes, Juju charms for windows are supported on Azure, although due to some Azure specific contraints some m

During the hyper-c bundle deployment, that will happen when nodes join active directory and need to reboot, which is perfectly fine. They will recover as soon as the servers come back up and the agent starts running. I will file a bug against Juju to update the unit status when its rebooting.

Sleep is overrated :D. The change is backward compatible. While we love people trying out Hyper-C, make sure you don't run any production systems on it yet. 2016 is still pre-release :). Also, Ceph is not yet supported in windows unless you export it using SMB3/iSCSI. Let me know how it works out!

Just to be clear. Do you want to deploy just openstack with hyper-v compute nodes joined to openstack, or do you want the whole hyper-converged scenario with active-directory, storage spaces direct, etc? Because if you only need a hyper-v compute enabled openstack, there are far less moving parts :)

Awesome! Good luck!

Thanks for the pastebin!

The guide was only tested on MAAS 1.8, which was the stable version at the time of writing the blog post. You seam to be running MAAS 1.9 in your setup. It appears they moved some code around in the version of curtin that comes with maas 1.9.

Can you do an update of https://github.com/cloudbase/cloudbase-init-offline-install/tree/nano-server-support .

You need to actually update the windows-curtin-hooks submodule. The updated submodule takes into account the newer version of curtin, and should fix your issue.

git submodule update --init --recursive

should do the trick. Make sure you rebuild the nano image after you update the repo and its submodules. Let me know if you get passed that step.

EDIT: Your windows-curtin-hooks submodule should be at revision: 6eb00b48f7a9741b154d04b779f688a0d065b623

The link may have been truncated EDIT: never mind. Some HTML got in the link.

On point nr 2, it would be great if you included the command line you used ( eg: \NewNanoServerImage.ps1 -IsoPath $isoPath -Platform BareMetal/VMWare/Hyper-V ). The -Platform flag is especially of interest.

Hi! Can you post a few more details about what you have already tried. Feel free to edit the initial question. It would help to know: 1) what environment you are running on (bare metal, VMWare, Hyper-V, KVM, etc); 2) How you generated the nano MAAS image 3) error you get in MAAS for the node

Currently landscape does not support the Hyper-V hypervisor. You can however, deploy the nova-hyperv charm manually using juju and add the needed relations by hand.

Hello,

The first error you see about finalize failing is due to the fact that the cloudbase-init MSI changed the location of where it installs itself. I just committed a a possible fix for that. Make sure you check it out before trying again.

Also, make sure that if you download the repo as zip, you unblock the zip before unarchiving to make sure you do not run into the "script not digitally signed" error:

Start-BitsTransfer https://github.com/gabriel-samfira/windows-openstack-imaging-tools/archive/persist-driver-option.zip
Unblock-File  persist-driver-option.zip

If you have a windows 8.1 installation available, you will be able to use that to generate any windows image up to 8.1. So that means you will be able to generate images for windows 7 as well.

Let me know if it works for you.

Hi,

This usually happens if the report_interval and agent_down_time configuration options in neutron.conf are absurdly low.

On your neutron-server, edit

/etc/neutron/neutron.conf

and add/change the above mentioned options as follows

agent_down_time = 180
report_interval = 60

To be honest, you could even go higher. Let me know if it works for you.

Hi Chuntzu!

In general we do not recommend using/setting passwords via unattend.xml. I highly recommend you generate a x509 certificate and upload that to MaaS. You will then be able to use that x509 certificate to execute remote commands on your newly installed windows machine over ssl without any passwords.

To generate a new x509 key, log into your MaaS node and run the following command:

maas-generate-winrm-cert

The public portion of the key will be printed to screen. Copy that key (including the "BEGIN CERTIFICATE" and "END CERTIFICATE" portion) and upload it to your MaaS node under user-->preferences-->SSL keys. (it should be in the same place you saved your SSH public key)

After you do this, deploy a new windows machine. After it gets installed and cloudbase-init finishes running, you should be able to run remote commands via WinRM.

You may find a small and nifty python script that can issue remote commands from windows here: https://raw.githubusercontent.com/clo...

Please note that you will need pywinrm for this to work:

sudo pip install pywinrm

after which you will be able to run:

./wsmancmd.py -H <IP_OF_WINDOWS_MACHINE> -s -a certificate -c $HOME/.ssl/winrm_client_cert.pem -k $HOME/.ssl/winrm_client_cert.key "net user Administrator supersecretp@ss"

Please note that windows 8.1 is not in the official list of supported OS (only server OS versions). You may not have an option to set a serial key. MaaS does offer the option to specify a KMS server, in which case it should be fine.

Let me know if it works for you.

I have been unable to reproduce this on my system. One last thing to try. After cloning the repository from github, do an aunblock-file on every file in the repo. After which, edit UnattendTemplate.xml and replace instances of -ExecutionPolicy Remotesigned with: -ExecutionPolicy Bypass. In theory, the RemoteSigned argument passed to powershell should prevent the behaviour you are observing.

Hi Chuntzu! To debug this, we need to get the actual error. It works on my system, but we need to see what is happening in your case. I need you to change a couple of the scripts to add a sleep before returning the error. Please add "Start-Sleep 60" at the following lines: http://goo.gl/3csFwU http://goo.gl/3linMV I suspect the rest of the errors will be resolved once we get the the root cause of the first one. Please also let me know for which version of windows you are trying to create an image.

updated the answer with a little bit more info

If you are using the latest stable PPA, the image should be uploaded as follows: maas root boot-resources create name=windows/win2012hvr2 architecture=amd64/generic filetype=ddtgz content@=$HOME/win2012hvr2-dd The name here is very important. It has to be windows/win2012hvr2. After which you will have to wait for your clusters to sync. The option will then appear in the drop-down list.

adk-tools-maas was designed for the old PXE installer. MaaS has moved to curtin fastpath installer. I have updated my previous answer to include info about how to create the image. Give it a try, and let me know if it works for you.

I have spoken with someone fom the MaaS team. They are preparing to release the image builder and documentation on their official MaaS wiki. It should become available soon. At that point, generating an image should be a matter of supplying the ISO and a serial key (if needed).

Actually, in version 1.7 MaaS uses whole disk images. So to put it in simple terms: install a windows VM on top of KVM using RAW disk images, sysprep, add some finalize scripts and shutdown. That image gets tgz-ed and uploaded to MaaS. I will update the wiki tomorrow to reflect this.

Hi Scott,

I am really sorry for all the frustration caused. The problems you are experiencing are probably due to the fact that we only tested our scripts with the EN_US version of windows. The good news is that with version 1.7 of MaaS generating PXE images is no longer required. Windows will be deployed using full disk images, already sysprepped.

The MaaS team is working on an image builder system that will allow you to just pass in an ISO and it will generate the image for you. Unfortunately, its not released yet. I will write up a quick document explaining how to manually generate it until the image-builder is released.

The procedure, consisting mostly of simply installing a new windows VM on top of KVM, copying over a few scripts, and doing a sysprep. The resulting image needs to be archived and uploaded to MaaS.

I will update this answer with a link to the document as soon as I have had a chance to write it up.

Again, I am sorry for any hard time you may have had.

Gabriel

Update:

We have updated the openstack imaging tools to allow MaaS image creation. Its not yet merged upstream, but you can take it for a spin if you would like. It can be downloaded from:

https://github.com/gabriel-samfira/windows-openstack-imaging-tools/tree/persist-driver-option

Usage info:

https://github.com/gabriel-samfira/windows-openstack-imaging-tools/tree/persist-driver-option#generate-maas-compatible-image

Please take note, that this only works on Windows. Also, in order to get a fully functional MaaS image, the commandlet will need to install the Hyper-V role on your Windows machine (if you do not have it already).

It will create an image from the desired ISO, it will boot up the image, run updates (if selected), install Cloudbase-init, sysprep and generate the required file.

Please note, that sysprep may take a long time depending on whether or not you selected to also run updates. The final image is a RAW disk image compressed into a tar.gz. If you still see a vhdx, wait for the commandlet to exit. You may follow the progress of the sysprep by starting up Hyper-V manager and double clicking on the MaaS-SysprepXXX machine.

Uploading the image to MaaS:

maas root boot-resources create name=windows/win2012hvr2 architecture=amd64/generic filetype=ddtgz content@=$HOME/win2012hvr2-dd

The name here is important. For Hyper-V server 2012 R2, the name must be windows/win2012hvr2. Please make sure you use the latest stable version of MaaS available here:

https://launchpad.net/~maas-maintainers/+archive/ubuntu/stable

After uploading the image to MaaS, you must wait for your cluster to finish syncing the image. MaaS will indicate that images are still syncing by displaying a yellow triangle with an exclamation mark in your clusters view. Once sync is done, you will have windows as an option in the edit node view, after you acquire it.

Let me know if it works for you.

Lets get some more info on the situation first.

Please add the output of the following commands:

On the windows machine you ran the script on:

net use

If the MaaS samba share is not there, lets try to add it and copy over some files again:

# The samba share on the MaaS server should be named reminst
New-SmbMapping -RemotePath \\<MAAS IP>\reminst -LocalPath X:

you should now be able to see a new drive letter called X. Lets try to write something there:

echo testing > X:\test.txt

NOTE: it is not necessary to add a SMB mapping for this to work. UNC path names should be enough. We do this for debug purposes only.

On your MaaS VM:

Lets see if the file is on the MaaS node:

ls /var/lib/maas/samba

You should see a test.txt. If the file is there, you should be able to copy over the WinPE files using:

CopyImageToMaaS.ps1 -TargetPath X:\

Please take note, that MaaS expects one of the following folder names to be present in /var/lib/maas/samba:

win2012
win2012r2
win2012hv
win2012hvr2

Also, if you have not already done so, please read the guide at: http://wiki.cloudbase.it/maas

Just to clear things up. The samba share is mounted on windows and you can see it when doing a: net use You can copy over a file form windows, but it does not appear to be on the target.Is this correct? If so, lets make sure that copying files over is possible. You may need to set up a samba user.

Thank you for pointing that out. I will update the wiki. Vis-a-vis the error message you are getting. Can you make sure you have allocated at least 2048 MB of RAM to the VM? It seams strange, but not having enough allocated RAM may cause that error.

Hi Jeff. Sorry for the late reply. Can you make sure that: D:\sources\install.wim exists? (D: in this case should be your windows ISO mounted). That error seams to be related to the fact that it cannot locate a required file on your installation media.

i have updated the answer. It might be a naming issue. It should try to use the PXE installer and not fastpath (curtin). If you would like, you can find me on freenode, my handle is gsamfira

I suspect what you are seeing is the fastpath installer. After editing the node and before hitting Start, Please click on "Use debian installer". That is the standard PXE installer. The fastpath installer tries to write a disk image directly to you hard disk, and that is done via a minimal ubuntu.

Not really. Please make sure that when you edit the node, windows is selected as the OS. When you "stop" a node, it is reset to defaults (default os, default version - Ubuntu in this case). Also, can you check if the node is using the fastpath installer, or the old installer?

Hello Andrew,

There are 3 stages in MaaS:

• initial discovery
• commissioning (hardware detection)
• Start (actual commissioning/install)

The initial discovery will detect any newly booted system on the network that booted via ethernet.

The commissioning stage is where the system boots a minimal ubuntu image, installs a set of tools and discovers the hardware of the system. After commissioning a machine, it will be in "Ready" state, at which point you can edit the node, set the OS and key, simply click on "Start" in the node screen.

Do not click on "commission" again. Click on "Start". This will start the machine (if you have a power adepter configured) and run the windows installer.

The reason why you only have the INSTALL image for windows in the cluster boot images, is that we only need INSTALL to set up windows. The first 2 steps can be done with the existing ubuntu images.

This also might be a naming issue between what the automated scripts generate, and what maas expects to find. Try the following:

mv /var/lib/maas/samba/ws2012r2std /var/lib/maas/samba/win2012r2
mkdir -p /var/lib/maas/boot-resources/current/windows/amd64/generic/win2012r2/release/
rm /var/lib/maas/boot-resources/current/windows/amd64/generic/win2012r2/release/*
for i in `ls /var/lib/maas/samba/win2012r2/boot/`; do ln -s /var/lib/maas/samba/win2012r2/boot/$i  /var/lib/maas/boot-resources/current/windows/amd64/generic/win2012r2/release/$i;done